Image Image Image Image Image Image Image Image Image Image | January 22, 2018

Scroll to top



PS3 Programming for Possession |

Keith Stuary did an article for the Official PlayStation 2 magazine about the development of Possession for the PS3. Now he can talk about what he learned, and it’s quite interesting.

First of all, the PS3 uses OpenGL, an open well known standard. (Even I’ve done some OpenGL programming, and it’s nice.) So anyone who’s done OpenGL, and there are a lot of us, will be familiar with the 3D graphics engine of the PS3. Because there is so much knowledge, books, and tutorials about OpenGL, it makes 3D programming for the PS3 much easier than it was for the PS2.

As well, the RSX chip from nVidia uses the Cg shader language, which is a standard that many people know. It’s not a Sony exclusive thing. And here is someone else saying how great the physics will be – Volatile’s lead PS3 programmer, Lyndon Homewood:

“The graphics capabilities of PS3 will, I think, be slightly above the absolutely top-end graphics cards on the PC, but you’ve got much more processing power in the box so you’re going to see a lot more physics, a lot more generated geometry. With water ripples, for example – they’re pretty much algorithms, you have a flat plane of triangles and you run some sort of mathematical algorithm over it to generate a surface rippling effect – well, you will have the processing power to do these sorts of generated geometry effects On PS3. You could actually put one chip aside just to do that…”

And on the question of how to make the most use of the SPE’s, he had this to say:

“The way we’re thinking of doing it ourselves is via a job queue. We’ll stick the jobs we want to do into a queue on the main processor and then we’ll get the SPEs to pull off a queue entry and process it whenever they’re free. You want to make sure all of your processors are always running. If you give the chips specific jobs, you’ll end up with a lot of them being idle – you won’t get the maximum out of PS3 doing that unless you time everything perfectly, so that the time it takes to do the animation on the first chip is exactly the same amount of time to do the physics on the next chip, which is exactly the same length of time it takes to do all your AI on the next chip – I think that would be extremely problematic.”

It’s nice to hear words from an actual developer’s mouth for once.

Gamesblog – Possession and the art of PS3 programming from Guardian Unlimited

  • Black Guy

    “Frankly, as a programmer, I find this fairly ridiculous. 3D APIs like DirectX and OpenGL are trivial to learn. Just like a college CS grad can’t program Word or Oracle just because he knows C++, it doesn’t mean that you can get maximum performance just because it uses the same toolset.

    More importantly, multithreaded programming is one of the most difficult problems in computer science. Take the “job queue” for example. What happens when two SPEs hit the queue at the exact same time? Its terribly inefficient to have two doing the same task. More problematically, they may alter the value twice- your ammo goes down two bullets instead of one. One common solution to this is “locking” on the queue, such that access happens serially (i.e. one at a time). However, that causes other SPEs to sit around waiting for things to do as they wait in line for another job.

    I’m simplifying things here just to illustrate a point. Next-gen programming is hard (the same problems are on the Xbox 360, PC, Mac and most likely the Revolution). As we reach the limits of Moore’s Law, we need to be more creative to push the technological envelope.”

  • As a programmer myself, I have to respectfully disagree. Knowing an API well, before even touching a new system, gives you a big advantage. And your remark about queues is ridiculous. You don’t need to lock all the SPE’s in order to lock the small little routine to add a task to a queue. Two tasks coming to a queue is a trivial matter to solve. And while multithreaded programming is one of the more difficult aspects of programming in general, it is by no means unknown territory. We’ve been doing it for decades.

  • aperson

    you know what line gets me?

    ““The graphics capabilities of PS3 will, I think, be slightly above the absolutely top-end graphics cards on the PC”

    If it’s going to be only slightly above, then will PC gaming already go leaps and bounds over PS3 next year?

    Otherwise, its a good read and nice to know its not as hard as people say it is to program for the PS3.

  • Black Guy

    iCan not understand why someone always has to draw a comparison between consoles and PC; maybe I’m missing something but its really stupid. X360 and PS3 will hold a slight edge for about a year (if that) but PC’s will ALWAYS be better no matter how advance a console is.

    A rig that can perform at the theoretical level of X360 and PS3 will cost about $3K easily. Almost a 1/3 of the price being the gfx card. Its like trying to compare a 90hp Honda Civic to a 16 cylinder exoctic sports car. It just doesn’t work.

    The latest ATI card – the XT1900- is suppose to b comparable to the X360 theoretical performace. The MSRP for the lowest card is almost $600. Lets add a dual core AMD for $1000, …. How much does a X360 cost… iThink $299.99

  • Black Guy

    Henning: Point taken. But regarding multithreaded programming being around for decades; maybe it has but it hasn’t really been employed in video games (from what I’ve read.) Question: Wasn’t the Sega Saturn the first multithreaded multi CPU system? It didn’t do well cuz developers shyed away from its complexity even though it was supposedly a very powerful system for its time.

  • I’m not saying there won’t be teething pains. But it is possible, and not rocket science. And this is something that Xbox 360 programmers will have to learn as well. If developers want a leg up, they can hire some Mac game programmers who’ve had more than one core/CPU for several years now.

  • shift

    interesting read. i’ll believe it, though, when i see it in action. there’s too much speculation to draw out a fair conclusion…

  • francois

    I think that PS2 programmers are already familliar with that programming paradigm. They certainly need to think parallel processing when writing code for PS2’s Vector processing units. If my memory is good, they had 3 VPU where they could store routine (16KB max) to perform parallel operation. That is why the PS2 was banned in some contry for its super computer virtue, probably only because it featured parallel processing capabilities.

    Let’s not forget, there is bright people in the computer science industry, and new hardware always end up being push to the limit by programmers no matter how hard it is.