Blog by PS3 developer about game development (nothing new, just a good read)

RC Cola · Feb 16, 2006

I'm not sure if I ever mentioned him before, but Deano Calver is a Lead Programmer at Ninja Theory (currently working on Heavenly Sword for the PS3). He often posts on the Beyond3D Forums, posting under the name DeanoC usually. Along with that, he also has a blog, which is the reason why I'm even posting this. In his most recent blog post, he discusses some things about memory management for consoles, or more specifically, the PS3. As I said in the title, this actually doesn't really contain any new, groundbreaking info (although some things were interesting), but it is an interesting read if you'd like to know more about game development (and the memory management part of that specifically).

Here's the blog:
http://rattie.demon.co.uk/?p=43

You would think that as we get more and more memory in consoles, that memory management would get easier but alas its not to be…

PS3 has 512Mb of RAM in total, which is a sizeable chunk when compared with the last generation of consoles (64Mb in the Xbox). The problem is that, we want to do much more and we want to do it ‘easier‘.

So where does it all go…

Well first you have to OS thats going to take a bit of the apple. And its a sizeable chunk…

Then we need space for all these lovely HDR AA framebuffers and render targets.

Then we have textures and geometry and least we forget animation data and sound. These content items consume the vast majority of the RAM. Off the top of my head its in the region of about 300Mb in total! This is all streamed as well, so be glad you have a nice big disk (Edit: talking about optical disks i.e. Blu-ray) to put things on…

So whats left? This gets to be used by code and the actual run-time heap. And suddenly all those ‘high level’ C++ things don’t seem like such a good idea. XML, std::strings, std::maps etc. consume memory like its going out of fashion… then something wants some more for pushbuffers and havok wants some for collision meshes and then there are load buffers and etc.

The grand result is you find your way over memory budget and whats potentially worse, its a really hard problem to track. We are a big team that can produce far more resources than I (as Lead Programmer) can cope with… So I have to resort to forgetting all this new fancy PC techniques and falling back to the good ol’ fashioned console style system.

So no memory allocation in-game, fixed size heaps and linear (AKA frame) allocators for each sub-system. If something don’t fit, tough…
Of course its a harsh reality for some, given how many people who trained in a modern university are taught. To be clear I mean, taught badly. Quite a few university in the UK don’t even teach C++ let along C and ASM these days. What good is it teaching people in languages like Java and C# with garbage collectors when in some cases we don’t even have conventional heaps!

So my list of things to make games development on consoles easier…

Track everything - Every allocation, every free. Have different memory policies and make people stick to them. Its easier to keep to a limit, than have to scramble to make things fit later on. Decide early, how much memory each system gets and don’t budge unless the person is really convincing (Any of my team reading this… I have been known to take bribes )

Keep things simple - While fancy C++ is fun, avoid it if you can. STL and things like vtables can hurt you badly unless your very careful. Any bits you use, make sure you have custom memory allocators.

Don’t think its a PC - Running well on PC, tells you exactly nothing about the performance and footprint on a console. Its a hard real-time embedded system just like its ancestors. One early library call we used was an order of magnitude slower than the same code on PC, so something that took a couple of seconds (development only serialisation code) took minutes. Luckily the library was quickly fixed but there were a few scary moments for a while

Don’t forget the old stuff - Its really no different in many ways from PS1 and PS2. If it good on PS1 its likely still good today, just you can do it ALOT more times on PS3.

To be honest, it make me feel comfortable knowing its still the same stuff that important. Guess its means my skills aren’t quite yet ready to be put out to pasture, even if many of the younger programmers think I’m a bit mad when I talk about fixed sized array versus std::vector and C/ASM rather than C++.

One bit I don’t like about it though, is sometimes having to be the bad guy and forcing the team to do things the hard way… Lot of them are good guys but really don’t want to program in a console friendly fashion…

Prehaps the most interesting bit, is that like a console of yore, there is going to be a lot of mileage over the generations of games.

I’ll make a prediction for how PS3 games will evolve.
1st Gen: PPU used for most things with the SPUs just doing some heavy lifting
2nd Gen: PPU still dominant but SPUs doing a lot more tasks.
3rd Gen: SPU completely dominant with PPU now more of a game coprocessor.

