Adapting Physics Tick Rates Across Display Refresh Rates

Porting a video game between platforms with differing display refresh rates—such as moving from a 60Hz console to a 120Hz handheld or a variable-refresh PC display—frequently disrupts physics simulations tied to rendering loops. To maintain consistent gameplay, stability, and visual fluidity, developers decouple physics calculations from display frequencies. This overview explores the primary engineering strategies used to adapt physics tick rates across platforms, including fixed timestep accumulators, temporal interpolation, dynamic substepping, and deterministic lockstep preservation.

The Problem with Framerate-Coupled Physics

Early console games often tied simulation updates directly to the vertical blank interval (V-Sync) at a fixed 30Hz or 60Hz. When code calculates velocity using a hardcoded or variable frame time directly (position += velocity * delta_time), fluctuating or altered display rates introduce critical bugs:

  • Simulation Instability: Large frame drops cause massive delta times, leading to collision tunneling where fast-moving objects pass through geometry.
  • Speed Discrepancies: Running a 30Hz-coupled physics loop on a 60Hz display doubles the simulation speed unless explicitly scaled.
  • Non-Deterministic Behavior: Subtle floating-point differences and varying iteration counts alter trajectory paths, jump heights, and mechanics across different platforms.

The Fixed Timestep Accumulator

The standard solution for cross-platform physics is decoupling rendering from the physics simulation using an accumulator loop. Instead of advancing physics by the exact time a frame took to render, the engine advances physics in uniform, discrete slices (e.g., exactly 1/60th of a second, or 16.66ms).

The implementation relies on tracking elapsed real-world time:

  1. Measure the real-time frame duration (frameTime).
  2. Add frameTime to an accumulator variable.
  3. While the accumulator contains enough time for a fixed physics step (e.g., dt = 0.0166s), run the physics simulation and subtract dt from the accumulator.
  4. Clamp the maximum accumulated time to avoid the "spiral of death," where physics calculations take longer than the fixed step, cascading into performance collapse.

This guarantees that whether a platform renders at 30Hz, 60Hz, 120Hz, or 144Hz, the physics engine updates using identical delta values.

Visual Smoothing: Interpolation and Extrapolation

Because a fixed physics tick rate rarely divides evenly into every platform’s refresh rate, rendering directly after an update loop introduces visual stutter (micro-judder). For instance, running a 50Hz physics loop on a 60Hz display causes some render frames to draw without a preceding physics update, while others draw after two.

To resolve this, developers use linear interpolation (lerp) between physics states:

  • The physics engine maintains two transform states for every dynamic body: the previous tick’s state and the current tick’s state.
  • The remainder in the accumulator (the fraction of time left over that was insufficient for a full physics step) is divided by the fixed timestep to calculate an alpha factor between 0.0 and 1.0.
  • The rendering engine calculates the rendered transform:
    RenderPosition = PreviousPosition * (1.0 - alpha) + CurrentPosition * alpha

Interpolation introduces one tick of display latency. If input responsiveness is paramount (such as in competitive shooters or fighting games), developers use extrapolation to predict future positions based on current velocity, though this risks visual artifacts if sudden collisions occur.

Dynamic Substepping

For resource-constrained ports (such as moving from PC to mobile or low-power consoles), running high-frequency fixed updates can overwhelm the CPU. Developers often lower the baseline physics tick rate (e.g., from 60Hz to 30Hz) and implement dynamic substepping.

Substepping dynamically subdivides a single timestep into smaller, iterative substeps only when complex interactions occur—such as fast-moving rigid bodies, complex ragdolls, or dense particle collisions. This maintains performance across hardware tiers while preserving collision integrity.

Handling Cross-Platform Determinism

When porting multiplayer games with client-side prediction or lockstep networking, identical inputs must yield identical physics results on all platforms, regardless of the screen's refresh rate:

  • Fixed Tick Parity: The simulation tick must remain identical across all connected devices, regardless of local render rates.
  • Floating-Point Standardization: Differences in CPU instruction sets (e.g., x86 vs. ARM) can produce slightly different floating-point results. Developers use fixed-point math or strict IEEE-754 floating-point modes to avoid cross-platform desynchronization.
  • Separation of Concerns: Audio, visual effects, and camera smoothing are updated on the variable render thread, while gameplay logic, hit detection, and spatial queries execute strictly within the fixed physics cycle.