Game Development Reference
In-Depth Information
Having stabilized the major problems out of our engine, we can turn our attention
to optimization. There is a wise programming adage: Always avoid premature opti-
mization. Nowhere is this more important than in games.
As game developers we have a pressing need for fast and efficient code, and this
can spur you into optimizing code as you write. This is important to some extent, but
I've seen many cases where it consumes vast quantities of programming time and ends
up making negligible difference to code performance. With all code optimization it
is crucial to have a profiler and check what is slow and why. Then you can focus on
issues that will improve performance, rather than burning time.
The engine presented in this topic has many opportunities for optimization.
There are quantities that are calculated several times, data storage that is wasteful,
and extraneous calculations that can be abbreviated and optimized. The version of
the engine built for this topic is meant to be as clear and concise as possible rather
than fully optimized for performance.
At the end of this section I will look briefly at some of the areas that could be
improved for speed or memory layout. I will not work through the details of the
more complex ones, but will leave them as an exercise if your profiler is telling you
that it would help.
There is one key optimization we can make first that has such a dramatic effect
on the overall performance that it is worth looking at in detail. This isn't a code opti-
mization (in the sense that it doesn't do the same thing in a more efficient way) but is
a global optimization that reduces the physics engine's workload.
There is a saying in graphics engine programming that the fastest polygons are those
you don't draw. Quickly determining which objects the user can see, and then ren-
dering only those, is a key part of rendering technology. There are dozens of common
techniques used to this end (including some we've seen in this topic, such as BSP trees
and quad-trees).
We can't do exactly the same thing in physics: otherwise, if the player looked away
and looked back, objects would be exactly as they were when last seen, even if that
was mid-collapse. The equivalent optimization for physics engines is to avoid simu-
lating objects that are stable and not moving. In fact this encompasses the majority of
objects in a typical simulation. Objects will tend to settle into a stable configuration:
resting on the ground or with their springs at an equilibrium point. Because of drag,
only systems that have a consistent input of force will fail to settle down (the force
may be gravity, however—a ball rolling down an infinitely long slope will never stop,
for example).
Stopping the simulation of objects at rest is called putting them to “sleep.” A pow-
erful sleep system can improve the performance of a physics simulation by many hun-
dreds of times, for an average game level.
Search Nedrilad ::

Custom Search