Why is there no option to set engine FPS/tic rate?

Discussion and feedback on Construct 2

Post » Sat Feb 20, 2016 3:34 am

Just curious, because the engine is designed to run flat out to match the vsync/refresh rate and there's no option for setting a desired tic rate or FPS rate.

While it may not sound useful, it can be incredibly useful, especially on mobile platforms.

1. Many games do not need 60 fps and the engine running as fast as possible may not offer a better gaming experience due to fps drops during big scenes, the fluctuation cause microstutter and its quite jarring. On mobiles this happens more due to weaking CPU/GPU so games with lots of action/units will get frequently FPS drops.

2. Aiming for a steady 30 fps would provide a more fluid gameplay without the stutters, with a major bonus side-effect: better battery life and the mobile device running less hot, because it doesn't have to work as hard to try and hit the 60 fps, fluctuating from 30 to 60 during intense scenes.

@Ashley
Is it a very difficult option to implement for the C2/C3 engine?
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,616

Post » Sat Feb 20, 2016 4:35 am

Hoo boy. I asked for a 30 fps option a while ago (thread 3 years ago!?) because it was an option in corona sdk and gamemaker. However, AFAIK, browsers don't support an fps clamp. Ashley tried a 1/2 vsync option which turned out to be a useless mess, so it was quickly dropped in beta. I think the best you could hope for is for your logic to run every second tick, but behaviors have no such option...
A big fan of JavaScript.
B
76
S
20
G
73
Posts: 2,244
Reputation: 45,962

Post » Sat Feb 20, 2016 4:51 am

From that thread:

Ashley's response:

"I'm pretty against this. It seems a backward justification: if your intent is to prevent degrading the user experience, then implementing a framerate cap will degrade the user experience on high-end devices that are perfectly capable of 60 FPS. Give it a couple of years and then everyone's got more powerful devices which are capable of 60 FPS, and you're unnecessarily degrading the experience for everybody. So I don't really buy that this improves the user experience.

With delta-time variable framerates should still continue gameplay at a steady rate. Perhaps you could provide an in-game option to reduce the number of sprites/effects to a "lo-fi" version to help it run faster if the player doesn't like the variable framerate. Also I think most casual players are far less sensitive to framerate issues than we are - I remember a few years ago crappy software-rendered Flash games staggering along with a horrible framerate still going viral all over the web... and once I saw someone on a plane playing a Bejeweled clone at 4 FPS... completely rubbish, but they didn't seem to care!"

--------------------------------

It's not a degradation of the user experience at all. Locked 30 fps functions very well on the biggest gaming platform: consoles.

Mobiles need this the most, particularly because JS + wrappers is inherently not as fast as native, so the CPU has to work harder by default. Even modern devices like the iPhone 6 Plus, while very fast, and can run most C2 games at 60 fps, it puts a major strain on the CPU, resulting in a very hot phone and the battery dead in about 2 hours. XCOM, the awesome 3D game, PC quality, drains mobiles in about 2 hours. Our 2D games have no excuse putting such a strain on mobile CPU.

Besides this point, many game genres do not function better at 60 fps for mobiles. A steady 30 fps will appear more visually smooth than fluctuations at ~60 fps.

The important point is allow us gamedevs to decide. If its possible, have this option. We will use it where we deem it best fit our needs.
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,616

Post » Sat Feb 20, 2016 8:14 am

@Silverforce I'm sorry to tell you this but you've just created another topic that will get denied by Ashley as soon as possible, with some odd reason why a feature like "30fps" is not good for the games quality and so on...

To be honest you are not the first one, neither the second one that asks for a feature like this.
The only solution for this problem will be a "wait for mobiles until they get more powerfull" I can assure you of that.

Maybe Construct 3 will be more open in terms of game-system features like this one, but I doubt that too...
ImageImageImage
B
63
S
23
G
78
Posts: 664
Reputation: 44,941

Post » Sat Feb 20, 2016 8:22 am

It's not even about "wait for mobiles until they get more powerful". Even IF they are very powerful, I do not want 60 fps for many genres of games on mobiles, I much prefer they have a solid 30 fps, using much less CPU/GPU cycles and thus having much better battery life for my game.

I just want to understand why there's all these excuses for such a key engine feature, is it because it's incredibly difficult to implement? Is it because it's impossible given the reliance on browsers?

What is the reason such a critical feature is absent?

I know the memory unload feature that many have asked is not possible because browsers handle all the memory management.
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,616

Post » Sat Feb 20, 2016 8:43 am

Silverforce wrote:It's not even about "wait for mobiles until they get more powerful". Even IF they are very powerful, I do not want 60 fps for many genres of games on mobiles, I much prefer they have a solid 30 fps, using much less CPU/GPU cycles and thus having much better battery life for my game.

