4
\$\begingroup\$

An object - a player or npc or whatever - has a position, direction and speed and such.

Before drawing each frame, we want to compute the current position of each object.

How do you do this?

If you take the elapsed time since last frame, you run the very real risk of the game running at the wrong speed if the frame-rate is very fast and the clock precision poor (as it often is on some platforms).

And how can you incorporate player controls such as the player wanting to go left or right (e.g. in a simple asteroids clone without ship inertia)?

Improve this question
\$\endgroup\$
7
  • \$\begingroup\$ I don't know any platform that doesn't offer sub-millisecond clock precision. What do you mean by "as it often is on some platforms"? \$\endgroup\$
    – sam hocevar
    May 18, 2012 at 10:17
  • \$\begingroup\$ @SamHocevar Google Native Client has been giving me problems; people have even managed to jump to ledges they shouldn't etc. \$\endgroup\$
    – Will
    May 18, 2012 at 10:52
  • 4
    \$\begingroup\$ So you mean that position += direction * speed * elapsed is giving you problems? \$\endgroup\$
    – David Gouveia
    May 18, 2012 at 11:15
  • \$\begingroup\$ @DavidGouveia yes; hence wondering what other approaches work better \$\endgroup\$
    – Will
    May 18, 2012 at 11:45
  • 3
    \$\begingroup\$ If your problem is the frame rate becoming too high, how about modifying your game loop to enforce a fixed frame rate? gafferongames.com/game-physics/fix-your-timestep \$\endgroup\$
    – David Gouveia
    May 18, 2012 at 11:51

1 Answer 1

Reset to default
1
\$\begingroup\$

First of all, the method of just using the elapsed time since the last frame should absolutely work just fine in 99% of all cases. If you're having problems, there's probably a bug in your implementation.

That said, this problem is generally referred to as numerical integration. Given a set of system dynamics (rules that define the next state of the system given the current state and a change in time), you have to compute the trajectory of the system over time.

The simplest method of doing this is called Newton-Euler. That method basically boils down to:

position[t + 1] = position[t] + velocity[t] * dt
velocity[t + 1] = velocity[t] + acceleration[t] * dt

It works as long as dt is sufficiently small. If Newton-Euler doesn't work for you, you generally move straight on to Runge-Kutta 4. RK4 is a little bit more complex. You will have to store not just the previous and next states of the system, but 4 more intermediate points between the previous and next. Essentially, RK4 tries to predit the next state of the system given the previous state and its derivatives. However, it requires you to be able to say what the position, velocity and acceleration of the object will be in the future as well as the present. This is easy in some systems (like orbiting bodies or falling characters), but is nigh-but-impossible when you've got stuff like collisions involved -- but otherwise it will give you nearly perfect results even when your timestep is quite large.

Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .