[REQUEST] Developer to set FPS

Apologies if this has been a recent discussion...

So, I've been trying to find ways to deploy across various platforms to include mobile. Aside from the CJS/GC/Ejecta discussion, I find that deploying to mobile (browser or CJS) yields changing results according to processor load, how modern the handset is, number of objects that instant etc. The problem as I see it is that my poor old mobile and tiny computer/phone is trying to yield 60 fps and, if it can't, it tries its best to give as close as it can at any given moment. If only I was trying to write a game of othello...

My coding must suck, because I can't seem to demand a constant load on the cpu which causes the framerate to vary, with a consequential degradation in the user experience.

As a workaround, what does everyone think to allowing the developer to set the FPS for any given game? Instead of stressing out trying to provide 60 fps (and only giving between 40 - 55 fps) my mobile would be able to relax, chill and comfortably do the required maths to render to 30 fps...

Just a thought. Am I alone?

I want this too, to ensure there is no variation of FPS, and also it could be an interesting debug feature (you know, to see how much you are better than 60 FPS, and when to starrt to worried that something begin to be too much intensive and might be a problem later).

I want this. Fixed at 30fps, rather than a subtle change in frame rate every now and then.

Agreed, if it's possible to do something like that, it would be a good feature to have.

+1!

-100

Whats next a cap on cpu?

In other words this doesn't do what you think it does.

A way to cap the FPS while testing would be great at the very least, as some bugs only occur at low FPS (like falling through floors, missing collision detections etc)

+101 (to counteract newt's strong objection ;) )

If we could cap the FPS while testing, we wouldn't have to deploy the game to an actual weak device to make sure we've fixed the issue for low end devices.

Also ,capping the FPS so that its constant can make a games overal play experience better that an PFS that changes frequently due to whats going on on-screen.

-Mike

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!

I have a question, since I absolutelly don't know about that:

Ashley

more fps induce more calculation in the same amount of time?

and If so, does it drain faster the battery of a mobile device?

EDIT: Also, I see this a previewing option at least

Perhaps, but the biggest drain on battery on modern devices is the screen. If the screen is on the same amount of time, then whether the game ran at 30 FPS or 60 FPS probably won't make a bigger difference than the fact the screen was still on that whole time. Meanwhile you want your game to look good on high-end devices compared to other games, right?

Ashley

Yes, but I think a way to change fps in preview (since it dont make a huge deal, I was worried about user experience and battery mostly), just to see if it is playable at lower fps could be interesting to know (because bejeweled can be played at a lower framerate than touhou project I think, even if this exemple is not applicable on mobile, just to explain)

Also I saw it not like a fixed parameter, but more like an ingame option if the fps go crazy between 35 and 50 for exemple. some users will less notice a constant 30 fps compare to a varying fps that will lead to more difficult control overall.

Shouldn't you be able to cap FPS with the delta time stuff built into C2? I know it would require a lot more programming on the movements and controls. But with the right math, couldn't you control FPS that way?

Either way, I agree with ASHLEY. The built in behaviors have built in DT algorithms which will make sure other things should run smoothly. The only that that would change is the frame positioning on graphics refresh. Given the rate at which smart phone are improving, Google's new JS project, Cacoon, improvements in webkit and such, I don't see a reason to limit frame rate. It would do nothing but limit the experience and cause a headache for devs later on with upkeep (unless you don't intend on supporting your game past a few months).

Ashley,

I think C2 is awesome with great potential and I hear what you?re saying regarding FPS but I have to disagree on the philosophy.

I would like to release games that are be playable on a mobile browser (Kongregate, Clay.io etc) as well as a PC (I see a great audience in people ? like me ? who get bored during their working day and would like a moment to escape). Most people in the world do not presently own an iPhone 5 or Galaxy S4 and I?m not yet convinced that the majority will have one or better in 2 years time (if my market is teenagers then they are unlikely to own a state of the art piece of hardware). Also, I don?t want to wait 2 years to release my game....

It is worth considering that the human eye can discern individual framerate images up to approx 18 fps; above that, humans are just not able to see individual frames. Hence why PAL tv can be piped to millions at 25 fps and no one cares ? so I don?t buy the need for 60 fps as being the only option of quality. What humans are very good at detecting, however, are changes: including those associated with varying velocity (speed and direction) ? the kind of things that happen when a browser is max?d and the fps varies.

I believe that this should be a decision for the developer and I?m asking for the option because I believe that, for the market today, being able to cap FPS at, say, 30 might improve the playability of a game on an average handset that would not cope with doing the same maths at 60 fps. Today I will design for Galaxy S2s and in 2 years I know I will be able to steroid up to the prolific use of quadcore and enjoy 60 fps and 200+ objects without a problem.

This is my only (minor) frustration with C2; the frequent builds and insightful updates are brilliant (as is the community). So, I?m just asking for a little dropdown box showing 60/30...

Thanks,

Ed

The human eye can see more than 18fps. Films are made 24fps for smoothness as with the way it projects, that's the point where it starts looking smooth. TVs (NTSC) are 29.9, and people can see the difference between that and 24fps.

Computers are 60hz and most games are 60fps. Many people notice the difference between 30fps and 60fps.

The problem I have with FPS isn't that higher is smoother, is that variable FPS can cause a bad user experience. That being said, it's the developer's responsibility to have specifications on the target hardware and scale the game down accordingly.

HOWEVER, Consoles are framerate limits due to hardware limitations and to ensure smooth operation. They're more concerned with the professional 30/60fps.

Mobile devices are also limited devices that if you can make a game run smoothly at 30fps, but have a hard time meeting 60fps, then there should be an option or a way to limit it.

That doesn't mean to not adjust the graphical load to meet hardware demand, just that framerate limiting is the /last/ step you do.

IMO while there is justification for a FPS limiter, there's no real reason to do so while the market and standards are changing so fast your game might run at 30fps today, but 60fps next week.

Once the field settles, and limitations are being met left and right, then maybe there would be a real reason. (Although a global delta-time multiplier to enforce framerate shouldn't be too hard to implement)

Edit: But this is mostly PC/Browser games. Mobile exports are usually 3rd party so it would be an option for CocoonJS or Phonegap to introduce FR limits to set for apps.

Seconding that people can see well more than 18 fps. Many people, including myself, can tell the difference between 60 and 120 fps.