[REQUEST] Developer to set FPS

Roccinio

I see you've had an account for a little over a month. Long-time lurker before that? In any case, how much of a game have you made? Have you reached a position where your game is simply unattractive because occasionally the smoothness changes?

I've spent the last 7 months working on a game, and I finally finished it 2 weeks ago. I've paid out to get art put together for it, and put in hundreds of hours. I could release my game on PC, and get fine results.

The thing is, I have built the game primarily for mobile devices. It'll work great on a PC, but for now, that's not my specific target. I've been accepted by Tizen, but can't do anything about iOS or Android just yet. We don't yet have a decent exporter.

You're talking about XB1 and PS4? Construct 2 has been accepted for Wii U, and yet we don't have an exporter for that yet, so unless you are fine with waiting another year or 2, then go for it. I'm currently looking at the present, and at present, I have a game that looks great at 60fsp, and good in 30fps.

The problem is, on mobile devices (like my Galaxy Note 10.1 or Samsung Galaxy S3, or iPad3 - which I consider pretty powerful) - I'm getting speeds that fluctuate from 60fps to 15fps. This game has been built under the impression that Cocoon would eventually become worthwhile, and I've been testing my game frequently on my devices to ensure that it works. The only problem I'm having, is the physics, and as I'm certainly sure you're aware, accelerated physics in Cocoon doesn't work.

This means my game can not be released.

Clearly there's a difference between 60fps, and 30fps, right? Have you ever played a game that's smooth when you stand still, but ever so slightly jerky when you move? That's a bit annoying, isn't it? That's because you're comparing the two rates of speeds. If the game was ONLY slightly jerky, you'd consider it the norm, and wouldn't automatically make the comparison.

We're not asking to make this the default, we're asking to make this optional for if and when we need it. As ChrisAlgoo said, "a consistent 30 is better than something inconsistent".

*Also, note the spaces I put between my paragraphs. It makes it easier on the eyes. Similar to a steady frame rate...

Running at 30fps allows for more visual content packed into the scene.

tomshardware.com/news/30fps-John-Carmack-Next-Generation-Console-Framerate,19864.html

gamespot.com/articles/watch-dogs-runs-at-30fps-on-xbox-one-ps4/1100-6415059

While increasing playability for being steady. Also if you run at 30fps you have more leeway to add visual FPS gauges to add extra effects or not.

Why is always assumed people want it to just run off the idea to make sure it runs on lower end. Even high systems receive a visual performance upgrade for the developer to choose more rendering features over more rendering frames. And you can get more than double the rendering features for half the render frames. Even in 20 years where computers can render real life like visuals. Running at 30fps will still offer more than double the period of time for each 30fps frame to render more detail

But hey. Why not tell the creators of Gears of War 3 there game looks terrible because they wanted more visual candy over 60fps.

"There's a good chance many developers may stick to 30fps just so that more content can be packed into each frame. Epic Games is a good example of that which stuck to 30fps with Gears of War 3. "Our target is, and shall remain, 30fps," former Epic superstar Cliff Bleszinski said in an interview. "When asked about 60 we always respond that we'd rather have the extra juice to put more on screen and stick with 30."

For Gears of War 3, lowering the framerate meant adding multi-layered shadows, wind and particle effects, and levels that changed in real time. Sure, the next-generation hardware will be beefier and likely capable of 60fps, but sticking with 30fps may simply become a choice similar to what Epic Games made."

Its still all conjecture. That's 3d C++, this is 2d javascript.

Show me the money.

— i understand your frustration and thus i will not respond to your insults,but the only one you have to blame is your self ,for putting all these man hours into something that it is not feasible with today's tools.

whatever YOU do to improve your game will always rely on other people work and it will not work as intended.that is the reason i posted on this thread to help people realize what is possible and what is not with c2 as to this moment.

there is no easy way around (although c2 in damn near) real programming.

have you ever paused to think for a minute what will happen if you successfully deploy your game to app store,you find a bug ,want to re upload and ludei releases v2021541 of cocconjs, apple changes something , and everything crashes?

i am not your enemy here my friend.i just want to point out that c2 team has VERY limited resources and it would be better to use that little time to something better.i want as more as you to produce an ios game and make 100000$ (yeahhhh!) but i am realistic and i know i just cant at this moment.

i know that i will become flamed for saying this but here it goes. don't spend man hours in something that you think it will work.most of the time ,it wont. and since we are not programmers we cant do anything to fix that.

love to you all!

I'd much prefer being able to set the resolution than the framerate. If I could force my game to a set resolution by changing the monitor resolution, that sounds like it'd eliminate any framerate wonkiness that may occur on slower/older devices that may try to run the game at a higher resolution than the machine is capable of, and would work (in theory) across multiple platforms.

