Developer explains what it’s like developing for each console: PS3 being the hardest

Alucardx23

Regular
Short fun read on what it is to program on several of the most famous consoles.

Cory Bloyd who works at Munkeyfun studio has revealed how hard/easy it was developing for different consoles ranging from N64 to the PS3. And you guessed it right, the PS3 was the hardest.
“I’ll add that even though I give Sony a hard time, I really do enjoy pounding on their machines. Sony consoles have always been a challenge. But, if you are willing to work with them instead of against them, they love you back tenfold,” he said.
He revealed these things on Reddit, where he goes by the handle Corysama. You can check out his entire explanation below.

Read more at http://gamingbolt.com/developer-exp...ole-ps3-being-the-hardest#t7PXuG5ORAd4rHRP.99

http://gamingbolt.com/developer-exp...loping-for-each-console-ps3-being-the-hardest
 
The CPU was weird (Hitatchi SH-4).
What was weird about the CPU? True it could have done with a better cache (I think it used direct mapping rather than N-way set associative) but otherwise it looked like a fairly sensible RISC architecture with quite good FP performance.
The GPU was weird
That just annoys me.
 
While there are always general issues shared by most developers, a lot of stuff will always remain personal. What seems perfectly logical to some is hard to grasp for others and vice versa. As a programmer and IT person in general I run into that every day. ;)
 
I don't understand why he ranks the PS3 as harder to develop for than the PS2 with its Japanese manuals, no dev tools, and completely alien architecture.
 
What was weird about the CPU? True it could have done with a better cache (I think it used direct mapping rather than N-way set associative) but otherwise it looked like a fairly sensible RISC architecture with quite good FP performance.
That just annoys me.

You must have been expecting the next bit then:

There were a bunch of features you didn’t know how to use.
 
Still waiting for DF to do a last gen round up/face off with Xbox vs GC vs PS2 vs PSP vs Wii vs DC with the systems best looking games.
 
If he'd written "there were a bunch of features I didn't know how to use" then, maybe, one could ignore it, but to what in particular was he refering?

Modifier volumes? I wonder if he/she actually worked on the DC at some point for a significant time. Going by its comments, I doubt it.
 
And in the devs here opinions what would you consider the hardest to program for console released since the PS1 era? I guess it boils down to three choices and that would be the Saturn, PS2, and PS3.
 
And in the devs here opinions what would you consider the hardest to program for console released since the PS1 era? I guess it boils down to three choices and that would be the Saturn, PS2, and PS3.

You'd have to be more specific than that. What do you mean by hard.

I remember it taking me a week to get 1 character on screen on a Genesis because all the documentation we had was a register list. The dev kit I had at the time had no way to send any data back to the Amiga we used to write the code, so all you could do was compile and run, without code to write characters to the screen you couldn't even do printf debugging.

But I wouldn't consider the genesis to be particularly difficult to work with.

If you wrote uCode for an N64 it had a lot in common with PS2.

Do you mean hard to utilize well? hard to develop for because of shitty tools? Hard to get started because of bad documentation? Hard to build big applications on? Hard to architect your game around? Hard because of the shear number of moving parts?

Hard can mean a lot of things.
 
On the topic of unnecessarily hard, I just read the latest entry in your "exciting blog", and I was sorry to read that your efforts to drive a 3D printer with a BeagleBone, for which you had sought SGX docs a while back, have turned out mostly fruitless.
 
What was weird about the CPU? True it could have done with a better cache (I think it used direct mapping rather than N-way set associative) but otherwise it looked like a fairly sensible RISC architecture with quite good FP performance.

I could see how an assembly programmer who was used to 32-bit instruction RISC or CISC ISAs wouldn't like it. You don't even get 32-bit branch instructions, so you constantly have to use literal pools for things like function calls. And there's no general shift by immediate instruction.

The SIMD was fast for what it was but what it provided was really spartan. And I could see how this would put you off for a console that had no dedicated coprocessors for T&L. Did it have anything at all outside of dot products and matrix * vector multiplies (themselves just dot product macros)? The 16 FP32 x2 bank register file also seems pretty constraining, even for the low latencies.
 
Gosh - that's stretching the grey matter. IIRC it also had some instructions for fast recip and/or sqrt calcs, which are clearly useful for shading etc.

Anyway, complaining about 16 FP regs when, IIRC, the contemporay x86 only gave you 8, is a bit mean :)
 
Back
Top