If this is common knowledge then my apologies.

But I stumbled across a PS3 developer's web site and they had some video
promos of their upcoming game. In some shots, they zoomed in close enough
where one could see actual code. Here's a reasonable facisimile:




It was definitely "Medius" Not medium or media. And another video showed.


So it is definitely C++. I was surprised that they had so many hard-coded
variables: fifteen in the above structure! And those were just the ones
I could see on the screen. I'd stick those in a data file and skip a
compile anytime those changed.

Oh well, the code was definitely in an XP window. But that is surely just
a front end to the PS3. One funny thing is that they had old Sony CRTs and
new Dell flat panel LCDs right next to each other

All in all, I guess it was a little anti-climatic. I was expecting some "super-
wonderful-insight-handed-down-from-above". But I guess they put their pants
on one leg at a time like us.


Oh well. Thought it was interesting. Sorry if this is a stupid post.

If you were to put constants in a separate file, you wouldn't need to recompile, but you would still need to read the file. Even then, you would likely have to have further constants to access those constants in the array you keep them in. Not to mention the fact that you lose some of the benefits of having a simple constant that's known at compile time.

at least use a #define, rather than a magic nameless number in your source code!

OneSadCookie Wrote:at least use a #define, rather than a magic nameless number in your source code!

Its name is the variable it's being assigned to. If that's the only place the value is used (and it's in a reasonably central location), there's no benefit at all to #defining it.

that may be true of


(but only if they're only ever assigned once; if they're ever reassigned then those numbers are magic and should be made named constants. Since their names indicate that they're member variables of the class, I'm inclined to suspect that they're intended to be mutable, and therefore these numbers *are* magic)

but it's certainly not true of


Where that 425 is completely meaningless (other than that we know something's going *really* fast)

WhatMeWorry Wrote:So it is definitely C++. I was surprised that they had so many hard-coded variables: fifteen in the above structure! And those were just the ones
I could see on the screen. I'd stick those in a data file and skip a compile anytime those changed.

Most of our PS3 code is written in C++, even on the SPUs. Some things are written in assembler where needed. Another thing you might be supprised about is the compilers we use. Well PS1, PS2 and PSP used gcc, as for PS3 well you can only guess

WhatMeWorry Wrote:All in all, I guess it was a little anti-climatic. I was expecting some "super-wonderful-insight-handed-down-from-above". But I guess they put their pants
on one leg at a time like us.

Professional games developers are just normal people. Sometimes the code we write isn't perfect for whatever reason, lack of time (especially in crunch time), laziness. Where I work we have a coding standard that we try to adhere to, but it doesn't always end up happening.

Of course my code is absolutly perfect ;-)

I am very honored -- hope that is not too strong a word-- to see a posting from an actual Cell programmer. The Cell processor fascinates me because it seems like such a radical (in the good sense) design. Obviously, i'm sure you've signed non disclosure agreements but are you able to tell us anything without breaking your contract? I can't take too much stock in the Public Relations people and CEOs making pitches at trade shows.

Is it as hard to program as some people has suggested?

Are you mildly impressed, impressed, blown away at performance?

If these are too much insider questions, can you tell me at least what features you use from C++ : Like how much is inhieritance used? Do you use templates? How about the STL? Any features or techniques you've found to be particular useful?

Pardon my enthusiam, but I don't recall many professional programmers posting before, and a Cell guy at that. I don't want to jeopardize your job and will understand if you don't respond. Heck, you might be too busy getting your next gen game out and won't evern read this

I have to agree with you, the Cell Processor is the most fascinating part of the PS3 in my opinion, more specifically the SPUs, just as the Vector Units made the PS2 so interesting. Unfortuanatly as yet I have no experience programming the SPUs myself just the PPU and GPU so I can't really comment too much on that side of things.

As for Cells difficulty to program, I think this mainly comes down to utilising the SPUs effectivley. Not only do you have 6 of them so you have the same kind of issues with them, as you have with any multi-core architecture, i.e how do you best share tasks among the 6 processing elements, but also each SPU only has limited Local Store. You have to fit your code and data into the Local Store. Generally with large data sets you will have to partition you data into smaller sets and work on them bit by bit. I personally love this kind of thing just as I loved the Vector Units on PS2 but I can see that some people may not enjoy it as much.

As for Inheritance, templates and STL. I think it's fair to say we do use all 3 to some extent or other, although I would be wary using at least the latter two in SPU code although as I understand it, there is nothing stopping you (I come from a C background originally so I'm still quite wary of such new fangled things) although I do use all three in my own Mac / PC code to some extent.

I hope you don't mind me being delibertaly vague, I certainly don't want to get into any trouble over my NDA. Certainly to my knowledge I haven't mentioned anything that isn't already in the public domain of which there seems to be quite a lot of Cell related information.

I should probably note that any opinions here are my own.

Hope this has been in some way insightful.

Claire