Hard Light Productions Forums
Off-Topic Discussion => General Discussion => Topic started by: IceFire on July 04, 2005, 12:24:08 am
-
..or rather, programmers are reportedly having a hard time writing software for multithreaded games to work with these two products.
http://arstechnica.com/news.ars/post/20050629-5054.html
-
interesting
-
well, we all know that the first generation of games won't be anything compared to the 2nd-3rd generation of games for each console repectively, once the devs know what a console can do, and such
compare the graphics between, say... halo, and Halo 2(sans texture errors)
-
This is hardly unexpected. It was no big secret that learning to code for the things was gonna be a pain. Hopefully it won't take too too long for them to learn. I'm no big console gamer, but having dev who know how to multithread games is a good thing, since that's the way the wind is blowing. Still, it's likely to be a considerably steeper learning curve then the other console generations have seen.
For the time being at least, the console wars are going to be between ATi and nVidia partly, and partly between sony and microsoft's marketing divisions.
-
Score 1 for the Nintendo Revolution!!! :D
-
Competition is good.
-
Scarcely a shock.
-
Suck it up. It's not only console devs who are going to have to start learning to program for multiple cores.
-
This makes it interesting for people like myself who are going through programming education now. Are we going to be learning out of date single core programming techniques that will prove futile by the time graduation comes around?
It also opens up some other more... philisophical questions about how the future of programming is going to work. Multiple processing threads is starting to go the way of how the brain works. Perhaps there are lessons that can be learnt from that.
Bio-Science / Technology degree's may be something to become more common...
-
You probably won't be studying purely single-core techniques, because even programmes running on a single core use parallelism.
-
Bah, they said the same about the PS2, and still no programmer died because of it. No big deal there :p
-
Here's a pretty good explanation about an actual developer's thoughts concerning programming for multiple cores.
http://www.gamespot.com/news/2005/07/01/news_6128504.html
-
i personally think they are overcomplicating things. its like compairing carburation to fuel injection. fuel injection is more complex and supposidly better, but you wont find it on a race car or single engine prop plane.
i do like the xbox's hardware capacity for dynamic lod-ing and object generation. i see it could make modding in fhe future much easyer. also game data coulde be created that would look better for systems with more power than the game was designed on. it would be nice to play the old quake at doom 3 detail with little or no remastering. it also opens up for stanardised game engines that could have much longer lifespans than what we have today. all this good stuff if it happens that they didnt screw up the core design in the first place.
-
Originally posted by Nuke
i personally think they are overcomplicating things. its like compairing carburation to fuel injection. fuel injection is more complex and supposidly better, but you wont find it on a race car or single engine prop plane.
Unless its a WWII fighter :)
Yeah I just posted the article for interests sake. Most know that first gen games will be ok in visuals and performance but will have nothing on what the later versions will do and look like.
-
WWII fighter engines were supercharged, not fuel injected. unlike carburation, superchargers force the air in at a much higher psi and makes the fuel/gas mix more explosive. fuel injection requires more advanced electronics than were available back then. your average civilian prop plane uses a carburator hnot too different thanwhat you would find on a lawn mower.
-
more parts = more possibility for something to screw up
-
Originally posted by Nuke
i personally think they are overcomplicating things. its like compairing carburation to fuel injection. fuel injection is more complex and supposidly better, but you wont find it on a race car or single engine prop plane.
It makes a great deal of sense to have multiple cores in a pure games machine IMO; there's an inherent parallelism in the way they have to structure games nowadays, I believe; different threads for physics, rendering, AI, etc.
-
it sounds good in theory but the programmers are gonna need to relearn alot of things to get the most out of the machine. i imagine the different setups will make porting code a hell of alot more difficult. i forsee alot of single platform games. but what other way is there to go, they kinda hit the clock speed cap already.
-
Originally posted by Nuke
WWII fighter engines were supercharged, not fuel injected. unlike carburation, superchargers force the air in at a much higher psi and makes the fuel/gas mix more explosive. fuel injection requires more advanced electronics than were available back then. your average civilian prop plane uses a carburator hnot too different thanwhat you would find on a lawn mower.
You might want to read up on your WWII engines then :)
Diamler Benz DB601 and DB603 had fuel injection liquid cooled engines. The big advantage that Diamler Benz was able to get out of these engines, in terms of practical combat use, was the fact that the engines suffered few ill effects of negative-G exposure meaning the pilot could push forward on the stick and dive out of combat. During the Battle of Britain, Spitfire and Hurricane (Rolls Royce Merlin) pilots had to learn to roll inverted and follow by pulling back on the stick. Any attempt to emulate the move would stall the engine as they were using carbeurated engines and the fuel would stop flowing.
This was later solved with a fuel ring (invented by a WAAF actually) and then fuel injection much later on.
Supercharged, turbocharged, and turbosupercharged methods were all used as well.
-
Originally posted by Turnsky
well, we all know that the first generation of games won't be anything compared to the 2nd-3rd generation of games for each console repectively, once the devs know what a console can do, and such
compare the graphics between, say... halo, and Halo 2(sans texture errors)
try halo and chronichles of riddick.
-
You know what? Halo still looks good compared to a lot of the newer games. I find that somewhat interesting.
-
Originally posted by Deepblue
You know what? Halo still looks good compared to a lot of the newer games. I find that somewhat interesting.
I think its like Blizzard games. WarCraft 3 wasn't all that groundbreaking in the graphics department when it came out but they spent a damned long time making sure it looked bloody fantastic for what they had to work with. The interfaces, the units, and everything is crafted to a very high quality.
The same I find from Bungie. They always adhered to making sure things were top notch in every aspect. Top level quality of artists. Other games have flashier graphics but they usually don't have quite the same art design. So while the graphics are technically amazing, they lack the artistic element that can make a good game engine look great.
-
Originally posted by aldo_14
It makes a great deal of sense to have multiple cores in a pure games machine IMO; there's an inherent parallelism in the way they have to structure games nowadays, I believe; different threads for physics, rendering, AI, etc.
what happens if you are half way through drawing something when the physics decides to move it, or AI is trying to find the most important target when it gets blown up.
very messy.
-
Indeed, it means all sorts of checks to make sure the object in question has been processed by the core gameplay stuff.
I can only imagine the utter hell pointers must be. :shaking:
-
Mais naturellement.
But that's why you have sempahores and locks and soforth. I can't think of a good way to do it entirely sequentially in a single thread, at least.
-
There are a few things you guys are forgetting. XBox360 has three dual thread cores, and PS3 has one master core with 8 slaves. Logically speaking, those are two entirely different setups. XBox360 will supposedly need checks after each cycle to verify that the six threads are valid. Programming in this fasion would indeed be a nightmare. PS3 supposedly will not need to do that, as all the SPEs are controlled by the master core. However, it is the utilization of the 8 SPEs that will be a nightmare (the odds are a few SPEs wont be used).
Two different structures, two different nightmares. But then again, I could be completely wrong.
-
"Double the threading, double the fun!" :p
-
"Three times the hair loss!"
I've often wondered about good ways to preserve thread independence, myself; quite often I've ended up in situations where it's slow to sync thread operations, and I've tended to look at ways in which I can minimise deadlock, inconsistency and soforth (as well as work stuff, I was trying to write a flexible side-scroller shooter a while back).
'tis frankly a pain in the arse. Especially as best practice design can be a bit slow, at least with Java (which has an inherent slowness anyways, of course).
-
I'll just leave the coding to the code-monkeys to figure out. I don't care how it works, as long as I get some decent games to play. :nod:
-
So, what's really the worst case scenario? We can expect single threaded games for a while, with the GPUs pulling the majority of the weight, but what's the worst that can happen long run? Something along the lines of using the cell's central processor to do all the gameplay and AI and physics, 1 spu to do fancy explosion physics, and 8 to decode real time ads for in game TVs?
.....uh....maybe I shouldn't give them any ideas, huh?
-
Originally posted by phatosealpha
So, what's really the worst case scenario? We can expect single threaded games for a while, with the GPUs pulling the majority of the weight, but what's the worst that can happen long run? Something along the lines of using the cell's central processor to do all the gameplay and AI and physics, 1 spu to do fancy explosion physics, and 8 to decode real time ads for in game TVs?
.....uh....maybe I shouldn't give them any ideas, huh?
More & more games will likely be either developed for a single platform, or multiple platforms with performance concessions made for compatibility (perhaps via middleware). I'd imagine it'd cost a bit more to develop games, leading to less originality (dependence on known brands, sequels, etc - think EA). Possibly even more film licenses as it's been suggested CGI models can be almost directly ported for use on the new consoles.
So basically the same as usual.
-
It's interesting because I'm looking to move into the gaming career or something with computers & creativity.
I've always longed to want to know how to program 3d stuff myself, but these days the maths involved are starting to scare me away from that particular field. I'm more likely to pursue an artist or Designer role.
Hell, I'm still trying to get my mind in the right frame of mind for learning. Uni starts next week and I'm still fairly slow-minded. I hope I can pick things up again... =S
At least I've got a year before I select a major. So I can try and figure out if I want to brave the maths or not...
Realistically, I'd just like to have have some knowledge about 3d programming and stick with the designing part...
-
Originally posted by aldo_14
More & more games will likely be either developed for a single platform, or multiple platforms with performance concessions made for compatibility (perhaps via middleware). I'd imagine it'd cost a bit more to develop games, leading to less originality (dependence on known brands, sequels, etc - think EA). Possibly even more film licenses as it's been suggested CGI models can be almost directly ported for use on the new consoles.
So basically the same as usual.
On that front, i'm going to be really happy with the Revolution's said ability to play basically every single Nintendo Title, possibly as far back as the Nes! Screw new games, i'm going to be veeeery happy playing the entire Legend of Zelda series on a single platform without the crappy issues that come up with PC Emulators...:D
-
I personally could care less about all of those old games. I am interested in the Revolution's new franchises as well as the rumored abilities of the Revolution controller (hot & cold response mechanisms, haptic feedback, etc.).
-
Originally posted by Grug
It's interesting because I'm looking to move into the gaming career or something with computers & creativity.
I've always longed to want to know how to program 3d stuff myself, but these days the maths involved are starting to scare me away from that particular field. I'm more likely to pursue an artist or Designer role.
Hell, I'm still trying to get my mind in the right frame of mind for learning. Uni starts next week and I'm still fairly slow-minded. I hope I can pick things up again... =S
At least I've got a year before I select a major. So I can try and figure out if I want to brave the maths or not...
Realistically, I'd just like to have have some knowledge about 3d programming and stick with the designing part...
Work your arse off in your spare time on what you want to do. Biggest mistake I made at uni was realising what I wanted to do, and how to go about it, after choosing my course.
-
Come on, multithreading is ridiculously simple if you start your project already considering it as a multithreaded one. It's much more likely that they're having trouble with obscure and badly documented APIs than with the actual concept of multithreaded software. Unless they're terribly bad software architects and programmers, which is unlikely (well, not all that unlikely considering the hackish nature of most game programming done nowadays).
-
char OutputData[] = "Hello, world!";
for(int i = 0; OutputData[i] != '\0'; i++)
{
char buf[2];
buf[1] = '\0';
buf[0] = OutputData[i];
printf("%s", buf);
}
Of course that's in C. A textbook example of C++ would involve templates, derived custom classes, and overloaded stream operators. :p
-
Heh. I made a "Hello, world!" proggy in VB a while back.
-
Originally posted by Styxx
Come on, multithreading is ridiculously simple if you start your project already considering it as a multithreaded one. It's much more likely that they're having trouble with obscure and badly documented APIs than with the actual concept of multithreaded software. Unless they're terribly bad software architects and programmers, which is unlikely (well, not all that unlikely considering the hackish nature of most game programming done nowadays).
Load balancing across either 3 or 9 processing units, I reckon, would be the primary difficulty. IIRC that was what pissed off a lot of PS2 developers (balancing a number of pipelines in that case, I believe). I would imagine they are having to control which PU hosts which threads (obviously you're having more threads than PUs in any non-trivial case), and more importantly balance use of local cache, pipeline, etc.
(Incidentally) IMO that still falls under the multithreading category.