Game Loop Calculator

A fixed timestep loop decouples physics updates from rendering. Physics runs at a constant rate (e.g., 60 Hz) regardless of how fast the CPU renders. This makes simulations deterministic and reproducible — the same inputs always produce the same outputs. Variable-timestep loops can cause objects to tunnel through walls at low FPS or behave erratically at high FPS.

If the tab is hidden, the device sleeps, or there's a garbage collection pause, the next frame's delta can be enormous. Without a cap, your game might try to simulate 5 seconds of physics in one step, causing objects to teleport or explode. Capping at 250ms (a few frames) means the simulation just 'pauses' briefly rather than going haywire.

When your render rate (e.g., 60 FPS) doesn't divide evenly into your physics rate, there's leftover time in the accumulator at render time. The alpha value (0 to 1) represents how far between the previous and current physics state the render is. Interpolating renders smoothly avoids objects 'snapping' between physics positions.

Not necessarily. For browser games, 60 Hz physics with any FPS works well. For platformers, 60 Hz feels responsive. For physics simulations or racing games, higher Hz (120-240) reduces numerical error. For mobile or low-power devices, 30 Hz physics with 30 FPS rendering is common. The key is that physics Hz should be fixed and predictable.

Render scale lets you render at a different resolution than the display. At 75% scale, you render at 1440×810 and upscale to 1920×1080, saving ~44% GPU work. At 200% scale (supersampling), you render at double resolution then downsample for anti-aliasing. Dynamic resolution scaling adjusts this at runtime to hit FPS targets.

The 80% budget means leaving 20% of your frame time as a buffer. A 60 FPS target gives 16.67ms per frame. At 80%, your actual game code has 13.3ms. This buffer absorbs garbage collection spikes, driver overhead, system interrupts, and occasional expensive frames without dropping below target FPS.