# Understand the clock inside a game loop
Every rendered frame gives the game a new elapsed time. In a variable delta loop, motion is commonly updated as position += velocity × frameTime. That keeps average speed close to the intended value when frames are steady, but it also makes one simulation update as large as the frame that produced it. A hitch is therefore not just a visual pause: it changes the amount of game time consumed by that update. # Compare variable integration with a fixed accumulator
A fixed timestep loop adds each frame duration to an accumulator, then repeatedly consumes a chosen step such as 16.667 ms. The simulation sees equal-sized updates, while the renderer can still present frames at a different rhythm. The leftover fraction stays in the accumulator for the next frame. When a long frame arrives, the fixed loop performs several small updates to account for elapsed time, which preserves the step size but can create a catch up burst. | Steady rendering | One update uses each regular frame duration | One or more equal steps consume the accumulated time | Both should follow the same motion closely. |
| Long frame | One large update can move an object too far | Several fixed updates catch up to elapsed time | Inspect drift and the catch up count together. |
| Different render rate | The update size changes with the frame rate | The simulation step stays the same | Fixed steps reduce render-rate dependence. |
| Delta ceiling | The variable update ignores time above the cap | The accumulator still receives the full frame duration | Use a clamp only when losing time is acceptable. |
# See what a frame spike actually does
At 60 frames per second, a regular frame is about 16.667 ms. With an extra 80 ms spike, one frame becomes about 96.667 ms. The variable model consumes that whole duration in one update. The fixed model consumes roughly six 16.667 ms steps instead. The total elapsed time can match, while the path taken through the simulation is different. # Read position drift and catch up together
Position difference is the variable path minus the fixed path. It tells you how far the two integration policies have separated, not which one is automatically correct. The catch up count tells you how much fixed work was required in a single rendered frame. A large difference points to visible motion divergence; a large catch up count points to a possible CPU budget problem. These are related, but they are not the same diagnosis. # Treat delta clamping as a policy
A clamp can stop a paused tab, breakpoint, or severe hitch from teleporting a character or sending a physics body through geometry. The tradeoff is that the variable clock then falls behind real elapsed time. If the game must preserve timing, use a fixed accumulator or another recovery policy. If the game must remain bounded and responsive, a clamp may be acceptable, but the lost time should be intentional. # Choose the loop for the job it protects
| Physics, collisions, or deterministic gameplay | Fixed timestep | Equal steps make the simulation less sensitive to render cadence. |
| Simple visual motion with no accumulated state | Variable delta | The update is small and usually does not need a catch up queue. |
| Gameplay simulation plus smooth rendering | Fixed update with interpolation | The simulation keeps its step while presentation hides fractional progress. |
| Recovery after a severe stall | A bounded catch up policy | Avoid turning one bad frame into unbounded simulation work. |
# Use a repeatable tuning workflow
Begin with no spikes and confirm that both paths agree. Add one repeatable hitch, then change its cadence to see whether the visible error accumulates or settles. Adjust the fixed step and inspect the catch up count before changing velocity. Finally enable the clamp and compare variable simulated time with wall time. This sequence separates the cause of a divergence from the policy used to contain it.
What this experiment cannot prove
The lab uses declared frame durations and a constant velocity, so it explains timing behavior rather than measuring a device or validating an engine. Real physics, input sampling, networking, interpolation, and a frame budget can change the best design. Use the result to form a hypothesis, then verify that hypothesis in the actual game.