[REQUEST] Developer to set FPS

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.digitalsoapbox2013-11-11 18:49:31

@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)

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.

[QUOTE=digitalsoapbox] 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?[/QUOTE]

@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.AnD4D2013-11-11 20:21:07

@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.digitalsoapbox2013-11-11 19:36:30

[Animmaniac]

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.Animmaniac2013-11-11 21:46:52

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.).alspal2013-11-12 02:21:01

[Ashley]

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.Ashley2013-11-12 12:09:41

@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.Thndr2013-11-12 22:43:42

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