Slashdot Mirror
The Art of PS3 Programming
The Guardian Gamesblog has a longish piece talking with Volatile Games, developers of the title Possession for the PS3, about what it's like to make a game for Sony's next-gen console. From the article: "At the end of the day it's just a multi-processor architecture. If you can get something running on eight threads of a PC CPU, you can get it running on eight processors on a PS3 - it's not massively different. There is a small 'gotcha' in there though. The main processor can access all the machine's video memory, but each of the seven SPE chips has access only to its own 256k of onboard memory - so if you have, say, a big mesh to process, it'll be necessary to stream it through a small amount of memory - you'd have to DMA it up to your cell chip and then process a little chunk, then DMA the next chunk, so you won't be able to jump around the memory as easily, which I guess you will be able to do on the Xbox 360."
1) The API is well known by developers, and has remained stable from version to version. This reduces the amount of R&D and training that need to be done for a game.
;-)
Uh most games nowadays use D3D.
2) Use of OpenGL allows for portable code. While you can't completely get away with writing the same code between a PC version and a Console version, much of the rendering engine at least has a chance of getting reused.
If you write a flexible enough rendering engine this wont matter so much.
3) Carmack says so.
yeah, ok. good reason
4) New features actually go through a standards process, meaning that they get more documentation than just "whatever Microsoft feels like telling you".
Which also means it takes long YEARS for a new version to come out, how long have we been waiting on OpenGL 2.0? Some cool things have come out since and OpenGL is always playing catch now.
5) DirectX is a non-portable skill. It ties you to Windows and the X-Box(s). OpenGL "ties" you to the Gamecube, Windows, PS2, PS3, Linux, Macintosh, etc.
Graphics Programming is a portable skill, I've never met a good graphics programmer who couldnt switch between the two on the fly. Honestly if you can only do graphics in 1 or the other that's pretty worthless.
I'm sorry the whole DX vs OGL war is really old and really lame, Neither are a "god-send". They are both tools, use the one that is best for the job.
What I find interesting about the question of "What can I do with 8 threads?" is that most people seem to assume that you can only have one graphics thread. Why not have 2? Or 3? Or 6? The Emotion Engine's core design is based around having two parallel programmable units handling graphics at the same time, for example one animates the surface of a lake while the other makes the pretty refracted light patterns on the bottom. Yes, it's nastier to program than standard single-thread-for-each-task programming, but it makes for a very powerful architecture when used properly. Similar things can be done with other parts of a game, and if you design your data layout and flow correctly you minimise the need for synchronisation. You could draw your frame with 7 parallel threads, then flip all the SPEs over to handle the physics, input, etc update for the next frame. It's all just a matter of thinking about how you design your game.