In the long-term, as Ashley said, why would you purposely slow your game down for machines that can handle it better? Though I say that with not really being worried about mobile right now, nor having tried C2 projects on mobile, so take this with a grain of salt, but...that seems kind of silly and short-sighted, and indicates to me it may be high time to see about optimizing your project if you're having framerate issues. The technology behind how C2 works is still relatively new, and it's only going to get better...so why hamstring yourself when there's so many interesting developments going on in the HTML5/javascript/jquery not to mention C2 world?

jayderyu: That's a 100% false equivalence. Gears of War was designed to run on ONE specific machine with a known featureset and hardware configuration that is/was incapable of running the game at 60fps. C2 games are, in general, not developed under such rigid requirements. Comparing the two is about as inaccurate a comparison as I could imagine, putting aside the huge technological differences between the engine running GoW & C2.

60fps has for decades been the goal of game developers (on computers, at least, and in general consoles aren't so different) as that's just about where humans aren't able to tell the difference in fps any more. There's no reason that goal should change just because some hardware isn't capable of achieving it, and as it's been settled on as the standard refresh rate for LED monitors - I think worldwide? Not totally sure, but pretty sure - for some time now. The argument that prettiness outweighs gameplay & smoothness/responsiveness seems counterintuitive.

Roccinio I really do apologise if anything I said came across as insulting. That really was not my intention. My main point was to say you're still pretty new, right? I've been here for 2 years, and I originally didn't even have an exe exporter.

I'd hate to call my time wasted. I've been checking my game quite frequently on mobile devices, and 3-4 months ago, it was running perfectly fine. I'm not sure if I've changed something along the line that has slowed my game down, or if C2 or CocoonJS is what has changed, but after having several months thinking your game will work, and then being told the exporter will improve things, only to have it break... I felt that if I 'cut my losses' I would be even worse off.

I find myself waiting for the next version of C2 to come up hoping that I'll be able to get faster speeds. Those 2fps really would make the world of difference to me.

At least now I have a finished project, so when the time comes that I can release on those devices, I'll be a happy chappy. I've also been focussing on upgrading artwork and fixing bugs for the last 3-4 months, so I'm pretty sure I've got a bug free game (we hope) <img src="smileys/smiley36.gif" border="0" align="middle" />

In any case, that's going off topic. I would really like to apologise again if I had insulted you. I've looked back through my post, and the only thing I can see was the jab at the end regarding posting without spaces. That's just a personal pet-peeve, and I only hinted it toward you rather than targeted. In any case, sorry about that.

I've seen your posts before, and you're always very polite, so I'd hate to think I'd been rude to one so nice.

The technology behind how C2 works is still relatively new, and it's only going to get better...so why hamstring yourself when there's so many interesting developments going on in the HTML5/javascript/jquery not to mention C2 world?

digitalsoapbox For me, the thing is that we're in a digital distribution age. I'd like it if we could release a 30fsp game now, using the tools we have available to us, and then when things are faster, we can switch off that limiter, and just be happy with 60, uploading our improved version over the old one.

I do not feel my game is overly ambitious. I do not have parallax backgrounds, I have around a maximum of 4 layers, a small amount of particles, and generally no more than 170 objects per each level. With approximately 20 on screen at any one time.

My game isn't overly ambitious, but for some reason Cocoon just doesn't like physics. Of which I generally have 1 non-immoveable object. I've waited for Cocoon to sort their plugin out for months, and halving the fps just seems to be a useful assist until Ludei pull it together.

I feel if it helps people get their products on the digital shelves, it's not too hard to change, and there is a demand for it, it should be done.

But this is Ashley and Tom's 'baby'. If they feel strongly enough that it shouldn't be added, they shouldn't feel the need to add it.

AnD4D I hear what you're saying, but with the new phones coming out this current generation able to handle 60fps, spending the time on such a feature when it's not likely C2 is actually what's at fault here may be a case of diminishing returns, a band-aid to cover up inefficiencies somewhere down the line that are being phased out as technology progresses and exporters like CoCoonJS & Webkit improve. The downside of C2 being HTML5/JS-based is that the technology is new and there are the occasional hiccups; the upside is that the technology is not going anywhere and is only going to get better over time.

Does a short-term fix outweigh long-term benefits? I don't think so and I'd rather see platform-agnostic additions & improvements to C2, but I also understand that some folks may just want to get their first games out there and published so they can move on to the next project.

Some time ago I was intrigued by the result of oscillating dt over the maximum height of jumps, like some users have reported. I had the idea of trying to smooth dt over time to reduce oscillations, and googled to see if there was something about this on internet. I ended up finding this very interesting read:

http://bitsquid.blogspot.com.br/2010/10/time-step-smoothing.html

It's quite easy to implement and maybe can have a positive effect on the visual "jerkiness" of oscillating fps. I made a test with a much more rudimentary smoothing than the one described in the article, and at least for the varying max jump height problem it improved considerably (note how the orange dt max height oscillated a lot, while the blue smooth dt max height stays almost constant).

Maybe it could be implemented in C2 with an option that goes from 0 to 100 (that lerps from the original dt to a smoothed one) allowing to choose between compromising distance versus timing precision.

I also had stumbled across these articles describing a method of how to make a fixed time step properly work in different refresh rates:

http://gafferongames.com/game-physics/fix-your-timestep/ (see "Free the physics")

http://www.koonsolo.com/news/dewitters-gameloop/ (see "Constant Game Speed independent of Variable FPS")

They basically talk about "decoupling" game logic updates from rendering, so that the game step can be constant while the FPS can vary freely. I think it could help with the problem of missed collisions on different hardware as well. But this method would probably require deeper changes to C2 that may not be that easy to change.

Another issue we might not be thinking of is the amount of work to even do it, as it might be something they can't implement without tearing up a lot of other things.

I think that it should be done whenever the next major render engine work happens.

Ya i'm just waiting for the collision & resolution optimizations so we get good performance, when g-sync becomes standard different or stuttering framerates won't matter anyway.

The core philosophy of Construct 2 has always been to make games for the future (hence HTML5 and no native support etc.).

So r150 ships with a half framerate mode. I had a tough time coding it though: I'm not sure how browsers handle their tick rate when they can't hit v-sync rate. So the current implementation uses a magic number: if the next tick comes within 29ms of the last tick, it skips it. I've tested it on a range of platforms and this was about the necessary value to actually hit the half-vsync framerate. For reasons I do not fully understand, smaller values still sometimes allowed higher-than-half-vsync framerates (e.g. with a 25ms detection, IE would sometimes still happily run at around 40 FPS on my 60 Hz display, even though Chrome and Firefox would hit 30 FPS). On top of that on some of the phones/tablets I tried I'm convinced even though the framerate counter was at half-vsync (e.g. 30 FPS), the display was way worse and janking horribly. I think this means when the performance is poor some browsers give up trying to vsync, and since this algorithm assumes ticks arrive on vsync intervals only, it starts going choppy in the 30-60 FPS range. I have a feeling it might be hitting 30 FPS, but in a really irregular fashion which is not at all better than a variable framerate in the 30-60 range.

On top of that due to the 29ms magic number, it will incorrectly skip frames on displays running at above about 70 Hz. In this case I think it will keep skipping frames even when the framerate drops below half-vsync, which will unnecessarily further degrade performance.

I did argue against it, but I've done what I think best and I'm not at all confident this implementation is adequate. So let me know how it works for you and on which platforms with which browsers. I have a feeling that this kind of accurate synchronisation might be an area that javascript/browsers are not well suited for. Or maybe there's a better timing algorithm that I'm not aware of yet.

Ashley

Glad to see that it's being attempted.

I know it's not optimal and is a way to downgrade the game's load VS optimization of the game/engine. Hopefully it can be worked with to make it a way to smooth the framerate for some people.

If it doesn't work well with a lot of things and requires a bunch of rework, I assume we would understand if it was temporarily removed for such work. If they know there is plans for a better way to halve the load for performance I think that'd be okay.

---

Also for the thing about crappy framerate in flash games, a lot of people put up with it until computes caught up but a lot of people also didn't start making very complex/high quality games until computers could handle it.

While the PC market can handle pretty much everything C2 throws at it, especially with Node-Webkit, I think at least planning for it was a good idea because people probably don't want to wait to the mobile market to upgrade their devices to near nexus-5 specs.

Hopefully Tizen and FirefoxOS function well and take hold in the market, or someone makes a good wrapper that can optimize how C2 accesses the device so it can have more frames processed smoothly. There seem to be too many problems with the current wrapper solutions. Framerate limitation is just a stop-gap.

Ashley - thanks for trying! I hope this proves to be worthwhile for all of us and that we haven't wasted your valuable time. In my imaginary world I thought it would be a simple case of halving the canvas update rate.

Downloading via mobile internet connection (!) so I'll have a look much later today...

You can't just half the tick rate, otherwise at 40 FPS you fall all the way to 20 FPS, and you definitely don't want to skip frames if it's a slow device and going to run at half-framerate anyway. It has to be smarter than that and try to schedule at exactly half vsync rate only when the framerate is higher than half vsync.