Slashdot Mirror
Conflicting Reports of PS3 Programming Difficulty
xenongamer writes "It appears there isn't any type of concensus regarding the programming difficulty of Sony and IBM's upcoming Cell processor. From the article: 'Although few doubt the relative power of the Cell microprocessor, many have expressed concern over the chip's asymmetric design, which makes programming for it a potential disaster ... One such man was 3D artist Josh Robinson, who was fired from his position at Sony just weeks after making a public, negative comment about PlayStation 3 development on his Internet blog.'"
I've written a huge amount of PS2 code for various games sitting on the shelves right now. I will do my best not to sound too harsh.
Reading your comments I get the feeling what it must be like for a Formula 1 driver listening to someone complain about taking a racing car out for a spin and complaining that it 'hard to drive' and then listing a bunch of silly reasons like no air condition or stereo like he has in his car at home.
The PS2 and PS3 and two of the most amazing and joy to work with graphic systems ever. Unfortunately the people most likely to talk about the two systems are inversely proportionals to their qualifications to do so.
Through some crazy reasoning the fact that Microsoft decided to try to build a console around the legacy x86 hardware design seems to have given the green light to every clown who knows a little DirectX to pass himself off as an expert on console hardware and development. And to run his mouth off on the Net about how the 'crazy' PS2/3 is 'stupid' because it isn't anything like his pc he is used to.
The PS2 and PS3 are machines designed for experienced console engineers to efficiently pipe compact media data from disc to screen for as cheaply as possible. The 8000 or so Sony titles sitting out on the shelves is the only thing that counts.
I have nothing but pity for people stuck in front of their archaic x86 pcs when I have access to something amazingly cool and powerful as the PS2/3.
Taking a look at Asymettric procesing... (PS3) This allows us to give each processors specific tasks. For example we could dedicate 1 cell chip to running say the AI for a game, another for the Player physics and the rest for graphics and sound.
Sorry, that's not how it works. You're thinking that the developers have 7 processors to play with, each capable of running a complex task like AI or the graphics engine. In fact the SPUs are more like DSPs or specialised co-processors. Last time I checked, no-one was designing AI algorithms to run on DSPs.
I'm sure that a sufficiently motivated person could write a multi-threaded AI algorithm to run on a conventional CPU with 7 co-processors. But it would be really hard to develop.
PS. If the Cell architecture is ideal for graphics rendering, what's that honking great Nvidia chip doing in the PS3? Providing ballast?
PPS. You can save time when typing out plurals by not adding an apostrophe every time.
For the record, this reply is not out of ignorance. I am a game engine developer with experience with PS2 and XBox development, at a low and high level. The PS2 is in every measure completely outclassed by Xbox. I'll address some of the big limitations of the GS here, but I can go on about the EE and VUs if you like. The GS is a POS. The biggest limitation of the GS, of course, is the memory. There's just not enough to do anything interesting. But there are many other significant limitations, including a severe lack of useful ALU operations, low precision interpolators, and a lack of speed compared to the NV2A GPU on the Xbox. The NV2A kicks the living crap out of the GS. There is no built in support for dot products, which are required for per pixel lighting. I have gotten dot products to work through clever (read: extremely hacky and slow) blit operations. Because of the high overhead involved with getting a dot product operation working, the only practical way of doing per pixel lighting is with a deferred illumination model. But you run into the lack of GS memory which makes deferred illumination impractical. If you could get past these two barriers, there is no practical way of normalizing interpolated vectors on the GS. There is no support for stencil buffers, so stenciled shadowing is impractical. Sure, you can emulate stencil buffer functionality using wrapped additive alpha operations (use 1 for a stencil increment, 255 for a stencil decrement), but if you want to do do z-fail shadows (which are required to remove artefacts when the shadow volume intersects the near plane), you have to invert the Z buffer. This can be done on the GS, but it is extremely slow unless you are using a 24 bit z-buffer (you can use an alpha blit, essentially a 1-z of the relevant area of the z-buffer in 24 bit mode). And again, you run into the low GS memory limitation. And don't get me started on the crappy interpolators. Big triangles just look like ass. The solution? Tessellate. Joy. The EE and the VUs arent much better. And if you want to do anything useful with the VUs, the EE is going to be damn busy assembling DMA packets for the DMAC, so you can lose all hope of even getting close to the combination of graphics + audio + sim fidelity + gameplay that you get on the Xbox. The PS2 is no formula 1 racer. It's a souped up Yugo with a blower.