[REQUEST] Developer to set FPS

Another problem is not all devices use a 60 Hz display. It's common, but it's by no means required. 30 FPS will have an uneven framerate if it doesn't divide nicely in to the refresh rate of a different frequency display, e.g. on a 75 Hz monitor.

I honestly would adore the option to cap the framerate. There's a big difference in gameplay comparing "30fps" to "randomly changing between 40-50fps" gameplay.

I have a computer I test with sometimes and when it's running between 40-50fps, I wish I could cap it at 30 to keep it remaining smooth.

The idea of uncapping for benchmarking is pretty nifty too, although not the main focus.

I totally understand the fact that dt makes it so that the game runs the same regardless of framerate, but there certainly is stutter and difference when the framerate is constantly fluctuating.

EDIT: To combat the "What if it ruins the experience for the users with better hardware that CAN fun 60fps", what about (not that I think this is an easy solution or anything) but a Framerate rounder? If the system keeps detecting that the fps is between 40-50, then it would round it down (Exactly like how FRAPS works when you record in a high framerate and then the game experiences lag, it forces the game's framerate down to 30fps)

I thought 30fps was standard for mobile games o.o

Ashley,

Point 1) There are many cases where a game works perfectly at high FPS and then fails casastrophically at low FPS. Delta time is fantastic, and its great to ensure stuff stays the same speed despite FPS, BUT this very solution to one problem makes objects fall through floors and otherwise completely miss critical collisions with objects, enemies etc etc at much lower FPS. The ability to cap frame-rate (at least while testing) would allow game makers to easily make sure the game works great across the board..even on weak devices.

Point 2) It seems to me it might be simple to allow the game to detect the power of the device its on and adapt the fps accordingly, as in: If FPS of title screen is < X, then cap FPS at 30, if FPS of titlescreen is greater that 50, then remove FPS cap....so perhaps there is no good reason to assume that capping the FPS will degrade anyones experience, in fact, only guarantee best experience across all platforms. (because we could turn off the cap either before making the build for high end platforms, or have the game turn off the cap at run-time if running on a powerful device.)

cheers,

Mike

I still can't seem to get my head around dt. I have a physics object that is set to frame rate independent and a timer that adds up in real time milliseconds.

Play it on my pc = fine

Play it on my mobile device, and the time counts as normal in real time, but my physics object moves slowly.

I also notice slowdown when additional sprites overwhelm. The drop from 60 to 30 can be disorienting. If I felt my game worked fine at 30fps, I'd like to limit it.

A game recently came out on pc. Naruto full burst. It's fixed at 30 fps, and some people aren't happy, but I think it runs great. Sure it may run better at 60, but I don't need any faster.

I feel my mobile game would benefit greatly from a locked 30fps, but Ashley is the genius here, not me.

Just yesterday I had an issue with a game bugging critically because the framerate dropped too low on a device while testing and objects started moving through walls. If there were an option in the debugger to test out slower frame rates before exporting, it would have saved some hassle for me.

I guess if you want a preview of 30 fps, you could set time scale to 0.5.

Unfortunately that doesn't work for finding frame rate dependent bugs (at least in my limited experience).

OK, OK, I agree that the human eye can discern scene update rates well above 18 fps, and probably out to above 60 fps for most people. That was not the context of my point, which I probably didn?t make very well. My comparison with PAL etc was to point out that such lower refresh rates can be wholly acceptable for viewing purposes ? only as long as the update rate is consistent. I don?t believe that a target audience will bother persisting with a game if the playability is hurt because the frame rate varies significantly between say 35-55 every few seconds.

Almost all other software creation tools allow the developer to set the frame rate (eg GMS, Corona, Moai etc). When I previously tinkered with GMS the default was 30 and plenty of acceptable games were created using that frame rate. Jase00 and — have the right idea with a frame rate rounder ? Unity uses vBlankCount to limit the frame rate to 30 to preserve the quality of the drawn display, which I understand is something similar (although I have no Unity experience).

The issue of screen refresh rate compatibility with the game refresh rate is an interesting point. My screen design knowledge is limited but surely 72 Hz and 144 Hz screens seem to cope with 60 fps games even though 60 does not wholly divide into 72. Is this because the higher the screen Hz then the smaller the frame draw error? This could be noticeable to an expert eye, but I don?t know how different a 30 fps game and a 60 fps game would look from each other on a 72 Hz monitor (aside from the more hesitant sprite movement etc).

This is all beside the point, however ? I just don?t understand why it should be acceptable for C2 to make a game that will inevitably be choppy and difficult to play in a mobile browser when a potential solution is close to hand. Whether the solution is to allow the developer to set the frame rate, or if C2 could apply the same idea as used in Unity to strive for a constant frame rate, I don?t really care.   

