Tech Interview: Split/Second • Page 3

Digital Foundry gets technical with tech director David Jefferies.

Digital Foundry: What sort of physics system is in place?

David Jefferies: 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.

Digital Foundry: We seem to be seeing a slight reduction in vertical resolution on the Xbox 360 demo. Looking at your SIGGRAPH presentation, you talk about three render targets plus depth. The particle buffer must surely be factored in too. What's the situation here with 360? Is there an issue with eDRAM size limitations?

David Jefferies: 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.

The lighting system employed allows for hundreds of different light sources in night-time scenes.

Digital Foundry: Going forwards, with MSAA not being on friendliest terms with deferred shading (requiring more video RAM, bandwidth and tiling on 360), do you have any thoughts on replacing it with a more custom solution to AA? We're seeing some pretty sensational SPU-based custom AA on God of War III and LittleBigPlanet 2, for example.

David Jefferies: 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.

Digital Foundry: There's a lot of excitement on Twitter from game coders getting to grips with the PS3's SPUs. Where does that leave 360? Is there much more that can be extracted from the hardware with VMX128 and memexport for example? Is there a sense that CPU aids GPU with PS3 with the opposite situation kicking in on 360?

David Jefferies: 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.

Black Rock utilised the well-known Havok physics system for use in handling the objects in Split/Second.

Digital Foundry: How does PC factor in from a development standpoint?

David Jefferies: 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.

Digital Foundry: Let's talk for a moment about online gaming. There's a lot of controversy among gamers about the relative merits of performance on PSN and Xbox Live. What is the technical approach to developing for online - are we effectively seeing the same base online code for both Xbox 360 and PS3? Generally speaking, if there is a performance difference is it down to infrastructure?

David Jefferies: 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.

Digital Foundry: Finally, a question about the future. Is your engine specifically developed for racing genres? Or rather, can it be easily extended to other types? With Split/Second just about complete and ready to ship, what do you think you can do with the engine going forward?

David Jefferies: 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.

Split/Second is released on 21st May for PlayStation 3 and Xbox 360.

Sometimes we include links to online retail stores. If you click on one and make a purchase we may receive a small commission. For more information, go here.

Jump to comments (79)

About the author

Richard Leadbetter

Richard Leadbetter

Technology Editor, Digital Foundry

Rich has been a games journalist since the days of 16-bit and specialises in technical analysis. He's commonly known around Eurogamer as the Blacksmith of the Future.


You may also enjoy...

Comments (79)

Comments for this article are now closed. Thanks for taking part!

Hide low-scoring comments