How Game Physics Ties Frame Rate to Benchmarking Speed

This article provides an overview of how game engines link physics calculations to frame rates and the resulting impact on computer hardware benchmarking. It covers the mechanics of the game loop, the differences between fixed and variable time steps, how uncapped frame rates alter simulation speeds, and why decoupling physics from rendering is essential for accurate, deterministic hardware testing.

The Game Loop and Frame-Locked Physics

At the heart of every video game is the game loop, a continuous cycle that processes user input, updates the game world (including physics), and renders the visual frame.

In older or specifically designed game engines, the physics simulation is tied directly to the rendering frame rate. In this "frame-locked" approach, the engine assumes the game will run at a specific speed, such as 60 frames per second (FPS). Every time the graphics card (GPU) renders a frame, the processor (CPU) advances the physics simulation by a fixed amount—specifically, 1/60th of a second.

When benchmarking modern hardware, testers usually uncap the frame rate to measure the maximum output of the CPU and GPU. In a frame-locked engine, if a powerful PC pushes the frame rate to 120 FPS, the engine still advances the physics by 1/60th of a second per frame. Because twice as many frames are occurring in one real-world second, the physics simulation runs at double the intended speed. Characters move twice as fast, gravity pulls harder, and the benchmark completes in half the time.

Variable Delta Time and Workload Scaling

To prevent simulation speed from changing when frame rates fluctuate, many engines use a variable time step, known as "delta time." With this method, the engine measures the exact amount of real time that has passed since the last frame was rendered and scales the physics calculations accordingly.

While delta time keeps the simulation speed consistent to the human eye, it creates a major issue for hardware benchmarking: workload scaling.

• Low Frame Rates: If a weak system runs a benchmark at 30 FPS, the CPU only calculates physics 30 times per second, moving objects in larger increments.
• High Frame Rates: If a high-end system runs the same benchmark at 300 FPS, the CPU must calculate the physics 300 times per second, moving objects in microscopic increments.

Because the physics are recalculated every frame, a faster GPU demands exponentially more physics work from the CPU. Instead of measuring how fast a system can complete a set workload, the benchmark inadvertently increases the workload the faster the computer runs. This creates an artificial CPU bottleneck at high frame rates, skewing the test results.

Floating-Point Errors and Determinism

Accurate hardware benchmarking relies on determinism—the guarantee that a test will execute the exact same way every single time it is run. Tying physics to frame rates via delta time destroys determinism due to floating-point math inaccuracies.

Computers have a limit to how precisely they can calculate decimals. When a benchmark runs at 300 FPS, the time between frames is a tiny fraction of a second (0.0033 seconds). Multiplying physics forces by such small numbers leads to rounding errors. Over the course of a benchmark, these rounding errors accumulate.

Consequently, a physics-heavy benchmark (like a building collapsing) will play out differently at 30 FPS than it will at 300 FPS. Debris may fall in different directions, causing different collision calculations, which alters the CPU load. If two computers are not calculating the exact same events, their benchmark scores cannot be fairly compared.

The Benchmarking Solution: Decoupled Fixed Time Steps

To ensure fair and accurate hardware evaluations, modern game engines and dedicated benchmarking tools decouple the physics engine from the rendering engine.

In this configuration, the physics simulation runs on a strict, independent timer (e.g., 60 ticks per second), regardless of whether the GPU is rendering 30 FPS or 500 FPS. The CPU calculates the exact same number of physics interactions per second on both a budget PC and a supercomputer.

To make the visuals look smooth at high frame rates, the engine uses interpolation. The GPU takes the previous physics state and the current physics state and draws the in-between frames smoothly. This allows the benchmark to accurately measure the raw rendering power of the GPU and the fixed logic processing of the CPU without the simulation speed breaking or the workload dynamically changing.