Performance improvement suggestion for Construct 3, the "Frame Rate Lock".

A Construct 3 Suggestion that will improve performance.

Salman_Shh made a great suggestion on the Construct 3 Suggestions Website.

Link: construct3.ideas.aha.io/ideas/C3-I-679

For those who don't know what the Frame Rate Lock is, it is the ever famous suggestion for Construct 2 that wasn't implemented. Basically, this feature will cap the FPS to whatever frame limit you want.

This is a feature that most game engines have to improve performance on weaker devices, make performance or GFX options, or manage FPS entirely.

Benefits of this feature

The benefit of this feature, is that we can control the FPS limit, scale and improve the performance of Construct Games to our liking. This is a good way to increase performance by lessening the load of the game from the redundant frames, if the extra graphical frames isn't needed in your game.

This is incredibly useful, for example, Mobile Games. Most professional Mobile Games lock their game FPS to around 24FPS to 30FPS, this is to improve performance & battery life and reduce power consumption.

Most professional games do this, I don't see why we shouldn't take advantage of this optimization too.

The devices that are most benefited

1. Mobile
2. Web

The devices that can help improve performance as an option

1. Desktop

This is a popular feature that most Construct 2 users longed for but this feature was denied. But since Construct 3 has more support because of its better editor & runtime and great subscription pricing. We can finally get features that would or are impossible to have on Construct 2.

One of the important features is this one. Please, again, vote for this. Comment too about the things that you think might help the thread.

Credits to Phacanu for sharing this info & Salman_Shh for making the suggestion.

Thanks a lot. Have a nice day and happy game development!

Setting the fps to a certain value will only provide a smooth solution if you know the display vsync fps and then set the update rate to a whole-value fraction of the vsync value. I have an old laptop that reduces the vsync to 50 fps when the battery is being used and an android tablet that uses 50 Hz as a default (ugh..)... 30 does not divide into 50, so using 30 in that case would cause some jank or apparent uneven movement. And there are plenty of monitors that run at other vsync values that 30 cannot divide into (ie 75 hz, 100 Hz, etc).

Thus, what you should really ask for (IMO) is a graceful degrade of logic fps - a runtime method of detecting when the average logic time is greater than that required to meet the monitor vsync (most games will jank a little if the player has a 240 hz monitor, for example, because the available logic time is only 4 ms per tick, ignoring garbage collection etc). But the jank may be hidden by the overall framerate (human eye limit) if the jank is only occasional.

In a cross-platform agnostic solution the runtime would have to allow the game logic and display timing to disconnect from each other. So, in a logic-heavy game all sprites would be moved at a fraction of the vsync fps (ie 0.5 x vsync or 0.33 x vsync -> whatever gives a round number). For a 75 hz monitor, the logic would have to degrade to 25 fps. And so on. That would take a bit of a re-write of the runtime logic, I think.

How can a browser detect the user's display vsync...? I don't know of a way that a browser can obtain that directly using JS, other than timing the requestAnimationFrame() timing... Oh, and if requestAnimationFrame() is called at exactly 60.00 Hz then it's probably a failure of the browser to detect the vsync and, instead, the browser has defaulted to the most likely callback value in absence of any data (so, even then, you can't guarantee to get the vsync value).

Unless I'm missing something...?

"This is a feature that most game engines have, to improve performance on weaker devices."

How does it improve performance? It internally knows how to share loop/function logic over multiple ticks? and knows which functions are not performance hevy, so they trigger instantly?

Isn't this already covered with best possible way?

This comes up from time to time. We'd have done it already if it was possible, but currently browsers don't support it. Star this issue to encourage development in Chrome.

Thanks. I already starred too.