     |
 |
 |
 | | | | |
 |
|||
 |
||||||
          |
 |
 |
||||
|
1. Framerate All the MotoGP games by Climax have to run at 60fps. It’s a completely non-negotiable part of the project. And so when, in January 2005, we sat down and hammered out the feature set for MotoGP’06 with THQ, the requirement of 60fps was writ large. Getting launch or near launch titles to run at 60fps is always going to be challenging. You start development on hardware (or sometimes an emulator) that bares scant resemblance to the final product – and final hardware usually only shows up very late in the cycle and even then you’re lucky if you get more than a handful of kits. In the beginning we planned fastidiously to hit the magical 60 mark, but at that stage we had little idea of the final hardware so our only option was to make all our assets scaleable. We’re lucky that all our tools are built around modelling higher order surfaces and so at a touch of a button we change a bike from 1,000,000 polygons to 1,000 polygons. The same goes for the environment. And our exporters will scale the textures or vegetation to whatever limits we desire. Basically, we thought we had all angles covered.
Now, I’m a console programmer as are most of my colleagues. It’s been 10 years since I released a PC game. This lack of PC experience led us to overlook something that would have been obvious to a PC coder. The single biggest performance drain on MotoGP’06 wasn’t the number of vertices or textures but the number of draw calls. In November 2005 our game was running at 12fps, with the render loop taking nearly 2 frames. That month news came through from Microsoft that the changes to the Xbox360 SDK that would allow us to circumvent these draw commands wouldn’t be ready in time for our launch. We were in very serious trouble indeed. Neil, one of our engineers, set about moving the render loop onto its own processor core. This was a major engineering challenge that took 6 weeks to complete, but even then the renderer was running over a frame. Another engineer, Matt, eventually solved the problem by writing an offline automatic occlusion system. It would travel round the track and take snapshots of the scene every few yards – and query the GPU to see which draw calls resulted in pixels being written to the screen. At run time it would not execute draw calls that didn’t contribute to the scene, and this cut our draw call count in half. The system has to revert back to frustum culling if you stray too far from the track. (Page 5/7)
|
|||||||||||||||
Features
Previous
|
|
|