Fixed timesteps and rendering interpolation

Two clocks, one game

A display frame and a simulation tick answer different questions: when can another image be shown, and how far should game rules advance? Treating them as the same event makes frame pacing part of gameplay. Design a fixed simulation schedule first, then decide how rendering observes it.

Accumulate and interpolate

An accumulator collects elapsed time and consumes whole steps of duration h; any remainder survives into the next frame. A catch-up limit bounds work during overload. [1] Rendering can blend the previous and current simulation transforms using alpha = accumulator / h, while authoritative simulation state remains separate. [2]

Worked example

Consider an illustrative game with h = 20 ms. The accumulator contains 6 ms when a 29 ms display interval arrives. Its new total is 35 ms: execute one simulation step, leaving 15 ms, so alpha = 0.75.

If the previous position is 2.0 m and the current position is 2.4 m, linear interpolation displays 2.3 m. That is a presentation sample between completed states, not another physics update. Preserve both states until the next tick. Never feed the blended position back into collision detection.

Implementation workflow

Choose one owner for time measurement and record input against simulation ticks. Within each tick, copy the current renderable state to the previous buffer, run gameplay and physics in a documented order, then publish the new state. Render from those buffers without changing them.

Make overload behavior explicit. For example, a maximum of 4 steps per frame processes at most 80 ms in this design. If more time remains, choose whether to retain debt, discard excess elapsed time, or enter a controlled slowdown. These choices change timing; log when they occur. If retained debt exceeds one step, do not blindly use it as an interpolation fraction.

Boundaries and checks

This previous-to-current blend presents an earlier simulation instant. Assess that delay separately from input response. Reset both render samples when teleporting, respawning, or loading a scene so the renderer does not animate an unintended journey.

Test uneven display intervals, a long pause, and consecutive overloaded frames. Inspect tick counts, remaining time, and visible motion together. A fixed timestep alone does not establish deterministic replay: random inputs, operation order, and external state still need consistent handling.

Sources

[1] Fix Your Timestep! — Glenn Fiedler.

[2] Physics interpolation introduction — Godot Engine documentation.