What if I use delta time to just regulate framerate but not individual entities?

Question

What if, instead of multiplying all my values that change each frame by delta time, I just increased one number in increments multiplied by delta time, and used that number to advance to the next frame? What's really the drawback here?
As far as I can tell, the famous "Fix Your Timestep!" article doesn't mention this.

Basically, I had implemented everything using integer positions with the intent of making games that had a similar game feel to NES and GameBoy Color games. This worked perfectly when using frame delay, but when it came time to implement delta time, it wasn't as simple as just multiplying my velocities by delta time. It was so much more of a headache than it was worth.

So I was inspired by this video (specifically the part on random numbers) to come up with a dumb solution like so:

float dirty_delta = 0;

while (!done)
{
    float dt = get_delta_time();

    dirty_delta += dt * 60;

    begin_frame();

    if (dirty_delta >= 1)
    {
        update();
        dirty_delta = 0;
    }

    draw();

    end_frame();
}

After implementing dirty delta, the program appears to work just fine. So if all I care about is keeping the game loop from moving too fast or slow based on the user's machine, is this good enough for government work?

Answer 1

I do not know about government work, of which government, and which laws...

We can be sure there won't be an issue with not passing delta if:

• You know the hardware you are targeting, it has predictible performance, and a standard refresh rate.
• You can identify when a frame is taking too long and have a commitment to fix it before release.

Or from the opposite point of view, not passing delta has these possible drawbacks:

• If you decide to change the frame rate (e.g. porting to a different hardware, or if you want to make it match the refresh rate of the display) your code won't be able to adapt to that.
• When a frame is taking too long (either because the update code is a bottleneck, or because the OS/CPU/Other apps degrading performance), your code could not adapt to that. Arguably you might want this.

We can also argue that not using delta has a benefit: update code is simpler (e.g. we assume a constant delta, or hardcode values as if already multiplied by delta), and since it would be doing less (less multiplying by delta) it would perform better (if this improvement in performance is significant is a different matter).

Thus, not passing delta is a good option on limited hardware with fixed specifications, in particular when the game is the only thing running on the system (which is the case of old consoles).

---

I see that in the code you post you call draw every loop, thus the concerns about refresh rate might be mitigated already (I'm assuming draw hides logic for swapping buffers, checking for VSync, or similar). Consider if you can save time in redundant draws by using a similar structure to the one you use for updates.

And about the updates, as I mentioned above, perhaps what you want is that updates to not adapt to the timing between updates. For example, if a particular frame takes longer, you won't see entities doing a big step afterwards to compensate.

---

You could pick some minimum hardware specifications below which your game is not expected to perform well anyway, so you can take that as your target hardware, and if you can assure that your updates stay within their allocated time on that target hardware (barring OS/CPU/Other apps)… Then if there are performance degradations, at least your game is not to blame.

Doing that might require (depending on your game and the target hardware) techniques such as:

• Limit the number of entities in the game at any given time.
• If you allow more entities that can be updated then each frame a different subset gets updated.
• Or you might have some have a simple update (e.g. keep going the direction they were) and some have a complex update (e.g. do path finding).
• Speaking of complex updates, you might want to write it a way that can be halted and resumed on the next update.

Notice that these and similar techniques depends on the game, and as such a general purpose game engine cannot make promises about them, so it makes sense that game engines give you delta (another reason for engines giving you delta is that they might allow to export your game to different hardware and operating systems).

---

I cannot tell you if that is OK for your game. And your government.

And I remind you to test.