[REQUEST] Developer to set FPS

Since C2 uses a high resolution timer could C2 base it's draw.call on that. My math will be off of course as it's only a sample.

But wouldnt it be best to just use a system of

var draw_next; 
var draw_skip =33.2; 
 
while(gamerun){ 
  process_logic(); 
  if( draw_next < timer){  
    draw();  
    draw_next = timer + draw_skip; 
  } 
} 

Here is an interesting post.

koonsolo.com/news/dewitters-gameloop

It works in reverse. instead of limiting FPS down. The idea is to instead always run the game logic at 25FPS and visual updates are rendered as fast as possible. however the interesting part is that if the game rendered less than 25FPS the game logic is still at 25FPS. This is pretty much more ideal in design.

A game logic flow always needs to be at a solid rate. This model could certainly achieve the desires of everyone on the list here.

Visual the game udpates as fast as possible, but logic is always set. This means even if the game hits heavy render areas where the game can slow down to a crawl logic still flows the same AND this means the game play remains smooth no matter what is happening.

This sounds like an ideal goal.

The Gameloop in question is the last one in the list. I think Ashley should check it out. Because let's be honest it's not that we want less FPS, we just want to maintain smooth game play and to do that we would reduce how often to render, but the reverse can also be true AND it could work well cross platform :)

might fill in a question here:

What is a low power device these days ?

I recently got myself a new smartphone, I'm not too hot on the newest and latest and go for price/quality.

2 years ago I got myself the galaxy gio, a little less then 1ghz, 512mb ... not even 100$

2 months ago I got: LG5 something

dualcore 1,2 ghz, 512mb ...... not even 100$

Low quality cheap phones ....

Not to be a nag, but to have phones like these perform badly for which you reqquire 30 fps, I suggest you take a look at your programming.

I still remember the days when they added tables to HTML and half the people argued very heatedly, "browsers are hypertext viewers, it's not supposed to look like desktop publishing!"

Now we are working to get them controlling frame rate to the exact microsecond. I find this so funny.

Tested my game in CocoonjS launcher on Samsung Galaxy S2 with half FPS enabled and the display flickers while it shows me 50-60 FPS .

Here is an interesting post.

http://www.koonsolo.com/news/dewitters-gameloop/

I guess you missed my post at page 6. I posted this exact same article with some other resources.

I've tried skipping every other tick regardless of the timing, and it just halves the framerate regardless of what it is on Chrome for Android. So if it's running at 40 FPS it drops to 20 FPS instead of 30 FPS, and still looks pretty bad.

I'm of the opinion that half framerate mode as implemented does not do anything useful, is too difficult to make work reliably in a browser-based engine, and I'd like to remove it in the next build.

Changing how the engine runs ticks and render frames is another matter and could be considered separately. However again I'm not convinced there's much value there. You want to aim to render a frame every v-sync interval, which is usually 60 FPS. Dropping frames is not much help if the game is logic-bottlenecked (the GPU will do the heavy lifting, not the CPU). Running logic more often than rendering is wasteful of CPU time.

AFAIK this is not a significant problem on desktops. I think it's a problem best solved by waiting. It's not much help in the short term, but in the long term I'm pretty sure everyone will have phones and tablets that can more or less match desktop performance.

Also on reading "deWiTTERS Game Loop", I disagree with fairly significant parts of it: the article goes all the way through without even mentioning v-sync, which is pretty strange. The goal of good game engine should be to draw a new frame at every v-sync interval. Picking 25 and 50 as example framerates are just about the worst examples. Picking 60 still wouldn't be perfect, because it doesn't address the problem that v-sync intervals come at different rates on different devices, depending on the display refresh rate. So that's quite a significant problematic area that it does not attempt to address.

Further the recommended solution proposes moving a fairly significant amount of logic in to the display function. In a good game engine, logic is a modifying operation and display is a read-only operation. The suggested solution sounds like it is really proposing three functions: logic, interpolate_logic, and display. So you call logic() at some fixed rate, then interpolate_logic() followed by display() at a higher rate.

