FrameRate on mobile devices

[haden]

I am trying various technologies to make Html5 games for mobile, for now I am testing Haxe+Flambe and a small game with 40 entities (sprites) gives me 13-15 frames per second on my iPod touch 4th gen with Safari.

 

My question is: what frame rate should I be targetting when making an Html5 game ? is 15 fps enough ??

[xerver]

You should always be targeting 60 fps. You may not get it, but you should be getting as close as possible. "Enough" is usually whatever makes your game feel smooth when playing, which can be different depending on the type of game it is.

[Chris]

What really makes you feel that a game is lagging are inconsistent framerates. If your game constantly drops from 60fps down to 40 or even more and returns to 60fps shortly after, you will feel it lagging, even if your eyes "cant see" more than 30fps.

For example: a movie runs at 25fps!

 

I remember when I had a GeForce 4200 (thats a few years ago, yes) that managed to get ~20fps on some of the newer shooters - but the card was able to HOLD that framerate, so gaming wasnt laggy.

 

When you use requestAnimationFrame, the browser tries to time your animations with 60fps - more fps don't make sense, since a TFT monitor isn't able to display more than that.

If your game code eats up so much performance that the 60fps cannot be achieved, the browser caps the fps at 30 - even if you could get more.

 

The reason behind the capping after 30fps and 60fps is to make sure the framerate is constant.

 

Yes - you COULD make a game at 15fps, but if thats a matter of poor performance, chances are high that the framerate will rise and drop; this makes your game laggy.

[haden]

You should always be targeting 60 fps. You may not get it, but you should be getting as close as possible. "Enough" is usually whatever makes your game feel smooth when playing, which can be different depending on the type of game it is.

Can you reach 60 fps on iPod touch ? My code runs really fast on iPad 2 (60 fps) but not on iPod touch.

[rich]

Personally I wouldn't bother trying to reach 60fps on mobile. Desktop yes, easily, but on mobile I typically cap my framerate at 30fps.

[haden]

Ok, so I guess Flambe is too slow for the iPod touch.

[Ezelia]

also try to keep your game logic separated from the rendering.
this way, if the browser can't handle the framerate, you'll get "frame drops" instead of lagging game. keeping the game speed constant (but this aproach isn't the best for all game types)

I usually handle game logic with timers and game rendering with requestanimframe

[Aduros]

Are you running iOS 5 or higher on your iPod? That's the version where canvas became usable. It may be that the iPod 4 is just a bit too old, its specs lie between an iPhone 3GS and 4.

 

Flambe's canvas renderer is pretty optimized, so either the slowness is not from rendering or you're hitting the limits on what Mobile Safari is capable of on that hardware.

[Aduros]

also try to keep your game logic separated from the rendering.

this way, if the browser can't handle the framerate, you'll get "frame drops" instead of lagging game. keeping the game speed constant (but this aproach isn't the best for all game types)

I usually handle game logic with timers and game rendering with requestanimframe

 

This doesn't seem like the right approach. Timer callbacks can lag just like rAF callbacks. Why not put everything in an rAF callback, measure the time between frames, and use that in your game logic, instead of assuming a fixed timestep? This also means your game will automatically pause when hidden, which is usually nice

[Ezelia]

I tested many approaches and the one I described is the most performant (in my case).
also I like to control when my game game logic is paused and when no. with timers I can control it, with RAF I can't.

[rich]

I've nothing against your approach, but I struggle to see how it can be more performant. Not having absolute control over when rendering occurs in relation to the game logic doesn't appeal to me one bit. Splitting between raf and setTimer means your game could conceivably render itself a couple of times before the game logic even updates. For heavily network dependant games that need to keep the logic running even if the user swaps tabs then I can see it being useful, if not essential. For anything else I'm having a hard time understanding the benefits.

[Ezelia]

yes I was speaking about multiplayer games

and I don't render my game multiple times, I only update render when something change.
the difference I noticed compared to the classic approach is that the game skip some frames instead of lagging.

what I need is to keep the game running allways at a constant speed (almost at constant speed).

[Chris]

Imho, that approach has no benefits.

Javascript is a single-threaded language, so altough all the stuff you are programming is asynchronous, the execution itself IS synchronous. Behind the scenes, everything is executed in order.

 

So if your game logic blocks the processing, or your rendering eats up too much performance, it makes no difference when you separate rendering into RAF and logic into timers, since they will simply block eachother in execution.

[Ezelia]

I know that, and I can't explaint it .
but in my case I really noticed a significant improve on mobiles/tablets ... it saved my life since without this the cusomer was not buying my game
on tablets the FPS dropped to 30 but we still had the impression that the game was running at a good speed.
without my approach, the FTP dropped to 30 but the game was laggy and too slow...

[Daikrys]

the only thing that could happen with ezelia's code is that the gamelogic was called way to often and my produced a bounce in framerates (as described above), basicly the performance boost just comes from the control the timer gives

[joannesalfa]

Personally I wouldn't bother trying to reach 60fps on mobile. Desktop yes, easily, but on mobile I typically cap my framerate at 30fps.

Yes, it's common when I developed some HTML5 games on iOS (version 5) came between 18-32 fps.

 

I don't think EVERY Android devices would run in decent fps (Except Nexus and Samsung that I personally tested them)

[rich]

the only thing that could happen with ezelia's code is that the gamelogic was called way to often and my produced a bounce in framerates (as described above), basicly the performance boost just comes from the control the timer gives

 

I expect that if you're updating motion via delta timer values (and possibly easing those out over multiple iterations, not just the previous one) then it won't make any difference what actually updates the dt, a timer or raf. However this is a moot point as he clearly confirmed that he needed it for a multiplayer game, and you can't use a raf loop in those cases due to the way they stop if you swap tabs.