Dynamic timescale based on FPS (Enable game slowdown)

Hello, everyone! I've been enjoying Construct 2 immensely, to the point of relying on the game I'm making with it for my livelihood. Now that's confidence in a product! It has absolutely every feature I ever needed or expected to need! That is, save one!

Construct 2 seems to be very, very stubborn about the way it handles frame rates. The option to set a frame rate cap doesn't seem to exist at all, despite the multitude of reasons a game creator might want to (I.E. for aesthetic reasons or to ensure more consistent results/performance out of certain devices).

Another option that's missing seems to be the ability to choose to have the game slow down rather than start dropping frames after the frame rate gets below a certain point. I've run into problems with this in my game, Grapple Force Rena; at low frame rates, the game doesn't register collisions as reliably, and the main character's grappling hook starts to 'pass through' and miss pieces of the environment, enemies, and objects. Games that value precision collision detection over game speed (I.E. 'bullet hell' shooters, which require incredibly precise collision handling) might become borderline unplayable under these conditions.

I've created an example of how to replicate the 'slowdown' behavior in Construct 2 using events, but since the engine only updates the frame rate it reports once per second, it isn't perfect. I've provided the example as an attachment, and also uploaded it here: http://battlestudio.com/c2slowdown/

Are there any plans to put more options in the hands of game creators in terms of the way Construct 2 handles performance issues like these? And when will we finally receive the ability to control the maximum frame rate manually?

Agreed - I'd definitely like to see an option to slow down the game instead of increasing dt.

I would like it too, however, setting the framerate should not slow down the game by default, only make it refresh less often the logic and display.

As for the timescalerelated to framerate, that could be an optionnal setting

Agreed, construct classic actually had this. C2 technically has it too, but it's hard coded to either 10 or 15 fps (I can't remember). It would be very useful if it was user definable in C2 as well. I think it would be possible to edit the exported code to change at what framerate the game slows down, but I'm not sure of how difficult that would be.

Set frame rate to 30 might be useful in mobile game. A stable frame rate at 30 fps might be smooth than floating between 60~40 fps.

I literally had to shelve a game back a few months ago because I was having this same issue, and couldn't find a way around it.

Mind, there are some hacky approaches that kinda/sorta work, but for my game -- a puzzle/shooter -- these approaches simply weren't reliable enough. I posted an example of one in this thread:

Ashley

Any possibility of this finding it's way onto your Everest-sized todo list.

Another vote for this.

I can even think of text-heavy games that might benefit from ~5 fps, so they don't drain a mobile battery.

So far this is the only feature I can see that's glaringly missing from Construct 2, and I really hope to see it included soon. The fact that game creators don't have the power to control the framerate of their games is surprising, and bordering on unacceptable, in my opinion! The framerate is something that can dramatically alter the experience of any visual medium in motion (just ask people who saw the Hobbit at 48fps), and as such it should be in the hands of the game creators. Even if hovering between 40-60fps is "better performance" by the numbers, a constant 30fps would offer a much better experience.

There's also the fact that one might want to limit the framerate for purely aesthetic reasons, perhaps emulating the experience of older computer games that ran at a low frame rates, or limiting your game to 24 fps for a "cinematic" feel - reading a post by one of the C2 creators saying there's "no good reason to do this" made me feel a little insulted!

usefull for mobile

BattleJenkins

I agree. However I have voiced opinion for this for years before your arrival. There are three factors involved why there is no FPS control on anything.

1. The change would require an architecture change to C2 root rendering.

Earlier this year Ashley threw in a simple FPS controller. However due to everything else it was impossible to get smooth animation. I know it's possible to have a good FPS controller but all the plugins that require motion would need re-working.

2, Ashley believes that there is no reason to run less than max capable and 60fps marker. Also Ashley claims that dt is working well enough even when the fps drops.. Though evidence shows enough to contrary.

3. It's a once man team doing the core programming...still .. Maybe down the road there will be enough programming staff to really take on some of the developer bottle necks.

i actually once linked to a fantastic article that swapped the FPS control. Due abvoe reason 1. There was the alternative or limiting the FPS of logic instead. This means that by dropping logic updates to less often this would allow better maintaince of FPS smooth rendering and ultimatly betterg ame performance without requiring the architecture changes. unfortunatly it was ignored. but hey. I tested out the theory on my own.

I wrote an on every 0.0033 tick. Inside there was a loop that went through an array and called a function. Essentialy I wrote a logic kernel. On my tests for mobile. I was able to get 5fps program up to 60fps by only doing the logic of the trig at apx 24fps and 30fps. So for my standards now that if there is any heavy trig going on. I'll either limit the updates or build a simple kernel. The result has been fantastic

I tried to entice Ashley to allow for this - a solid 30 fps on a Samsung S2 would be infinitely better than what I experienced with continual slow-downs and speed-ups. Here's the old thread. The problem was something to do with how C2 ties to the vsync of the display in use... It ultimately proved no good - a non-fixed and on-demand temporary lower framerate was implemented, but that proved just as glitchey as if no remedy had been implemented. It felt like a 1/2 way solution - to lower the framerate ad-hoc if the tick time was longer than a certain value (can't remember the details so apologies if this makes no sense). I imagine that it would require a big re-write of the engine, although I really don't understand why it's not possible to do when Unity and GameMaker manage it without a problem - and they both export to HTML5....

Hey thanks for the link. Guess I missed the last replies in that thread one way or another.

However Ashley reply is pretty clear. No work will be done on such features in the future do to personal design philosophy. Outside of having real tangible proof by way of code examples for an HTML5 engine. I suspect there will be no budging.