Disable Vsync and use fixed time based framerate

How do you disable Vsync in C3 and lock dt? For certain games/applications Vsync+a variable dt doesn't cut it. If you want your game to have completely deterministic results you operate off of a fixed time slice. I see you can set the minimum dt to lock it under a certain fps, but how do you cap dt and the framerate on faster refresh rates as well? Ideally there should be a fixed framerate mode and an option to lock dt completely.

if you are talking about a framerate/tick cap or fix (at 30 say)

Exactly this.

but if you do this you would definitely be wanting to use dt for all movement and timing etc...

Unfortunately no, you would not want to to use dt for all movement and timing. It is not bad practice to use a fixed framerate, the only side effect is screen tearing which in my experience is almost completely unnoticeable. The other trade-off is slowdown when the game lags, instead of choppy movement. Both look and play equally bad in my opinion, and a lot of times slowdown is preferable, to keep the logic deterministic. With deterministic game logic you can do things like an input based replay system.

Ideally, games separate out the rendering and logic into two asynchronous tick updates, one fixed time-step for logic, and another vsync'd one (with dt) for graphical/ui/etc things which don't need determinism. Using interpolation you can get the graphics to move nice and smoothly at whatever refresh rate you want, while keeping a deterministic time-step for game logic. This allows you to keep the best of both worlds (no tearing+higher refresh rate graphics AND deterministic logic) Unfortunately Construct is more beginner targeted and does not use this type of system. It can be hacked in with events (kind of) but it won't always work well. The next best thing is just a regular fixed timestep, at 60 fps.

Sorry i deleted my post cos i said you could disable vsync in chrome flags but when checked i couldn't see it, it used to be there but it has been removed.

Yea i get you, i think the reasons you state maybe applied years ago for consoles when the hardware and performance was fixed.

They days your game needs to run on different machines with different specs.

weve already got a fix cap of 60hz on desktop. unless you are pushing really hard you are pretty much guaranteed 60. So you could go without dt and know what to expect. But i still wouldn't and def not for mobile where you dont know ancient devices and being used.

If you really want to run stuff only 30 times a second you could control that easily in events.

But Its not slowdown we have to worry about any more , it is speeding up.

pc gaming is now gone 120hz + with 144hz monitors the norm now. Consoles look like they are following suit as are no longer hosting fixed specs. browsers will likely follow soon enough and release the frame cap as well due to gaming

so to future proof your game you have to use dt.

Also I see no reason to separate game logic from drawing as your canvas will only change once your logic is done so the ideal situation is to render at the end of every tick. any other frames rendered on top of this are just redrawing the same thing that hasn't changed yet. so you wont see it.

I'm no expert tho, just my view....

They days your game needs to run on different machines with different specs.

Exactly, and a fixed timestep would fix this. It's not for every game but certain games might want it.

weve already got a fix cap of 60hz on desktop

Desktop isn't fixed to 60 though, on chrome on my 144hz monitor the framerate is 144 with vsync on. Anyways, suppose you could just throw everything you want with a fixed timestep into an every 1/60 seconds event and call it a day. If the machine lags, it'll execute once per frame anyway. If we had a way to lock dt in behaviors that would help, because then the logic in those would slow down as well, keeping everything deterministic. And if the framerate is let's say 120hz, frames will be skipped nicely. However... my next point:

I see no reason to separate game logic from drawing

Locking the event sheet rate to vsync rate has problems.

