Can you expand on this? Is the timing off or are you just seeing tearing? Tearing would be an expected result when turning vsync off since drawing to the back buffer is no longer in sync with the monitor’s vblank.
So when I say stuttery I actually mean frame rate drops to 5fps or so; things still work but update very slowly. I’m assuming the syntax I’m using is wrong, so would like to know how to set Vsync off and frame cap to 0 programmatically?
If you disable vsync in game.project instead, is the behaviour the same?
When I set it in game.project (and not in code) it works as expected. I’d rather not do this, though, because on most devices Vsync at 60fps would work fine, so I’d prefer to detect the edge cases and set those to Vsync off and frame cap 0.
1 Like
Sure, I was just trying to figure out where the problem is 
It seems you found a case where we don’t use the correct state in the engine when vsync/framcap is set in runtime. Could you try swapping the order of the messages? E.g. set update frequency first and then swap interval.
2 Likes
Cool, will try that tomorrow!
Same result I’m afraid. I tested with @britzl’s metrics extension, and the framerate drops and keeps dropping to around 1fps with this code:
msg.post("@system:", "set_update_frequency", { frequency = 0 } )
msg.post("@system:", "set_vsync", { swap_interval = 0 } )
Hmm that sounds really strange, the above messages shouldn’t affect performance in that way at all. Are you doing lots of heavy-lifting in any script update? If you send me the project I can have a look.
I don’t think I’m overloading any update function, but just to be sure I created a project from scratch, and it shows the same issue:
Vsync framecap.zip (24.9 KB)
Is it my syntax, or something else?
1 Like
What happens is that instead of disabling vsync and measuring actual time, we disable vsync and try to respect the set framerate, e.g. 0 in this case. As a workaround you can do;
msg.post("@system:", "set_update_frequency", { frequency = 60 } )
msg.post("@system:", "set_vsync", { swap_interval = 0 } )
This will disable vsync and will try to respect the update frequency using software (timers & sleeps) instead.
2 Likes
Ok. Would this be equivalent to setting frame cap 0 in project.settings, or likely to be less “smooth”?
Not really equivalent, but kind of similar.
With vsync off, setting frame cap 0 in project.settings will let the engine update as fast as it can, with dt measured every frame (dt can vary from frame-to-frame). When setting to 60 the engine will update 60 times per second, using timers and sleeps, so you should get a consistent 60fps (or close to it) regardless (dt is fixed to 1/60).
3 Likes
Great, thanks! Will run with this and report back if I bump into any issues.
1 Like
I’m back! Power saving mode on iOS has become a bother, and I can’t seem to find any way to make it run faster than 30fps. It seems it’s hardware locked to 30fps, so this code in fact has no effect:
msg.post("@system:", "set_update_frequency", { frequency = 60 } )
msg.post("@system:", "set_vsync", { swap_interval = 0 } )
In my desperation I even tried to set frequency to 120, which made no difference.
After a bit more testing, its seems like the vsync flag can’t be set to 0 (off) if the Vsync checkbox was checked, or to 1 (on), if the checkbox was unchecked:
Hi, I’m trying to understand the problem.
Let’s forget about “set_update_frequency” and “set_vsync” messages for a while and try to use the only game.project settings. Because usually, we don’t need to change mode on the fly, and we can back to this conversation about the messages when we decide that this is exactly what you need.
I’ve tested on
XperiaZ5
Xiaomi Redmi Note 4
iPhone X
Everything works according to the table:
- Vsync is on - we update the engine depends on the device. Usually, it’s 60 times per frame, but when it’s an energy saving mode it could be 48 or 30, etc. or on a special device for gamers it could be 120, etc, it depends on the device.
dt = 0.016667 - dt variable is fixed on this value.
In this case, the game works fine only when the device has 60 MHz refresh rate.
In the energy saving mode, the game works slow, on gamers devices game works really fast.
- Vsync is off and FrameCap == 0 - we ignore vsync and update the engine as fast as we can.
dt = time from the last frame
Everything works fine with the same speed in any case.
- Vsync is off and FrameCap > 0 - we ignore vsync, and we’re updating the engine FrameCap times per second.
dt = 1/FrameCap
The game works with the same speed but the animation is too laggy - but it’s expected behavior because we don’t sync with the screen update.
For me, this configuration shows noticeable stutters on Facebook Instant export, especially when the orthographic camera zooms.
I’ve just understood that you are talking about html5, pls, mention that all the time, when you make a post with the bug report.
Because when you write iPhone we are thinking about native iOS application.
I’ll re-test it for html5
1 Like
Agreed and many humble apologies. I blame Facebook and their non-hardware-specific HTML5 platform! Thanks for helping with this.
1 Like
I’ve compared
phaser demo https://phaser.io/examples/v2/misc/pause-menu
and Defold html5 demo http://potatojam.com/games/vsync/
in the energy saving mode.
I can’t feel the difference.
When the device turns on the energy saving mode it reduces fps for the browser to 33 or 30 (depends on device), that’s why animation feels less smooth. But I can’t reproduce any extra lags or problems.
4 Likes