Game Development Reference

In-Depth Information

Earlier in the chapter, however, we introduced another factor to alter the velocity: the

damping parameter.

The damping parameter is used to remove a bit of velocity at each frame. This is

done by simply multiplying the velocity by the damping factor

p
= ˙

˙

pd

+ ¨

pt

[3.5]

where
d
is the damping for the object.

This form of the equation hides a problem, however. No matter whether we have

a long or a short time interval over which to update, the amount of velocity being

removed is the same. If our frame rate suddenly improves, then there will be more

updates per second and the object will suddenly appear to have more drag. A more

correct version of the equation solves this problem by incorporating the time into the

drag part of the equation:

p
=
pd
t

+
pt

[3.6]

where the damping parameter
d
is now the proportion of the velocity retained each

second, rather than each frame.

Calculating one floating-point number to the power of another is a slow process

on most modern hardware. If you are simulating a huge number of objects, then it

is normally best to avoid this step. For a particle physics engine designed to simulate

thousands of sparks, for example, use equation 3.5, or even remove damping alto-

gether.

Because we are heading toward an engine designed for simulating a smaller num-

ber of rigid bodies, I will use the full form in this topic, as given in equation 3.6.

A different approach favored by many engine developers is to use equation 3.5 with a

damping value very near to 1—so small that it will not be noticeable to the player but

big enough to be able to solve the numerical instability problem. In this case a varia-

tion in frame rate will not make any visual difference. Drag forces can then be created

and applied as explicit forces that will act on each object (as we'll see in chapter 5).

Unfortunately, this simply moves the problem to another part of the code—the

part where we calculate the size of the drag force. For this reason I prefer to make the

damping parameter more flexible and allow it to be used to simulate visible levels of

drag.

3.3.2

T
HE
C
OMPLETE
I
NTEGRATOR

We can now implement our integrator unit. The code looks like this:

Excerpt from include/cyclone/precision.h

/** Defines the precision of the power operator. */

#define real_pow powf