Solved in Defold 1.2.126
4 Likes
I’m making a Facebook Instant game. When using go.animate on iOS devices on battery saving mode (and thus locked to 30fps) the animations take twice as long. When “Variable Dt” is ticked in the project settings they appear to take the correct amount of time, but the animations are choppy.
Equally, on my external monitor the game runs at 75 fps and the animations are too fast when “Variable Dt” is unticked.
Could this be related to the discussions in this thread, or is this expected behaviour? If so, what’s the correct way to deal with this? I’m using Defold 1.2.140.
We will release support for variable refresh rate screens soon. Most likely in 1.2.142, in two weeks.
Not sure about iOS battery saver mode though. @Johan_Beck-Noren?
3 Likes
variable_dt should be a solution for most cases since it measures actual time elapsed for the time step used. Can you describe more how the animations are choppy? Choppy as in unstable just 30fps-choppy?
1 Like
Amazing!
Choppy as in skipped frames; the animation is stable but not smooth.
Well to be more precis, we will soon support monitors that run at a refresh rate ≠ 60 Hz. Supporting monitors utilising full variable refresh rate (e.g. Nvidia Gsync or AMD Freesync) is still a way off and has not been designed as of yet.
3 Likes
Will this also affect Facebook Instant games on iOS devices?
Because go.animate is time based, shouldn’t the animations take the same amount of time, regardless of framerate?
It is time based, but tied to a timestep dt. This allows to for example pause a collection or let it run in slow-mo. “variable_dt” measures actual time which is more robust under different setups (vsync on/off in driver settings, low bat mode etc.) but can cause issues with physics if there are large differences in frame time since the same dt is used for all system throughout the engine.
In the future we should decouple our physics more from the timestep, either by handling short/long frame times in a nice manner or putting it on a separate thread.
Okay, I’ll have to experiment with this to make it work as intended. I can’t easily use delta time in my game, because I calculate a lot of things in only one frame. I may have to grab the average delta time and use that.
Hmm how do you mean? Can you describe what you are trying to solve?
Basically I’m trying to make go.animate run smoothly on Facebook Instant on a variety of devices, including the low power mode on iOS.
To exclude that I’m doing something silly in my game that eats CPU/GPU, I’m making a test project now. I will be back!
So I’ve thoroughly tested this on a number of devices loading a Facebook Instant game. On iOS devices there is an initial 1-2 stutter, where framerate drops/frames are skipped. After this period it stabilises and runs smoothly.
After removing culling code I was running every frame, my game also behaves like above. I’m starting a new topic for that here: To cull or not to cull
Thanks!