To me this seems a kind of crazy way to design a game engine; it's a pretty big architectural change, and makes the assumption that it's good for performance if interpolate_logic() is cheaper than logic(). In fact if the game is GPU-bottlenecked, there's no point calling interpolate_logic() - you may as well just call the full logic() since it runs in parallel to the GPU and won't impact performance. And I'm convinced that even the use of interpolate_logic() will cause game logic problems far more serious than vanishingly small rounding errors with variable framerates, which will not cause any problems in a well-designed game with reasonable tolerances.

You can also simulate this method in the existing engine using techniques I've recommended previously: run expensive things like collision checks, for-each loops or nested loops on a timer, or at least every N ticks. Then you are effectively splitting your game logic in to expensive logic ticks (logic()) and cheap logic ticks (interpolate_logic()). This is just straightforwardly sensible game design and works well in a variable framerate engine as well, and can be done today without any extra engine options or rearchitecting.

On the contrary I'm of the opinion that the variable rate logic/display cycle is the best solution: it v-syncs nicely at different refresh rates, handles mid-range framerates reasonably well, and is simple to design and reason about (since logic updates and display updates come at the same rate). I think the only disadvantage is really low framerates can teleport objects through collisions, but most systems aren't that slow, and there is a minimum framerate of 10 FPS in the Construct 2 engine.

lennaert :

Well, to me the pb with the 30/60 fps is more on newer devices than older ones.

My game flickers a lot on my Ipad3 with fps between 55/60 for example. Even a drop for 60 to 58 is very noticable.

That's why we are a lot asking to be able to set the fps at 30, to get rid of that, and have a stable framerate : we would prefer a stable 30 than a shaking 60, simply because people will not see they are at 30, but will see the shakes (cause there are really visible).

On older devices, like an ipod4, i'm around 30, so i personnaly don't care on that point regarding an older device (it's more a question of optimization in that case). But maybe people concider that devices (ipad3 for example) as old ones already.

I already uses timers for collisions, i've optimised my game a lot, i've optimized my code, but it's still there, it's not a question of code in that case i think. Of course you can get rid of that by having just 10 objects on the screen or 1 collision test in the layout (i exagerate voluntirally), but if you try to do a more complex game, it's difficult to get rid of that, if you do an action game or a platformer, and use a scrolling.

Ashley :

I don't understand everything because of my limited english and because it's too technical for me, but it seems that if i understand well, you will stop investigating on that. Before everything, thanks to have tried :) , but for me it's a bad news, because of what i said above.

lennaert - I think your first question is valid: what constitutes a mid-range device today? I am sure we could discuss this for weeks as everyone will have a different target audience for their products and, so, a different opinion. Regarding your assertion that poor programming could be the cause of these problems, I am afraid that I must disagree as I don?t think you see the problem. As — points out, those of us who are asking for this feature do so having already tried to reduce the processor loading in our games as much as feasible. However, the issues seem to be caused by things out of our control like the C2 engine processing maths for objects with physics or platform behaviours and trying to do that at the rate of 60 fps (or, to be more accurate, vsync). Try and play a few of the Scirra arcade games on your phone browser and you?ll see the problem we are trying to alleviate.

Ashley - Thanks for devoting a lot of your time to this. Regarding setting a game rate at 30 fps, am I right in presuming that the likes of GMS and Unity just ignore vsync altogether? Regardless, I appreciate the efforts to try and make this work and I, for one, don?t want to ask you to completely re-write the C2 engine to enable this feature. I totally understand that future mobile computing power will probably swallow up this problem in the next couple of years. I?ll just have to teach myself some patience?

lennaert :

Well, to me the pb with the 30/60 fps is more on newer devices than older ones.

My game flickers a lot on my Ipad3 with fps between 55/60 for example. Even a drop for 60 to 58 is very noticable.

That's why we are a lot asking to be able to set the fps at 30, to get rid of that, and have a stable framerate : we would prefer a stable 30 than a shaking 60, simply because people will not see they are at 30, but will see the shakes (cause there are really visible).