I expect the third generation of PS3 titles will really shine, the first engine that is really SPU centric and just treats the PPU as a coprocessor is going to kick arse. The SPUs are fast like greased lightning but just require a different paradigm thats not going to be fully incorporated for a few generations…
Click to expand...

Deano also has at least one comment at the time of this post, so you can read the comments for more info.

I just highlighted some of the things I found interesting. Some it dealt with the PS3 to a degree (OS memory size, use of BR in games, evolution of PS3 games, etc.), while the rest kind of dealt with the differences between developing for a game console versus developing for a PC.

OldManBernie · Feb 16, 2006

Good point... real men code in C/C++ and knows how to garbage collect.

Fatty FatBastard · Feb 16, 2006

How is this possibly a "good read"?

You need to put all video game technical info in one thread. This stuff is really boring.

RC Cola · Feb 16, 2006

Well, I think it is a good read...about game development. If you're not into game development (or even software development in general), then that blog post is probably more boring than interesting. In fact, I do admit that I almost didn't post this for that very reason; however, I thought I'd give it a shot since it seemed like some people were interested in this kind of stuff.

As for a VG technical info thread, I don't typically post too much information that would be necessary for that. Or at least, I don't think I do; perhaps my definition of technical info is something a little different than what others consider to be technical info. The only thing I might post about in the near future that would be considered technical info (IMO) would be any information about the GPU in the PS3 (RSX)...which might lead to a discussion about the system as a whole, which I'm sure I'll probably offer comparisons to (most likely the Xbox 360).

BTW, for those interested in the blog, Deano kind of explained a bit at B3D why Heavenly Sword will apparently use Blu-ray as opposed to DVD:
http://www.beyond3d.com/forum/showpost.php?p=699247&postcount=68

Well there they very real bonus of being able to duplicate stuff to reduce seeks, you still as much compression in reality cos load times are the killer on all next-gen consoles.

The real benefit of big disks is mental... its one less thing to worry about, I have enough to things to worry about (you should see how much hair I have these days ) without figuring out how I'm going to make it fit.
Click to expand...

While I've always thought that next-gen games should have a next-gen optical format, I still thought that some of the early PS3 games might still use DVDs, especially something like Heavenly Sword. So it surprises me a bit to see BR support like this, especially with the reasoning Deano provided. I figured maybe he was alluding to better-than-expected load times offered by Blu-ray or something like that, but I guess any possible disadvantages for using the format (higher costs, possibly slower load times) are not that big of a deal, at least in this particular case. It may just be more of a mental thing for some developers, like Deano said.

Invisible Fan · Feb 18, 2006

I would love for developers to have a very good reason to require Blu-Ray sized disks....A hard drive was supposed to give most of these benefits!!

If texture size and quality reach that grotesque point where it becomes the main reason, then there's a huge problem with how games are made and sold....

I'm not a programmer, so I don't know any new possibilities to take advantage of the extra capacity offhand.

Keep It Simple Stupid....

RC Cola,

I dug up this thread to ask you if you had/wanted subscriptions to Game Developer or Computer Graphics World.

RC Cola · Feb 18, 2006

Invisible Fan said:

RC Cola,

I dug up this thread to ask you if you had/wanted subscriptions to Game Developer or Computer Graphics World.
Click to expand...

No, I don't have a subscription to either one, or any magazines now that I think about it. Sounds interesting though, definitely something I'll look into. Thanks for the heads up.

Rocket G · Feb 19, 2006

Fatty,

Unless you're a complete moron, you know these threads are video game threds before you open them.

So don't open 'em.

You don't see people ****ting on the multiple Texas Tech or fast food related threads you start, so quit being a troll.

Forums

Blog by PS3 developer about game development (nothing new, just a good read)

RC Cola Member

OldManBernie Old Fogey

Fatty FatBastard Member

RC Cola Member

Invisible Fan Member

RC Cola Member

Rocket G Member

Share This Page

About ClutchFans

Rockets Content

Support ClutchFans!