I just want to understand why there's all these excuses for such a key engine feature, is it because it's incredibly difficult to implement? Is it because it's impossible given the reliance on browsers?

What is the reason such a critical feature is absent?

I know the memory unload feature that many have asked is not possible because browsers handle all the memory management.

I know how frustrating it gets when suggestions that are fundamental for every modern game engine are not implemented neither planned to get implemented.
I'm not an expert in web technology like Ashley is but I think that this feature could be implemented without
huge issues, (for example) the problem with compensating collusion checks on lower frame rates can be handled with the "slowdown" feature.
ImageImageImage
B
63
S
23
G
78
Posts: 664
Reputation: 44,941

Post » Sat Feb 20, 2016 12:55 pm

I think that we're stuck in a place that's going to always cause problems. As browsers will always try to render at vsync and our game logic will always be run at whatever rate the browser is trying to achieve, we're always going to encounter occasional frame drops on low-end devices.
A big fan of JavaScript.
B
76
S
20
G
73
Posts: 2,244
Reputation: 45,962

Post » Sat Feb 20, 2016 1:39 pm

At some point, Ashley implemented a 30fps-mode, because of public demand. It died in the same Beta-cycle and never reached stable, because it didn't work right with web tech. It caused a lot of problems, so the idea was abandoned.
B
77
S
28
G
32
Posts: 481
Reputation: 19,763

Post » Sat Feb 20, 2016 1:53 pm

Eisenhans wrote:At some point, Ashley implemented a 30fps-mode, because of public demand. It died in the same Beta-cycle and never reached stable, because it didn't work right with web tech. It caused a lot of problems, so the idea was abandoned.


Okay fair enough. At least it was tried.
B
70
S
24
G
19
Posts: 1,757
Reputation: 17,616

Post » Sat Feb 20, 2016 1:55 pm

I don't always keep the same view over time - my view of things tends to evolve with the technology, so bear that in mind when quoting my posts from a few years ago. Also BTW it's kind of annoying to see people asserting that they know what I'm going to say, especially when they're wrong :P

tl;dr: star this Chrome issue: http://crbug.com/522983

My thoughts on this are:

Performance: I'm not convinced it makes sense to do this because the game might not reach 60 FPS. Modern mobile devices are about as powerful as laptops. Having one master switch to drop to 30 FPS on all devices is overkill IMO. I stand by this aspect of my previous post: if you are doing this to improve the user experience, then dropping a device that could easily reach 60 FPS to 30 FPS actually degrades the experience.

Also it's not just about mobile, some laptops have serious fillrate performance issues because they ship with the terrible combination of a weak integrated Intel GPU and a high-resolution screen. I think the original motivation for this feature was actually for these laptops. Intel integrated GPUs are far weaker than most mobile devices! (Before anyone accuses C2 of being slow, it's a hardware limit, native apps will be the same!) So if your intent is to flip this mode on for mobile devices and leave it off everywhere else, I think it might actually be better to leave it off for mobile and optionally on for underpowered desktop systems :P

Battery life: I think the argument here is better, although I would be interested to see actual data on the battery life savings. As far as I'm aware the screen is one of the biggest battery drain on mobile devices, so if the screen is on for the same amount of time at the same brightness, that part of the battery drain is identical regardless of how intensively the game is running. Also power-saving hardware works best when it can remain idle for long periods of time, allowing the chip time to fall back to the lowest-power modes. 30 FPS allows a maximum of about 30ms idle time, which isn't that much time to power down components. So I think it would be interesting to try and quantify this saving, rather than speculating that it will help. (Note people often compare 2D games to 3D games, but they're not the same - particularly in terms of overdraw, 2D games can be more intensive, since 3D games use different rendering techniques like Z buffering. Also modern GPUs are so well-optimised for 3D that it doesn't matter if you draw a triangle in 2D or 3D, it probably treats both as the same case.)

Also note that on a weak laptop plugged in to mains, there's no need to save battery life.

Browser support: we actually tried implementing this already, and it didn't work well at all, mainly because browsers are designed to run at v-sync rate. We tried simply skipping alternate frames, but the browser scheduler assumes a full frame will be drawn on the skipped frame. In some browsers this actually resulted in an even more janky mess, and in others it would incorrectly drop to quarter-framerate mode (just 15 FPS!) if the browser thought it couldn't hit 60 FPS, because the browser would drop down the framerate itself in some way. So there needs to be built-in browser support for half-framerate mode, which doesn't exist yet.

Based on that, I already made the case for this feature to some of the Chrome developers (making some of the same arguments people are giving here!), and you can star this bug to vote on the suggestion. Until then, there's not much we can do to actually support this.
Scirra Founder
B
399
S
236
G
89
Posts: 24,519
Reputation: 195,361

Next

Return to Construct 2 General

Who is online

Users browsing this forum: BlueAlfie and 7 guests