Tech Focus: Motorstorm Apocalypse
From first impressions of the PS3 to stereoscopic 3D and 1080p
Yes. If we stayed at 1280x720 for 2D, it would inevitably mean a compromised 3D experience. We saw it as an opportunity to improve our 2D experience though. This is a gross oversimplification, but 1280x1080 is exactly the same number of pixels as 960x720x2 - so that's what we targeted, although in the end it became 1024x720x2 due to some boring alignment reasons. Of course we also wanted to add dynamic lighting, improve our shadows, fix our particle halos, add MLAA and add SSAO. It goes without saying that we're not sane.
We'd rather have a four-player experience with some compromises than not have it at all.
Oli Wright, lead graphics programmer, Evolution Studios
With a game like Apocalypse, it's incredibly difficult to guarantee the RSX rendering time for any given frame up-front. The frames are just so variable, primarily because of the vehicles. We like to have lots of vehicles on screen, and often they're close to the camera, and quite often engulfed in a fireball. So we have two choices. We either make everything so cheap that we can draw our most expensive frame still within budget, or we scale back the rendering for frames that we think are going to be over budget.
We hugely prefer this latter approach. It means the RSX is close to being maxed out far more often, without losing frames. If we didn't do the dynamic detail scaling, then it would mean that the RSX would be idle for a lot of the time to give us the headroom for our variable frame cost, and frames that were more expensive than we considered for would tear and frame out.
We do use dynamic resolution changing in 2D - but we've tried to budget things so it only kicks in in exceptional circumstances. When you play the game, it's really hard to notice it happening unless you have a little flashing light that pops up to say 'dynamic resolution active!' Our rule for anticipating the RSX rendering time is simply to assume that the current frame will cost the same as the previous one, unless there's a camera cut. It's a bit basic, but it works very well.
Split-screen is, obviously, a nightmare. We have lots of things that we can scale back to make four-player split screen possible. LOD biasing, shadow resolution, shadow range, SSAO and motion blur. So the visuals are compromised in four-player, but we'd rather have a four-player experience with some compromises than not have it at all.
If you have a peer-to-peer architecture then yes, there will be an exponential increase, and you do run the risk of saturating the upstream bandwidth on a consumer connection, and introducing latency. However, since we have a client/server architecture there is no exponential increase in network traffic - only a linear increase in upload.
The only major pixel-pushing task that we run on SPU is the MLAA. The SPUs are mostly occupied with physics, vehicle simulation (which runs at 600Hz), animation processing, particles, scene processing and rendering preparation. They're certainly not sat idle. If the SPUs were tied up doing lots of work off-loaded from the GPU, then we'd need to have much simpler worlds with far fewer dynamic objects. That wouldn't be MotorStorm. As it stands, we have worlds with over 2000 dynamic objects in them.
The MLAA processing itself wasn't upgraded, it just took 50 per cent longer to run. So we had to find the SPU time and the XDR memory to make it work.
We have a couple of tools to try to make sure that the performance of world rendering in particular is as consistent as possible. The first is a world benchmarking tool that runs a camera through the world along all possible routes, timing various GPU phases and reporting on hot and cold spots. The second is a tool called The Auditor that gives a more spreadsheet type breakdown of a resource usage for a world.
I don't think we'd ever be complacent enough to say that any particular area can't be improved upon. There are always things that can be done better. A major area for us that we know we need to improve on is that of world production - our existing process is simply too labour intensive.
In terms of exploiting the hardware better - yes - there are always things you have in your mind that could be done better. But there's always a difficult balance to strike between making something that's production ready versus blue sky experimentation.