Previous: Time-Stepping in Simulated Worlds.
Decoupling Refresh Rate from Simulation
That’s usually accomplished by rendering as fast as the hardware can, ideally at the refresh rate (or “VSYNC”, in reference to old CRT display), measuring the time elapsed since the last frame, accumulating that time and advancing the simulation in fixed time-steps.
This also means that you can safely decouple the time-stepping of visual effects and rendering from that of the simulation. The time-stepping of your simulation should be tied to the needs of the physics, while the rendering should be tied to the needs of the eye (or the capability of the hardware).
In practice, for some rendered frames, the simulation may not advance, and for others, it may advance several steps.
This can be the case if your simulation is fairly complex, and is only realistically stepped at 15 Hz, while visually you may want a smoother 60 FPS (or more). In those situations:
- the visual rendering will typically rely on “interpolation” to add the extra smoothness.
- each simulation progression step (at 60 Hz) will perform
- 1/4 of the complete simulation step if your engine is single-threaded
- a synchronization attempt if the simulation is multi-threaded
A simulation may (should?) involve multiple sub-simulations, that will run at various time-steps, for instance in a game you could have:
- collision-detection and physics for near objects evolving at 100 or 200 Hz
- AI and game scripts running at 30 Hz
- distant objects evolving at 10 Hz
- weather/environment evolving at 0.1 Hz
This is a simple way to focus processing resources on simulated aspects the protagonist(s) will see and interact with.
