Dynamic timescale based on FPS (Enable game slowdown)

Discussion and feedback on Construct 2

Post » Mon Aug 04, 2014 2:35 pm

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?
You do not have the required permissions to view the files attached to this post.
B
9
S
2
Posts: 28
Reputation: 649

Post » Mon Aug 04, 2014 2:56 pm

Agreed - I'd definitely like to see an option to slow down the game instead of increasing dt.
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,679

Post » Mon Aug 04, 2014 3:20 pm

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
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
53
S
22
G
18
Posts: 2,122
Reputation: 17,123

Post » Mon Aug 04, 2014 4:14 pm

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.
Moderator
B
94
S
33
G
33
Posts: 3,006
Reputation: 27,749

Post » Mon Aug 04, 2014 4:28 pm

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.
B
108
S
26
G
267
Posts: 4,456
Reputation: 149,747

Post » Mon Aug 04, 2014 4:30 pm

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:

viewtopic.php?f=147&t=94112

@Ashley

Any possibility of this finding it's way onto your Everest-sized todo list. :D
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Tue Aug 05, 2014 3:58 am

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.
B
36
S
8
G
8
Posts: 532
Reputation: 6,903

Post » Mon Aug 11, 2014 11:28 pm

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!
B
9
S
2
Posts: 28
Reputation: 649

Post » Tue Aug 12, 2014 12:01 am

usefull for mobile
B
45
S
16
G
8
Posts: 792
Reputation: 8,306

Post » Tue Aug 12, 2014 12:33 am

@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 :)
B
90
S
18
G
9
Posts: 2,455
Reputation: 15,018

Next

Return to Construct 2 General

Who is online

Users browsing this forum: CrudeMik and 5 guests