Timestep isn't in seconds?

Questions
1

Not sure if I’m missing something here, but when I do something like the following:

local timer = 0.0 function update(self, dt) timer = timer + dt msg.post("@render:", "draw_text", {text = "Timer: " .. timer, position = vmath.vector3(200, 200, 0)}) end

The resulting printout is quite a bit faster than seconds. Is it supposed to be that way? If so, what is a good way to sync up results to seconds?

2

Is your monitor running at a higher refresh rate than 60 Hz? Does enabling “Variable dt” in your project display settings make any difference?

See also this thread: Why is the update speed too fast? (DEF-1785) (SOLVED)

4

Yeah, I’m using a 144hz monitor. Setting “Variable dt” fixes it. I was actually wondering about this: is there a difference in Defold between game physics update time and actual framerate? What if I want my game to take advantage of higher update rate monitors, but still run physics at 60hz?

5

See: Physics simulation rate — The updates are the same, with the same dt. I’m not the right person to answer your second question, but I’m guessing it’s a no.

I’m not quite sure how Defold limits the frame rate to be honest. I have a 75Hz monitor to test with. A windows desktop build with fixed dt seems to adjust and run fine on it, but an HTML version needs variable dt to run correctly.

6

Thanks for the info.

I wonder what the best practice is then. In that thread it is stated that it is always preferred to use a fixed time step, but if I do that it makes my game run way too fast on my monitor even when I have it set to 60hz. I want to make a fighting game and timing is extremely important in that genre.

7

Have to wait for Defold team to make the fix so you can use fixed rate properly.

8

@Johan_Beck-Noren Didn’t you start on the task of getting dmengine to respect the update frequency (although that was maybe only the headless version)?

9

Yes the design work for a fix is started, but no definite release date yet unfortunately.

1 Like