Tech Interview: Split/Second

For the physics we use Havok, which is a good solution for both Xbox 360 and PS3. It means we can have hundreds of physically correct objects littering the environments with no slowdown and gives us one less thing to worry about.

The complexity of the rendering in Split/Second requires us to have over 70 render targets which eventually get composited together to form the final image. Neither the PS3 nor the Xbox 360 can accommodate that many render targets in video memory so there is a lot of copying of render targets between system and video memory.

You're right though; the Xbox 360 has a very slightly reduced vertical resolution running at 1280x672. This is to accommodate the high-precision render targets that we use for the gamma-correct rendering. We then apply a high-quality upscale to reach our output resolution of 1280x720.

Raw pixel resolution is only one of many factors that go to making a high-quality image. Just as important, if not more so, is the quality of the pixel itself. Gamma correctness, high-resolution lighting precision and good-quality anti-aliasing are all extremely important for the visual fidelity of the final framebuffer.

It's also worth bearing in mind that very few consumer LCDs actually have a pixel resolution of 1280x720 - they are almost all either 1366x768 or 1920x1080. So the consumer LCD will then perform another scaling operation before rendering the image visible to the user.

I think MSAA is still a pretty good solution to anti-aliasing (as explained earlier, you need to ensure you've got a gamma-correct renderer or it won't look right).

The reason it requires additional video RAM, bandwidth and tiling is because it works at the sub-pixel level (either two or four fragments per pixel) rather than the pixel level. If you want to reduce this overhead then you need to stop working at the sub-pixel level and that introduces a whole load of its own problems.

The SPU AA implementations that I've seen all work at the pixel level and in some instances can look really good but in other instances, particularly thin objects, look really bad because they don't have access to the sub-pixel information.

So I'm not totally sold yet but as always we'll be evaluating the state-of-the-art when improving our render engine. In our experience good anti-aliasing is just as much down to having good art assets as down to the hardware MSAA.

The 360 has a very powerful GPU which affords the developer a lot of flexibility about how to approach the rendering. We do offload some work to the CPUs but not as much as for the PS3.

They are very different architectures but after really pushing both consoles for Split/Second we don't get the feeling that one is more powerful than the other - they're just different and this needs to be remembered when designing engines for them.

With your specific examples, yes we do use a lot of VMX128 in performance critical parts of our code and we use memexport when defragging the textures in our streaming buffers (it's best for the GPU to perform this operation because then you don't get contention between the CPU and GPU as they try and access the same textures) and also as part of our tile classification system.

We work with an external studio on the PC port who takes the console versions as a starting point. This allows us to concentrate on the 360 and PS3 safe in the knowledge that it's in good hands.

Interesting, I've not encountered this controversy before. We use a piece of middleware called NetZ that handles the low-level interface with PSN and Xbox Live and it presents to the game the packets of data that we transmit. The game then uses these packets to keep in sync across whichever network it's using.

The only performance difference we get when online is down to the game rather than the network. Online gamers can trigger up to eight Power Plays at any one time which puts additional stress on the engine that we need to account for - in single-player it's rare to have more than two Power Plays triggered instantaneously.

The next step we want to take with the engine is not so much improving the efficiency and quality of the engine itself but rather improving the source data that's fed into it. The artists generate the source assets that the engine uses and we're keen to improve their workflow and their iteration times and the feedback that the tools give them about the quality of their assets and whether they're within budget or not.

This will be what makes the big difference in our future games.