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

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?

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...

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.

— 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...

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.

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.

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.

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.

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.

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

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

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.

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

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.

...

Now that is what I call a nice informative response, thank you for that Ashley !

Please provide information like this (even if it seems to be just useless information for you) in every response, especially in feature suggestions.

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

Yeah the most of us (including myself) just want to see valid reasons with information about previous attempts or something like that, so we know were we're at.

To be honest, after seeing the almost same response to several topics like this one I did assume that you

simply tried it once then just threw it aside because it didn't work well at that time. (I guess I was wrong. )

Now that is what I call a nice informative response, thank you for that Ashley !

Please provide information like this (even if it seems to be just useless information for you) in every response, especially in feature suggestions.

Indeed, thank you Ashley . It's good to know the informations behind these limitations.

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.

+1 star for that bug.

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.

Here's the thing, let us be the judge, if the tool can do it, let us decide what's better for our games. It's an entirely different matter if the engine cannot do it, in this case, it looks like a browser conflict is preventing you from getting it done, as I said, fair enough.

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.

Mobile SOCs loaded will burn through the battery much faster than the screen display. Example that really highlights this: play a video, an iPhone 6 Plus lasts for ~8 hours or more. The screen is on, but not much of the CPU/GPU is being used (just a dedicated decoder part of the SOC).

Now, load up an intensive game that loads the CPU/GPU, something like XCOM, watch that iPhone 6 Plus dead in battery in ~2 hours, while running very hot.

For the record, my game (link in signature), stripped of many effects, lowered on particles, removed shaders, optimized AI, on the iPhone 6 Plus Safari drains the battery in ~2 hours also. The PC version runs 60 fps on old Intel Graphics laptops from 2007. According to cpuutilisation, on my PC it loads ~20-35% of the single-thread. On iPhone 6 Plus Safari, it's ~60-90%, so it's hitting peak CPU usage during big battles.

Mobiles have incredible specs, on paper. But as soon as you try to extract peak performance out of them, their slim designs mean they get very hot and power usage increases. This is true for all mobile games, where developers never aim to fully load the SOC due to this reason.

This is a major concern for mobile gamers, if it's possible to lower CPU/GPU load % to achieve a steady state fluid experience, then it's something beneficial.

Would I trade 60 fps and get a steady 30 fps if it means my mobile device is now just warm, not hot, and battery life is near doubled? Yes I would. But give me that choice if possible.

Again, thanks for trying and looking into it. Sadly it's inherently linked to browsers and Chromium is the issue.

How does Safari treat vsync or half v-sync?

We should be able to lock to any frame rate we want imho. Turn base rouge like could easily run 15-20 fps to be fully playable.

Here's the thing, let us be the judge, if the tool can do it, let us decide what's better for our games. It's an entirely different matter if the engine cannot do it, in this case, it looks like a browser conflict is preventing you from getting it done, as I said, fair enough.

I can't agree more.