When a streamer with a monitor, which had a higher framerate than my monitor, played my Ludum Dare submission, I knew I’d screwed up somehow. Everything was incredibly fast and he died almost instantly. I apologized, realizing I’d forgotten to calculate for variable Dt. I’m lucky though, because I mostly rely on real-time alarms. There wasn’t much to fix.
When I looked into the options, I noticed that there shouldn’t have been anything wrong when he played it at 144Hz. I had Variable Dt disabled and Update Frequency set to 60. Mousing over Variable Dt says that it uses real-time steps instead of Update Frequency. The way I understand that is that, with it off, the Update Frequency is used by the engine for Update(), so the game should have defaulted to updating every 1/60 of a second.
Am I misunderstanding, or did this not work as intended?
When “variable_dt” is NOT checked the engine rely on vsync updates, while at the same time assuming that the monitor refresh rate is 60Hz. Running on a monitor with for example 144Hz will result in 144 frames per second but still using a dt of 1/60 causing the game to step faster than intended. A temporary workaround would be to check ‘variable_dt’, but this needs to be fixed of course.
No progress yet I’m afraid, the issue has not been worked on other than having some discussions within the team before summer about possible designs for solving the problem. My guess is that we need to solve this together with handling monitors with variable refresh rates (some smartphones have this as well).
I’ll take another round with the team and see if we can prioritise this issue in our backlog.
We’ve bought some cool gamer hardware to help us test this. The Defold team is now proud(?) owners of a Razer gaming phone and a gaming monitor. Here’s proof:
any news/progress?