An example implementation of automatically-calculated delta time in Pico-8, allowing for framerate-independent game logic.
It's not much to look at, but a detailed description is available in the code comments.
Example use case:
You've built a project targeting 30FPS, but it turns out to be optimized enough to run at 60FPS.
Normally, switching from using _update to _update60 after the fact would be a painful job involving a lot of manual number editing, and you'd be screwed. However, if you had built your project with delta time in mind from the start, you could simply rename and everything will continue to move at the 'correct' rate.
This is a very useful tool to have in your arsenal, but I do want to point out a gotcha which is sometimes overlooked in specific cases:
When you go variable-DT, you lose the ability to be repeatably deterministic. This is fine for most games, but any game with a replay system or, perhaps, a multiplayer game that assumes both ends are computing the same derived values from the small amount of data that's communicated across a network, it can be an issue. It's very common for math applied two times to be different from math applied twice as hard, due to precision issues.
I'm only bringing this up so you're all aware of this gotcha IF you're writing such a game. Otherwise, this is definitely something you wan to be familiar with. Even in a deterministic game where, say, you have replays, you'll still have tons of non-critical systems that can run on variable DTs, e.g. particles, weather, sfx, etc.
It can be especially important to pay attention to random seeds. Most people just call an API function like rnd() without thinking twice, but if the pattern of calls to rnd() change due to variable DT, that's another possible source of deviation from the expected behavior of, say, a replay. So it's common to have separate random seeds for the deterministic stuff and the variable stuff.
[Please log in to post a comment]