The problem is when the refresh rate is equal to something strange like 75hz (a common desktop rate), when you want a fixed 60hz timestep. then, what happens is that since the true logic rate of the event sheet is vsynced, the every 1/60 seconds event (which is our pseudo fixed timestep) cannot be respected properly. The frame will take 0.013 seconds to execute, fail the time event (since the time accumulation isn't ready), and only check it again once 0.026 seconds has passed (the next vsync, and ~10ms off target). On this frame it'll return true, and execute. at 0.039 it'll be false again and skip that frame, and then next time it will be true again. And so on. Frames are skipped resulting in an extremely jerky "fixed" (not really) timestep. If this was built into the engine then the fixed timestep would be high precision and non jerky.

there are no current way to do this in NW.Js nor chrome AFAIK (well you can use a chrome or nw.js argument to disable v sync but then the game will run as fast as possible as opposed to a fixed framerate), the dt minimum value can be fixed to fit a 60 fps display so if the game goes under 60 fps, well, it will get slowed down.

using dt is still important to ensure that the result will act the same regardless of the framerate (so a 144Hz display or a 60 Hz one will still be calculated the same).

But apart from performance reasons (executing the logic and rendering at a fixed 30 fps is not as costly), if it is done well, dt ensures that as long as there is no lag or freezes, the game acts correctly and is as fluid as it can (since the movements aren't framerate dependant but time dependant).

Also I never thought of a single case when anyone would want to use every X seconds with such a low value as 1/60, like why even do this? I don't get it, if your dt implementation is correct you simply don't need nor want that, perhaps I'm missing something (it's early here).

I still agree however that a fixed framerate would make development easier for some people working with devices with a low perfs/framerate ratio, or simply make development faster as there is no dt to use (even though dt isn't that hard to use once you understand it, but as said for deterministic resuts while still being the same speed on all system is a must it's important), however input based replay would indeed work nicely, instead of what we can do currently (basically a time based replay which is not as easy to do!).

EDIT: After reading it again it feels like this post is agaisnt fixed framerates, it is not, I want to see a fixed framerate as an option, screen tearing is a light tradeoff for all the advantages it gives, this post was simply trying to explain how to compensate from the lack of it currently. Oh btw GM:Studio allows a fixed framerate but unsure if they do it the right way.

the dt minimum value can be fixed to fit a 60 fps display so if the game goes under 60 fps, well, it will get slowed down.

Yes, but a maximum can't be set. The only way would be to set the minimum to something like 600 so it has no chance of ever varying on faster displays. It's still going to run faster on faster displays though.

using dt is still important to ensure that the result will act the same regardless of the framerate (so a 144Hz display or a 60 Hz one will still be calculated the same).

Having a fixed framerate completely alleviates this issue, and there's no need for any dt at all. The game and rendering rate are fixed according to system time. that's the whole point of a fixed framerate.

But apart from performance reasons (executing the logic and rendering at a fixed 30 fps is not as costly), if it is done well, dt ensures that as long as there is no lag or freezes, the game acts correctly and is as fluid as it can (since the movements aren't framerate dependant but time dependant).

Exactly what isn't wanted, time dependent movement. For most games and applications it's fine, but sometimes you don't want that. It's good to give people control of their game's behavior. Forcing them to use V-sync and the corresponding logic rate isn't something an engine should do. Don't get me wrong, most games SHOULD use V-sync + dt. The game I'm working on now (not with Construct) uses V-sync and dt. But there are times when you don't want or need it. Old games did not use any kind of dt and thus were perfectly deterministic. Some people want that.

Also I never thought of a single case when anyone would want to use every X seconds with such a low value as 1/60, like why even do this? I don't get it, if your dt implementation is correct you simply don't need nor want that, perhaps I'm missing something (it's early here).

I'm showing you the only workaround that you can do in C2-C3 to acheive a fixed framerate, but I explained the problems above. The event sheet running at vsync rate makes precise timing impossible, resulting in very jerky movement. It needs to be a runtime option to work properly.

There is a Chrome "bug" opened for over a year requesting ability to lock framerate.....

https://bugs.chromium.org/p/chromium/issues/detail?id=522983

doesn't look like it is getting much love but if more people star it then it might. I have starred it.

I looks like Scirra's Ashley Gullen is already a big contributor to the thread and related group!

https://groups.google.com/a/chromium.org/forum/#!topic/scheduler-dev/MNt-Ma7xnYQ