Digital Foundry: Conversely, where does this leave 360? Is it a literally a case - as many have said - that the advantages of the SPUs are matched by the more advanced GPU you have available in the Microsoft console?
Steven Tovey: The GPU in the 360 packs more punch than the RSX; this is well-documented, on the other hand though the SPUs in the PS3 are astoundingly powerful. I think there are certain techniques, such as God of War 3's MLAA that are just unfeasible on 360, but it works both ways, the 10MB of EDRAM in 360 makes 4x MSAA feasible.
For a cross-platform title like Blur it's really just a balancing act, we need to be mindful of the strengths of both platforms and play to them in order produce the same final frame on both platforms.
The really fun thing for us as a cross-platform developer is that the underlying techniques used to synthesise that image can be worlds apart depending on the platform, but look exactly the same to the player. For example, the 360 version of Blur performs the lighting on the GPU in a much more "standard" way, whereas the PS3 uses the SPUs.
In practice this means the PS3 version of Blur could push more lights than the 360, but it loses out in other areas such as the prohibitive memory footprint required for 4x MSAA. Basically any rendering tasks that are not implicitly tied to the rasterizer such as lighting and post-processing are going to benefit from the SPUs, but there are trade-offs to be made in other areas to get those benefits.
Digital Foundry: What is your fundamental approach to developing for the HD consoles? Criterion talked with us about the same code in almost all cases working on both platforms, with a lower-level manager distributing tasks between the available processors. What's your take on this?
Steven Tovey: It's a totally valid approach and in a lot of cases that will work just fine. We do have a similar scheduler-type set up here so we can essentially write cross-platform code that will be distributed across all the available processing elements.
In a lot of other cases though we will target the platform directly with assembly or intrinsics, this is a little more involved, but can be worth it for the extra speed-up we get in computationally intensive tasks such as the physics, lighting or other SPU-assisted rendering.
In the main the performance of a title is bound almost entirely by data-access patterns, so simply designing the data properly will get you most of the way there and mean that you don't always have to resort to lower-level optimisations (as fun as they are to do).
Digital Foundry: And where does this leave PC? Is it the case that developing for console inherently makes your PC version more efficient? Is Bizarre handling the PC version of Blur?
Charlie Birtwistle: Certainly the multi-threaded focus of the core components of Horizon, which is the physics, scene graph, and renderer, did result in improved performance on multi-core PCs with the exception of our renderer, which unfortunately we were not able to use multi-threaded on PC. This is because DirectX 9 doesn't support simultaneous rendering in the same way that the extended DirectX 9 on 360, and the low-level libraries on PS3, do.
So the PC version is slower at rendering on CPU than the console versions, but the speed of today's PCs mean that a reasonably up to date machine should still be able to run Blur at over 30 FPS on the highest detail settings, which is the same as the console version.
For older PCs we have a range of lower-detail settings so you can still get modest performance on some pretty old PCs. For future games we hope to support DirectX 11, which would allow us to do multi-threaded rendering on PC which would significantly improve frame rate for people with the latest and greatest kit. We developed the PC version in conjunction with another studio that helped out on compatibility and usability issues.
Digital Foundry: Bearing in mind how rich Blur is, the fact that you're v-synced on both platforms at native 720p and with accomplished AA is quite remarkable. In fact, from memory, I'm fairly sure all of your games on the HD consoles have been. Bearing in mind how many developers routinely drop v-sync when slipping below 30FPS, aren't you tempted to do the same? What are the challenges of sticking with v-sync?
Charlie Birtwistle: Sticking with v-sync results in a higher-quality experience for the user. We've read enough articles like ones by yourself lamenting the screen-tearing you get in many recent games, so this is something we were not willing to compromise on. The key to sticking with v-sync is that you simply cannot go over 33ms (for a 30FPS game like Blur) for rendering on either the CPU or the GPU.
This is something which a lot of studios simply don't have the time or discipline to enforce, so the quick and easy fix is to drop v-sync when you start framing out so you get a drop of a few FPS and tearing rather than dropping all the way down to 20FPS and maintaining v-sync.
In order to prevent going over 33ms you simply have to be very careful about what you are doing, make sure the artwork for the levels is consistently within the budgets you have set out, make sure particle effects and so forth are optimised and not generating crazy amounts of overdraw.
For Blur especially this was a challenge because we have to cope with the worst case of 20 cars all bunched up and hitting each other with power-ups, each of which adds particles and dynamic lights and so forth into the scene.
In order to not have to cut the detail right down across the board to deal with the worst case, what we do is employ a dynamic level of detail system. What this does is it looks at the time spent to render the previous frames, and then adjusts the detail across various systems when the frame time is getting close to 33ms. So it might reduce the draw distance of props/street furniture/trees/etc, it can turn on a quarter-resolution buffer to deal with lots of particle overdraw, it reduces the quality of the filters used in post processing, reduce the update rate of the dynamic environment map on the cars by 50 per cent and so on.
All in all this dynamic LOD system can claw back upwards of 10ms of GPU time when stuff is really going crazy, and hopefully when that happens the player is so busy battling other cars they don't notice that the detail has actually been turned down somewhat. This was a big help in maintaining a stable frame rate for both 360 and PS3 versions of the game.
Digital Foundry: You've got 4x MSAA in 360 Blur, with what looks like quincunx standing in on PS3. It's rare that we see 4x MSAA on PS3 - I think GT5 is probably the only time I've seen it in a (good) racing game. What are the challenges in using high levels of MSAA on PS3?
Charlie Birtwistle: On PS3 we actually use regular 2x MSAA, then we then apply a half-pixel offset with bilinear filtering late in the frame to very slightly blur the whole image to remove any remaining unsightly jaggies. We found this to produce a more pleasing result than quincunx.
As for 4x MSAA on PS3, this simply wasn't doable because of the additional memory requirements. A back buffer of 1280x720x4AA with depth buffer is nearly 30MB on PS3, whereas this is around 7MB on 360 because the multi samples are only ever used in EDRAM and combined as you copy to main memory, so AA doesn't require any additional memory. We simply couldn't afford such a large memory discrepancy between the PS3 and 360 versions because other systems all had tight budgets.
I imagine for PS3 exclusive games such as GT5 you can budget specifically for things like this, but with a multi-platform project such as Blur this simply wasn't possible.