Tech Interview: Crackdown 2

Usually sequels don't happen because there's a lack of desire for a second outing from the developer, publisher or most importantly the general public. Strangely enough for Crackdown 2 that just didn't seem to be the case. The reasons I know for it are not happening for a while are mostly dull, boring, corporate ones mostly to do with unfortunate timing and strategic changes for some of the parties involved that made building a sequel not as attractive as it once may have been. It all worked out nicely in the end though!

Crackdown 1 was originally written using RenderWare but towards the end most of it was replaced, mainly for efficiency reasons. By the end almost none of the rendering was using RenderWare. The game data was also edited using RenderWareStudio but towards the end of CD1 this started to become unworkable - it was never designed to edit open-world type games and you couldn't even really see what you were doing because the game rendering was so different from the editor.

For Crackdown 2 we completely replaced the editor too - the designers can finally see what the graphics actually look like while they are editing (pretty much anyway), which is nice! There is almost no RenderWare code left in the game now, what little there is left we could not remove this time due to risk.

The RenderWare story with Crackdown is a bit long and painful. Initially the game was an Xbox title using RenderWare 3. It then migrated to Xbox 360 onto a very early version of RenderWare 4. Unfortunately RenderWare 4 was then cancelled by EA and that left a massive Guatemalan sinkhole sized void in the game's technical armoury. It was a bit of a disaster.

Actually the deferred lighting in Crackdown is basically a post effect. The depth pre-pass writes out a surface normal per pixel and during the opaque pass the shaders perform directional lighting but write out the brightness of the original diffuse colour to the alpha channel. The lighting pass reads this and performs additive lighting; it cannot do specular lighting and the result it gives is not 100 per cent correct, but it works well enough. The lights can also be volumetric: for example, the car headlights which have an inscatter and outscatter component.

The original code was written by Hugh Malan at Realtime Worlds. The reason he chose that technique was performance - I don't think any other technique would really allow so many dynamic lights. Since it's all done in screen space the lights are fairly cheap (until you have lots of large overlapping ones anyway). One downside is the requirement to write out the normals during the depth pass, but to be honest it became clear on CD2 that the depth pass was mainly bottlenecked by vertex processing anyway so it's actually quite a good trade-off. The normals get used by several other things too: the outline and shadow passes for example.

On CD1 I mainly worked on optimising it - near the end we had to halve the resolution of the light pass to manage to keep the game near 30FPS at night. On CD2 I optimised it again and managed to be able to put it back to full resolution, although the car headlights are still half resolution because it's easier to get into situations where they cover the entire screen.

I think deferred lighting is the way forward really - it works out a lot cheaper when you have a lot of lights and it means you don't have to split the geometry up so much. I'm not completely sold on fully deferred rendering because you are limited to what information you can store in the render targets and obviously more or larger render targets means lower performance. Another issue with fully deferred rendering is that it doesn't interact well with MSAA, although some new features in DirectX 10 and DX11 go some way towards solving that - at a price though. However, I have never implemented fully deferred rendering on 360, so maybe I'm completely wrong about this!

It's not especially difficult to draw the outlines, but it is quite difficult to get them looking nice. They tend to add aliasing to the image especially in the middle distance. It was tweaked many times on CD1 and again for CD2. The CD2 outline pass costs about 2ms which is fairly expensive. The cartoon-style look was always planned for CD1 - I think the idea was to make it look like a comic book.

Yes, we use two tiles (one 1280x484 at the top and one 1280x240 at the bottom). Personally I think eDRAM is a blessing on 360 because without it fill rate would be a lot lower, and zero overhead alpha blending is always nice. Tiling can really hurt performance though because it can often nearly double vertex overhead - this hurts most during the depth pre-pass where vertex processing can actually become a bottleneck.

There isn't really any good way to split the tiles either - in CD2 the worst case is when you point the camera up around 30 degrees because then lots of stuff in the distance starts to straddle the two tiles. There are many tricks you can play such as drawing the bottom tile first, or splitting the tiles vertically instead of horizontally, but in the end you can always find situations where lots of things straddle the tiles and you pay twice the cost for the vertex processing and associated overhead such as state traffic, etc.

I think it was definitely the right choice to go with the eDRAM-based design - 360 GPU performance probably wouldn't be anywhere near what it is without it - and they could only afford to put 10MB in there, so developers just have to deal with that. Microsoft has done an excellent job at making predicated tiling easy to use and there is very little CPU overhead. I do hope that the next Xbox (if it uses an eDRAM-like design) has enough memory to fit the standard resolution with basic MSAA though.