Tech Interview: Crackdown 2

Three years on from its release and Realtime Worlds' Crackdown still commands an incredible level of respect from committed Xbox 360 gamers, and we count ourselves among its many fans. Indeed, the very first Digital Foundry feature in the now-regular Saturday slot was a tech retrospective of this very special game.

Now, finally, there is a sequel, courtesy of new development studio Ruffian Games, staffed by many of the people who helped create the original game. With the demo released earlier this week, and the first pressed retail copies of the game back in the hands of the developer just a couple of days later, Digital Foundry approached Ruffian to talk tech about the new sequel.

In this piece, studio head Gary Liddon, along with senior engineers Janq and Neil Duffield, talk us through some of the story behind the original game and highlight the major enhancements in the sequel. Sit back and enjoy: the Ruffians have been extremely open and candid about the development process.

Digital Foundry: Crackdown is probably one of the most beloved of Xbox 360 exclusives, and even to this day, there's still something very special and unique about it. Why did it take so long to get a sequel?

Gary Liddon: 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!

Digital Foundry: In the original Crackdown, there's a big credit for RenderWare, yet looking at the final game it looks like a state-of-the-art 360 title for its time, and it's difficult to discern where the Criterion code is used. What's the score there?

Janq: 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.

Gary Liddon: 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.

Digital Foundry: Wolfgang Engel's blog was where we first read about the concept of the light pre-pass rendition of deferred rendering with his work for GTA IV. Yet it seems that Crackdown's implementation predates this significantly. Can you tell us how and why this technique was chosen? What did you set out to achieve with it?

Janq: 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.

Digital Foundry: These days deferred rendering and light pre-pass in particular has gained an enormous amount of traction over the more traditional forward renderer. Is this something you could foresee happening in the development of the original Crackdown tech?

Janq: 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!

Digital Foundry: From what we've read about Crackdown in Engel's book, ShaderX7, the implementation of the black outlines and the general cel-shaded look seems to have been a difficult addition to the code and yet it's pretty fundamental to the look of the game. What were the challenges here and was the cartoon-style look always planned for the game?

Janq: 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.

Digital Foundry: Native 720p resolution with 2x multisampling antialiasing means you must be tiling from eDRAM. Bearing in mind the "unique for its time" properties of the Crackdown engine, was eDRAM a blessing or curse?

Janq: 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.