Every real time engine — whether for games, physics simulations, or visualization — must solve one fundamental problem:

This article explains:

• how time works in a real time engine
• why fixed timesteps matter
• how rendering and simulation interact
• how to design a deterministic update loop
• how to avoid jitter, drift, and instability

This is the foundation for the physics module, the renderer, and the entire engine runtime.

Real time engines run in a loop:

while (running) {
    process_input();
    update();
    simulate();
    render();
}

But the timing of these steps determines:

• stability
• determinism
• smoothness
• correctness
• performance

Time is not just a number — it is a design constraint.

There are two main approaches to advancing time.

1. Variable Timestep (Δt changes every frame)

Definition

Each frame uses the actual time elapsed since the previous frame:

float dt = time_now - time_prev;
simulate(dt);

Pros

• simple
• easy to implement
• works for basic animations

Cons

• physics becomes unstable
• collisions become inconsistent
• determinism is impossible
• fast machines behave differently than slow ones
• simulation results drift over time

Variable timestep is not acceptable for physics simulation.

2. Fixed Timestep (Δt is constant)

Definition

Simulation always advances in fixed increments:

const float dt = 1.0f / 60.0f; // 60 Hz simulation

Rendering may run at 144 FPS, but simulation always runs at 60 Hz.

Pros

• deterministic
• stable physics
• reproducible results
• consistent collisions
• predictable behavior

Cons

• requires an accumulator
• slightly more complex

Fixed timestep is the correct choice for the GusOnGames engine.

This is the industry standard solution used by:

• Box2D
• Bullet
• Unity (internally)
• Godot
• Unreal (in certain subsystems)

1. The Pattern

float accumulator = 0.0f;
float dt = 1.0f / 60.0f;

while (running) {
    float frame_time = time_now - time_prev;
    time_prev = time_now;

    accumulator += frame_time;

    while (accumulator >= dt) {
        simulate(dt);
        accumulator -= dt;
    }

    render(interpolate(accumulator / dt));
}

2. Why it works

• simulation runs at a fixed rate
• rendering runs as fast as possible
• interpolation smooths motion
• determinism is guaranteed
• physics is stable

This is the loop we will implement in the engine.

The time module belongs in the platform layer because:

• it depends on OS timing
• it is needed by both renderer and simulation
• it must be consistent across modules

1. Required API

namespace btg_platform {
    void start_timer();         // initialize timer
    double get_elapsed_time();  // get elapsed time in seconds since last call to start_timer or get_elapsed_time
    double get_last_elapsed_time(); // get the last elapsed time without resetting the timer
}

2. Responsibilities

• track current time
• track previous frame time
• compute delta time
• provide high resolution timing
• remain platform agnostic

3. Implementation Notes

• use std::chrono::high_resolution_clock
• convert to seconds
• avoid OS specific APIs
• avoid floating point drift by using double internally

Determinism means:

This is essential for:

• physics correctness
• debugging
• replay systems
• network synchronization
• simulation tools
• educational demos

1. Sources of Non Determinism

• variable timestep
• floating point drift
• inconsistent update order
• random number generators
• multi threading (not used yet)

2. How We Guarantee Determinism

• fixed timestep
• stable math operations
• predictable update order
• controlled randomness
• single threaded simulation

This is why the engine’s architecture is designed the way it is.

Rendering runs as fast as possible:

• 60 FPS
• 120 FPS
• 144 FPS
• 240 FPS

Simulation runs at a fixed rate:

• 60 Hz
• 120 Hz (optional)

1. Why They Must Be Separate

Rendering is visual. Simulation is logical.

Rendering can interpolate. Simulation cannot.

Rendering can skip frames. Simulation must not.

2. Interpolation

To avoid jitter:

render(interpolate(alpha));

Where:

alpha = accumulator / dt;

This blends between:

• previous simulation state
• current simulation state

This produces smooth motion even when simulation runs slower than rendering.

Here is the final loop that the GusOnGames engine will use:

float accumulator = 0.0f;
const float dt = 1.0f / 60.0f;

while (window.is_open()) {
    Time::update();
    float frame_time = Time::delta();

    accumulator += frame_time;

    input.update();

    while (accumulator >= dt) {
        simulation.update(dt);
        accumulator -= dt;
    }

    float alpha = accumulator / dt;
    renderer.render(alpha);
}

This loop is:

• stable
• deterministic
• smooth
• predictable
• engine ready

This article defined the time system for the GusOnGames engine:

• variable timestep is unstable
• fixed timestep is correct
• accumulator pattern is the gold standard
• rendering and simulation run at different rates
• interpolation ensures smooth visuals
• determinism is essential for physics and debugging
• the time module belongs in the platform layer

This is one of the most important architectural decisions in the entire engine.