Why use delta time(dt) if the framerate is locked?

Solar2D General Questions/Discussion
#1

I see many posts and examples using delta time to affect object speed. This makes sense if the fps is variable/unlocked, but Solar2d is fps locked at either 30 or 60 via config.lua is my understanding. So why do this?

If the game generates frames slower than required: the whole game slows, basically changing the definition of a second to whatever is needed by the device to finish on time. It can make sense to use delta time to smooth out any bumps when running in this range. Additionally if u are just in general close to running the frames ‘on time’ it can makeup for that 10-15% difference so u don’t have to experience the slightly slower movement visually while you play.
But the game logic will still run slower, and the game will break if the value balloons without a cap…and it begs the question why ur game logic isn’t just written that way to begin with if it still works. I would think it would make more sense to monitor delta time independently and then manually identify less important high cost operations to frameskip like pathfinding or auto-targetting etc (i.e. your device generates frames 20% slower than the game requires…ok then let’s only run pathfinding once every two or three frames to help speed u up).

Then there’s the other situation which I understand even less as to why: when u are always creating frames under the minimum time. If you apply delta time to ur movement operations in this situation you are literally slowing your movement speed. At a fixed fps that only makes sense to me if the engine is generating and displaying those 60 frames at weird intervals…something that doesn’t seem to be true from my testing:

06:39:45.462  frames:236 time:3998.9 dt:0.92400000000001 ttl_dt:3.7397 fps:60
...the values in-between were very similar no major jumps...
06:39:46.462  frames:298 time:4998.8 dt:0.94800000000001 ttl_dt:4.7229 fps:60
i.e. from 4s to 5s in the simulator we had 62 frames created 6% faster than necessary

I’m assuming solar2d is preventing you from creating frames too much faster than is required (delta time has stayed between 0.9 and 1.0 for me so far). I’ve never seen dt used at all in pico8 games which also run at fixed 30 and 60fps. What am I missing (I’m using the linked post’s notation)?

#2

Frametime and framerate are both never constant. To keep magnitude of any movement inside the game independent of these variations, you use delta time.

Solar2D seems to allow a fps cap at 30 or 60 fps but it doesn’t guarantee perfectly constant frame times

As for whether you should use fixed time steps or delta time, it depends on your game and its performance on the target platform. If you are achieving your target fps all of the time and notice that things run smoother when you use a fixed time step, you can do that.

Also, how are you computing dt? 0.92s, 0.94s don’t seem correct if you’re running at 60fps unless I’ve missed something

1 Like