Physics and Render Loops: Fixed vs. Variable Timesteps

1. The Problem with Variable Timesteps for Physics

In the last lesson, we celebrated how deltaTime makes movement consistent across different hardware. So, why is it suddenly a problem? While it's great for simple visual updates, it's detrimental to tasks that require precision and consistency, like physics.

The following video provides an excellent summary of the issues.

To summarize the key problems:

• Instability: A sudden lag spike can cause deltaTime to become very large. If you're updating position with position += velocity * deltaTime, a huge deltaTime can cause an object to teleport a large distance in a single frame. This can make it "tunnel" through walls or other objects, breaking your collision detection.
• Non-Determinism: The simulation's outcome can vary depending on the frame rate. Two players running the same game with the same inputs could see different results if their computers have different performance. This makes networked multiplayer, replays, and reliable bug reproduction nearly impossible.

2. The Solution: Decoupling Update from Render

The solution is to decouple our simulation logic from our rendering logic.

• Simulation (Physics): Will run at a constant, fixed rate (e.g., 60 times per second). We'll call this the "tick rate". Every update will use the same fixed dt.
• Rendering: Will run as fast as the hardware allows, using whatever time is left over.

This means we might run multiple physics updates in one frame if rendering is slow, or run zero physics updates if rendering is very fast.

To manage this, we use an accumulator. Think of it as a time bank. In each main loop iteration, we measure the real time that has passed (frameTime) and add it to our accumulator. Then, we check if we have enough "time" in the bank to perform one or more fixed-sized physics steps.

The following article is a classic in game development literature and explains this concept beautifully.

The core logic, which we will soon implement in C, looks like this:

// A constant representing our fixed time step for physics
const double FIXED_DT = 1.0 / 60.0; 

// The time accumulator
double accumulator = 0.0;

// In the main loop...
frameTime = calculate_how_long_the_last_frame_took();
accumulator += frameTime;

// Consume time from the accumulator in fixed-size chunks
while (accumulator >= FIXED_DT) {
    update_physics(FIXED_DT);
    accumulator -= FIXED_DT;
}

render_game();

3. Implementing the Fixed Timestep Loop in C

Let's translate this theory into code. We'll modify the main loop we built in the previous lesson.

First, define the constants for our fixed update loop outside the main loop. A tick rate of 60 Hz is a common starting point.

// main.c

// Add these new constants



#define PHYSICS_TICK_RATE 60
const double FIXED_DT = 1.0 / PHYSICS_TICK_RATE;

int main(void) {
    // ... window creation and other setup ...

    double lastFrameTime = 0.0;
    double accumulator = 0.0;

    while (!glfwWindowShouldClose(window)) {
        // --- Time calculation ---
        double currentFrameTime = glfwGetTime();
        double deltaTime = currentFrameTime - lastFrameTime;
        lastFrameTime = currentFrameTime;

        // Add the real frame time to the accumulator
        accumulator += deltaTime;

        // --- Input Processing (happens every frame) ---
        process_input(window);

        // --- Fixed Physics Update ---
        while (accumulator >= FIXED_DT) {
            // Update physics, game logic, etc. using a fixed time step
            update_game_state(FIXED_DT); 
            accumulator -= FIXED_DT;
        }

        // --- Rendering (happens every frame) ---
        render_game(); // We will need to modify this soon

        glfwSwapBuffers(window);
        glfwPollEvents();
    }

    // ... cleanup ...
    return 0;
}

Notice a few key changes:

1. We have a new function update_game_state(). This is where all deterministic logic, like physics, will go. It always receives FIXED_DT as its time step.
2. General process_input() can still happen once per frame. This is for checking button presses. The effect of that input (e.g., applying a force to an object) would happen inside update_game_state().
3. The variable deltaTime is now only used to feed the accumulator. It is no longer passed to our game logic functions.

4. The Final Touch: Smoothing with Interpolation

We have solved the physics stability problem, but we've created a new, visual one. Our physics state now only changes at discrete 1/60th-of-a-second intervals. However, our render_game() function is called at a different, variable rate.

This mismatch means the rendered object will appear to be "stuck" at its old position for a few frames, then instantly "jump" to the new one. This causes a noticeable visual stutter or jitter, even at high frame rates.

The solution is to interpolate the object's rendered position. When we render, we figure out how far we are, time-wise, between the last physics update and the next one. This value, often called alpha, will be between 0.0 and 1.0. We can then draw our object at a position blended between its previous state and its current state.

alpha = accumulator / FIXED_DT;

render_position = current_position * alpha + previous_position * (1.0 - alpha);

This is a classic linear interpolation, or "lerp". The resources below explain this final, crucial step.

This next video provides a practical demonstration of both the problem and the solution.

5. Putting It All Together

To implement interpolation, we need to store the state of our objects from the previous physics tick as well as the current one.

Let's imagine a simple GameState struct and see the final main loop.

// A simple struct to hold our object's state
typedef struct {
    vec3 position;
} GameObjectState;

// ...



#define PHYSICS_TICK_RATE 60
const double FIXED_DT = 1.0 / PHYSICS_TICK_RATE;

int main(void) {
    // ... setup ...

    double lastFrameTime = 0.0;
    double accumulator = 0.0;

    // We need two states to interpolate between
    GameObjectState previousState = { .position = {0.0f, 0.0f, 0.0f} };
    GameObjectState currentState = { .position = {0.0f, 0.0f, 0.0f} };

    while (!glfwWindowShouldClose(window)) {
        double currentFrameTime = glfwGetTime();
        double deltaTime = currentFrameTime - lastFrameTime;
        lastFrameTime = currentFrameTime;
        accumulator += deltaTime;

        process_input(window);

        while (accumulator >= FIXED_DT) {
            // Before updating, the 'current' state becomes the 'previous' one
            previousState = currentState; 
            
            // Update the 'current' state using fixed delta time
            update_game_state(&currentState, FIXED_DT); 

            accumulator -= FIXED_DT;
        }

        // --- Interpolation for Rendering ---
        const double alpha = accumulator / FIXED_DT;
        
        GameObjectState renderState;
        // renderState.position = currentState.position * alpha + previousState.position * (1.0 - alpha);
        // In C with glm, this is:
        vec3 scaled_current, scaled_previous;
        glm_vec3_scale(currentState.position, (float)alpha, scaled_current);
        glm_vec3_scale(previousState.position, (float)(1.0 - alpha), scaled_previous);
        glm_vec3_add(scaled_current, scaled_previous, renderState.position);
        
        render_game(renderState); // Pass the interpolated state to the render function

        glfwSwapBuffers(window);
        glfwPollEvents();
    }
    // ...
}

This loop structure is robust, efficient, and is the foundation upon which you'll build the rest of your game engine.

Conclusion

Congratulations! You have now implemented one of the most important architectural patterns in game development. By separating your fixed-rate simulation from your variable-rate rendering, you've created a system that is both physically stable and visually smooth.

Key Takeaways:

• Using a variable timestep for physics leads to instability and non-deterministic behavior.
• A fixed-timestep loop runs simulation logic at a constant rate (e.g., 60 Hz) for consistency.
• An accumulator is used to bank the real time that has passed, which is then consumed in fixed-size chunks by the physics simulation.
• Interpolation between the previous and current physics states is essential to smooth out rendering and prevent visual stuttering.

Preview of the Next Lesson:
We've established the core pulse of our engine. Now, we need something to simulate. What is an object in our game world? In the next lesson, we will begin answering that by tackling the learning outcome: Design a basic Entity struct to represent any object in the game world. This will be the fundamental building block for players, enemies, bullets, and everything else that exists in your game.