Same - an automatic save of tab order and tabs open would be great.

+ Loads for me too. It is possible to code tweens with a bit of thought and research or you can use the Lite Tween plugin if you don't worry about future compatibility or access to the Scirra arcade. However, I think that having these built in would be great.

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?

OK, first impressions:

From testing on my Laptop (FW31ZJ on Chrome, wheezingly old but reliable), i9100 Samsung S2 & Toshiba Excite tab (both in Android Chrome and CocoonJS) and iPhone 4S (Safari). Tested using a couple of embryonic games I have.

Bottom line: I?m not convinced....

On laptop (Chrome):

Is there a bug (?). If I set reduced framerate in layout 1 then this did not translate to layout 2: the game then played at 60 fps. If I set the reduced framerate in Layout 2 then all worked as expected (on Chrome in Windows 7).

Reduced quality on laptop. This is not because of the reduced framerate; to my eye it appeared that the game framerate was varying slightly even though the fps showed a constant 30.

Mobile / tablet:

Within CocoonJS (not compiled to apk ? only in debug app). I add this for interest as I know this will not be a direct concern. With reduced framerate enabled, CocoonJS debug display shows double the framerate I would normally expect (approx 120 on the S2) while on an on-game fps display I had the fps was shown as 60 and not 30... Wierd.

On mobile (Android Chrome / Safari): Results of variable quality. To be honest, I didn?t notice any significant improvement in the quality of the displayed games when they were capped at 30 fps, as if ? similar to the case with the laptop browser ? the update rate was changing ever-so slightly during play even though the indicated fps figure was a constant 30 fps. This was similar behaviour I had observed when the fps was not capped, so this was not an improvement in my opinion.

So, I now take a big fat slice of humble pie. I think that Ashley was right on this one (I owe you at least one beer!). Unless there is another way to cap the fps at a solid rate with less jerky results, this isn?t the solution I was hoping it would be ? at least for my needs. As previously mentioned, the fix will probably be to be patient and wait until mobile browser / cpu technology catches up. Sigh.

Anyone else any thoughts?

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

I understand the views from those who don�t want this feature but I see it as an opportunity for us to be able to make C2 games that will be playable on a wider variety of hardware. Ashley is right to enable this feature - if a device exhibits signs of suffering then the developer will be able to strangle the fps and preserve game-play. Thus those playing on $1000 phones will not feel short changed and neither will a 14 yr old who is using dad�s old Samsung.

I hear doors opening....

Here is a beautiful and elegant example of how to do all of these. Have a look at the capx about 1/2 way down the first page of this thread, courtesy of Yann.

Ease In and Ease Out Functions

What Arima said.

When everyone owns a Nexus 5 then I might be less inclined use this feature. My target audience, when not using desktops, will most likely use handsets with ?average? processing power. The option to switch the frame-rate in-game if demanded by the user or by a carefully written algorithm would be awesome and would give the player the best possible experience for their hardware.

Ashley,

This is an excellent move, thank you VERY much!

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!

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

Maybe it will magically fix itself in the near future.

I'll get my coat....