On older devices, like an ipod4, i'm around 30, so i personnaly don't care on that point regarding an older device (it's more a question of optimization in that case). But maybe people concider that devices (ipad3 for example) as old ones already.

I already uses timers for collisions, i've optimised my game a lot, i've optimized my code, but it's still there, it's not a question of code in that case i think. Of course you can get rid of that by having just 10 objects on the screen or 1 collision test in the layout (i exagerate voluntirally), but if you try to do a more complex game, it's difficult to get rid of that, if you do an action game or a platformer, and use a scrolling.

—

Is the flickering related to reduced frame rate ? wouldnt your request for a lower frame rate be counter productive then ? i would assume you get more time between flickers ?

Or do you expect that with a reduced framerate the overall processing goes faster ?

Hadnt heard or seen that before :\ granted, I'm kinda new

Got some stuff running slow, but never flickering.

Only time I actually got flickering was with objects outside of the layout with CocoonJS.

And an Ipad unable to keep up ...that must be some heavy game then, you sure you have chosen the right development platform? :P (yoke yoke)

lennaert - I think your first question is valid: what constitutes a mid-range device today? I am sure we could discuss this for weeks as everyone will have a different target audience for their products and, so, a different opinion. Regarding your assertion that poor programming could be the cause of these problems, I am afraid that I must disagree as I don?t think you see the problem. As — points out, those of us who are asking for this feature do so having already tried to reduce the processor loading in our games as much as feasible. However, the issues seem to be caused by things out of our control like the C2 engine processing maths for objects with physics or platform behaviours and trying to do that at the rate of 60 fps (or, to be more accurate, vsync). Try and play a few of the Scirra arcade games on your phone browser and you?ll see the problem we are trying to alleviate.

Hmm, I've encountered many problems with phone browsers and web based apps .. but thats mostly due to the device also having to run a full fledged browser in order to support the html5 aspects. Though my smartphones processing power is nice ... the rather small memory becomes the next bottle neck, not my code. (well, in a lot of situations anyway)

Hi guys, I had made a recording on my Android to show you what I mean by flickering.

The first half of the video is with half framerate mode disabled, and the last part is with it enabled.

The flickering is almost as I see it with neked eyes and has nothing to do with the recording app.

[TUBE]http://youtu.be/SqQuBdox014[/TUBE]

lennaert

Well, as you said you're new, so maybe you have not done enough tests to see what we are speaking about, I don't know.

First, sorry for my english mistake, but it's not "flicks" i have like Cipriux on his video, but a sort of lag. I'm not sure of the good term in english :).

Back to the pb, it's more complicated than what you think.

My game is running between 29 and 31 and my ipod4, which is a (very) good fps for such an old device with a more or less complex c2 game, fps i would have not reached at all without a lot of optimization work on the graphics and code.

When i put it on my ipad2, i'm at a constant 60, most of the time, sometimes 58, with very noticable framerate falls, even if my fps is very good. On my ipad3, i'm more aound 55-57 (don't ask me why compare to the ipad2). But more than that, the fps is not "constant". I wouldn't mind to be on 55 or even 30 or 42, if it was constant, but as the game tries to always reach 60, it creates noticable lags even if you lose just 1 or 2 fps, and even if you have a "good" fps, which is commonly known as 30 and above.

Now again, i can simplifly my game a lot to win fps, but for what i'm doing now, i can't do better that what i did i think, i've already simplified a lot my "art direction", my code, etc. A way of getting rid of that is to not use a scrolling too, but my game is based on that.

Anotehr (good) solution would be to have the memory manager on mobiles (to be able to use bigger images, so less objects, so to win fps), but it's not here now.

That's why i would have liked to have the ability to set the max fps at 30, as a lot of prgram about mobiles do (GS, Stencyl, Unity) to get rid of that pb, simply to have a smooth scrolling at least on newer devices, without the obligation of having very simple graphics.

Now, I'm not the best programer of the world (if I was I would not be on that forum or using C2), i'm not the best C2 user neither, but I just thought that this option would have been nice, and I'm not the only one (with people sometimes using the soft for a long time).

And maybe even setting the fps to 30 would have not solved that pb, I don't know, maybe i'm misunderstanding completely how fps work, but it was for people interested good to try.

So I thank again Ashley to have tried, even if he didn't "believed" in the good purpose of it. At least he tried to satisfy a part of the users and that's very nice!

To finish on that subject, and with all my respect, I can understand that some people think it's a useless feature, but it's not because the feature doesn't interest me for example, that i wiil go on the topic of it to say to people to be better programers, or change soft or target, it's not very helpfull :3. We have all different uses of C2, and sometimes different needs.