If a solution would be easy to implement then I say let?s go for it ASHLEY. I know that you?re the expert here but I think that there are some good arguments for implementing a frame rate rounder or lower fps option. Unless this is asking for the moon on a stick (complete C2 code base rewrite) in which case I will stop asking immediately!

I guess if you want a preview of 30 fps, you could set time scale to 0.5.

newt : that will slow the speed of the game, not act like a low FPS.

A low FPs induce less calculs, if you game is programmed as a frame-rate independent game, it will not slow down by low FPS, just be less fluid, and also, in that case, low FPS can induce bugs.

The timescale is the way to slow down easily the game while not changing the FPS.

Its the closest thing you have... other than throwing a bunch of particle objects in with the wash.

Of course if the fps is already at 30, that wont accomplish much.

I think it's too bad. There are PS3 games rendering at 30FPS to allow the CPU and GPU to increase qaulity physics and game logic. Then it also gives around double the time for the GPU to increase visual quality. Then because the game is tuned to play at 30fps no one really notices.

But C2 will never support it. So I suggest leaving the discussion dead :(

This was one of my first requests over a year ago. I see this request a couple of times a season. And when an official response comes in. The answer is usually along the lines. "If it's possible to render at 60fps then why bother render at anything less".

Well other have given reasons, very good points of discussions, pointed out companies like EA, Sqaure, Ubisoft Watcdogs run at 30fps.

ca.ign.com/articles/2013/09/27/watch-dogs-runs-at-30-frames-per-second-on-next-gen-consoles

that's right. Big next gen game. because the graphics and gameplay qaulity can be improved due to more processing time. But it's just not good enough reason :(

So I gave up.

However there is an alternative. It requires some extra build time.

* C2 only draws if there is a graphics change. Take advangtage of that.

* Grab Rojo hounds canvas.

* All sprites are invisible at all times.

* render on to rojo hounds canvas at 30fps.

because the canvas is only drawn on at the 30fs tick 1/16 or something, The C2 only renders at 30fps and you get all the logic physics quality of 60fps. Still not sure how to increase visual quality though. But i'm sure it can be done.

jayderyu

Seems like quite a frustrating work around using canvas :( It's possible that it's not a simple change to make for Ashley. I'm sure if it was, judging by how many people are requesting it, and how regularly it's come up, it would have been added by now.

My game could really do with it. A physics object is spawned, and the game just slows down just enough that things go from silky smooth to slightly jerky.

Surely this just comes down to a matter of choice. If it isn't too difficult to implement then all it does is provide the developer with more choices/options, which is generally a good thing.

If it is too difficult, or it would break the engine too much, then let Ashley say so and this topic can then be closed.

I didn't say we would never support it. IMO It's a trickier subject than most people are giving it credit for.

Issues with dt at low framerates are a different problem. If the framerate is low enough to cause problems with gameplay, usually it is much lower than 30 FPS, so a framerate cap does not fix that. It's a separate problem.

Adjusting the framerate cap at runtime is a pretty difficult problem and hard to get reliably right. You'd want to figure that out on startup, but Javascript optimisation and garbage collection tends to make things a bit choppy on startup, so any measurements would be unreliable. Even so later on there might just be a single momentary blip below 60 FPS, and you probably don't want that to trip it down to 30 FPS. So then you have to draw a line somewhere, and wherever you draw the line, sometimes you'll choose 60 FPS when it should have been 30 and 30 FPS when it would have been better to choose 60. I'm not at all confident the engine would be able to choose correctly most of the time.

Other game creation tools might provide a framerate setting, but I don't think that makes it a good idea!

A screen with a refresh rate like 72 Hz doesn't play the game at 60 FPS - it plays it at 72 FPS (if the system is fast enough). A framerate independent game adapts to this seamlessly, ensuring best quality display. To be more correct, instead of talking about 60 FPS and 30 FPS we should say "vsync rate" and "half vsync rate". The engine could support a "half vsync rate" mode, but then you can't easily tell the display refresh rate in Javascript, so you have to go off some adaptive system again, which is unreliable and might pick wrong, and then you have a choppy framerate again. Also that kind of thing needs reliable high-precision timers, which aren't available everywhere.

Consoles are a different case: the hardware is known in detail in advance, so you may be able to say confidently that a game you have absolutely cannot run at vsync rate. However C2 games run everywhere from powerful desktops to weak phones. IMO a game running at half-vsync on a powerful desktop PC is both annoying and an inferior experience to a vsync-rate game. I didn't spend all that money on a ridiculous graphics card for 30 FPS :)

In short my opinion is that if a system can run a game at vsync rate, we should let it. Since there's probably not a really reliable way to detect the need for half-vsync rate and then accurately hit that, the best way to try and let it is to leave the framerate uncapped.