How is developing for the different consoles?

Corey Bloyd, an experienced game developer currently working for has decided Munkeyfun topic screens that answer, explaining their experiences to work with a lot of consoles ranging from the PS1 to the Xbox 360.

Bloyd uses some specialized terms, but the description of his adventures with various devices allow to understand the headaches that everyone gave him and which he explains as follows:

PlayStation

Everything is simple and to the point. With some years of dedication you could understand all the PS1 to the bit level. Compared to what you could do with PCs at that time was amazing. But every step of the way you said "really? Do I have to do so? Devils. Ok, I guess ... give me a couple of weeks. " Indeed there was no debugger. You ran what you did and you saw that happening.

Nintendo 64

All more or less works. Most were quick and flexible. You never felt that you were using it. But it's okay because your half-baked results were usually better than most PS1 games. Each cartridge megabyte cost much money. There was a debugger but the debugger was sometimes completely random bugs [...].

Dreamcast

The processor was rare (Hitatchi s H-4). The graphics processor was rare (a predecessor of the PowerVR chips in modern iPhones). There was a lot of features you did not know how to use. Microsoft and spoke almost DirectX box set as a PC type but forged ahead. That would not work anyway. looked like it might have been very cool. But the PS2 would be much better!

PlayStation 2

You get a lot of manuals written 10 inches thick by Japanese hardware engineers. The first time you read nothing makes sense. The second time, the third book has a little more sense of what you learned in the eighth book. The machine has ten different processors (IOP SPU1 & 2, MDEC, R5900, VU0 & 1, GIF, VIF, GS) and six separate memory spaces (IOP, SPU, CPU, GS, VU0 & 1) and all work in completely different ways.

There are so many amazing things you can do, but all require money back through invisible blade access violation (segfault). Making the first triangle appear on the screen it took the team a month because enrutear included commands through oddities like R5900-> FIV-> VU1-> GIF-> GS no feedback on what you were doing wrong until each step lograbas was correct.

If you were willing to modify your game to fit the machine, you could get amazing results. There was a debugger to the center processed (R5900). Worked quite well. For all other processors simply had to write code without bugs.

Gamecube

GC did not work with a lot. It seems really flexible. As you could do anything but nothing is terribly bad or great. The processor was not fast but its features were tragically under-utilized in comparison to the Xbox.

The CPU had an incredibly low latency RAM. Any data structure complicated or messy should be fine (in theory). Just do it. But more than half of the RAM was divided behind a surprisingly high latency sweep. So you had to manually organize your data in Active vs Bulk. He had a SIMD [processor capable of parallel processing] who worked half and only had 2 operations with floating at the same time, instead of 1 or 4.

PlayStation Portable

Nor did a lot here. PS2 was presented as a simple but inside it felt more like a PS1 bulky. They tried to improve some parts to make it less difficult to work with him, but those parts felt clumsy compared to the original design. Almost taking the speed of rasterization of PS2 in a smaller resolution meant that you did not have to worry about mixing pixels.

Xbox

It smells like a PC. There were some tricks you could dig to get more of the machine. But mostly it was a blessing enough to have a unique expertise and consistent PC from which to develop. The debbuger worked! I really, really worked! PIX was hand delivered by angels.

Xbox 360

[...] Really smell until the PC-browsing-The GPU is great - except that the limited EDRAM means you have to think twice before using antialiasing requirement WTF! Holy shit there are many records of SIMDs! 4 x 128 floating logs register banks x 6 = 12k records!

You get a Dx9 and everything works, but if you explore more you find better ways of doing things, more and more. Eventually your code looks nothing like PC-DX9 and works waaaaay better than before! The debugger is amazing! PIX PIX! I kiss you!

PlayStation 3

A box of 95 pounds appears on your desktop along with a printed 24-step instructions on how to turn the first time. All they try, most fail to try starting. Eventually one succeeds and gets to set the machine from all others. There is only one processor. It seems to be able to do everything, but can not.

The sound processor (SPU) looks like it should be really amazing but not for nothing you or anyone else is doing. The processor debbuger works pretty well but there is no debugger for the SPU. There was nothing like PIX at startup. Eventually some developer Sony got tired and made ​​his own type PIX debugger.

The graphics processor is very, very disappointing ... most about working with the central processor, but it can not handle the workload. Some look more deeply into the sound processor and by god, they are fast! Unfortunately realize that the SPU needs to be devoted almost all the time to compensate the weaknesses of the graphics processor.

What do you think? I think I'll be a little less recalcitrant next time you find a bug or I'm complaining because the game I'm dying to be published takes a long time for my console of choice.