Fixed time step vs Variable time step

What is better for games when developing game loops, fixed time steps or variable time steps? What type of games are better with one or the other?

Variable time steps:

With variable time step, I mean physics updates will take in some sort of "time elapsed since last update" argument and hence dependent on framerate. This may mean doing calculations as position = position + distancePerSecond*timeElapsed.

• pro: smooth
• pro: easier to to code
• con: hard to record/replay actions as time steps vary
• con: weird physics errors that are hard to predict with very small or large time steps

eg (from dewitters):

while( game_is_running ) {
    prev_frame_tick = curr_frame_tick;
    curr_frame_tick = GetTickCount();
    update( curr_frame_tick - prev_frame_tick );
    render();
}

Fixed time steps:

With fixed time steps, the update method may not even accept a "time elapsed" as it assumes that each update is for a fixed time period. Calculations may be done as position = position + distancePerUpdate. The example includes an interpolation during render.

• pro: physics are very predictable
• pro: easier to record actions per time step as they are fixed
• pro: possibly easier to sync up with other players over network?
• pro: don't have to confuse all calculations with timeElapsed variable everywhere
• con: it will never sync up vertical refresh so you either have jittery graphics or you have to always interpolate.
• con: maximum frame rate is limited unless you interpolate
• con: hard to work within frameworks that assume variable time steps (like pyglet or flixel)

eg (from dewitters):

while( game_is_running ) {
    while( GetTickCount() > next_game_tick) {
        update();
        next_game_tick += SKIP_TICKS;
    }
    interpolation = float( GetTickCount() + SKIP_TICKS - next_game_tick ) / float( SKIP_TICKS );
    render( interpolation );
}

Notes:

• Gaffer on games: Fix your timestep!
• deWitter's game loop article
• Quake 3's fps affects jump physics Allegedly this is one reason why Doom 3 is frame locked at 60fps?
• Flixel requires a variable timestep (I think this is determined by Flash) whereas Flashpunk allows you fixed and variable timesteps.
• Box2d docs seems to suggest that it likes constant time steps. See Simulating the World of Box2D
• 
  
• ANSWER:-.

There are two issues related to the question.

• Should physics step rate be tied to frame rate?
• Should physics be stepped with constant deltas?

In Glen fielder's Fix your time step he says to "Free the Physics". That means your physics update rate should not be tied to your frame rate.

For example, if the display framerate is 50fps and the simulation is designed to run at 100fps then we need to take two physics steps every display update to keep the physics in sync.

In Erin Catto's recommendations for Box2D he advocates this as well.

So don't tie the time step to your frame rate (unless you really, really have to).

Should Physics step rate be tied to your frame rate? No.

---

Erin's thoughts on fixed step vs variable stepping:

Box2D uses a computational algorithm called an integrator. Integrators simulate the physics equations at discrete points of time. ... We also don't like the time step to change much. A variable time step produces variable results, which makes it difficult to debug.

Glen's thoughts on fixed vs variable stepping:

Fix your timestep or explode

... If you have a series of really stiff spring constraints for shock absorbers in a car simulation then tiny changes in dt can actually make the simulation explode. ...

Should physics be stepped with constant deltas? Yes.

---

The way to step the physics with constant deltas and not tie your physics update rate to the frame rate still is to use a time accumulator. In my game I take it a step further. I apply a smoothing function to incoming time. That way large FPS spikes don't cause the physics to jump too far, instead they're simulated more quickly for a frame or two.

You mention that with a fixed rate, the physics wouldn't sync up with the display. This is true if the target physics rate is near the target frame rate. It's worse the frame rate is larger than the physics rate. In general it is better to target a physics update rate of twice your target FPS, if you can afford it.

If you can't afford a large physics update rate, consider interpolating the graphics' positions between frames to make the drawn graphics appear to move more smoothly than the physics actually moves.