FPS handling

[Jon Goikolea]

I'll start with an issue I'm having and after that I will pass to a more generic thought.

 

I'm using this game loop structure, using requestAnimationFrame:

requestAnimFrame = (function() {  return window.requestAnimationFrame ||     window.webkitRequestAnimationFrame ||     window.mozRequestAnimationFrame ||     window.oRequestAnimationFrame ||     window.msRequestAnimationFrame ||     function(/* function FrameRequestCallback */ callback, /* DOMElement Element */ element) {       window.setTimeout(callback, 1000/60);     };})();gameloop=function(){       //Here I do my calculations and drawings       //I do this in order to calculate FPS       thisLoop=new Date;       var fps=1000/(thisLoop-lastLoop);       lastLoop=thisLoop;       requestAnimFrame(gameloop);    }

It works fine both on Chrome and IE, at a steady 60 fps pace. But when running on Firefox, FPS counting goes over 60 (it sets around 65) and the gaming experience is a lot worse, not smooth at all because I suppose the screen might be dropping some frames.

 

I read of setting a time-interval alongside the requestAnimFrame call but I don't know if it's the solution. Any thoughts?

 

Having said that, a more broad question.

 

MAKING GAME LOGIC FPS INDEPENDENT. This has been taking some of my time lately. I've tried a couple of methods to do that. In the first one, I use that fps data I'm getting to do the pertinent speed corrections every cycle with fresh data. Then I tried to do the same but using a mean value calculated over some cycles. I'm getting buggy results either way (what else!). Is this the correct approach? Which is the lowest FPS you handle in your games?

[rich]

A couple of things:

 

1) It's impossible to get consistently perfect and high frame rates across all browsers (even so called 'modern' ones). It's the holy grail of html5 games, but it doesn't exist yet.

 

2) The best way to do it is to use WebGL and avoid dom and canvas. This is useless for mobile of course, although that is changing.

 

3) You need to use a delta timer and multiplier to smooth out the motion. Here is the approach I use:

 

First I define a multiplier (this is on a sprite level basis):

 

sprite.multiplier = 0.001 * pxPerSecond;

 

 

pxPerSecond is how many pixels I want my sprite to move in exactly 1 second (1000 ms).

 

In your update loop:

 

now = new Date().getTime();delta = now - (time || now);time = now;sprite.x += sprite.multiplier * delta;

 

 

You will find that even in the latest and great hardware accelerated Chrome, the time it actually takes to move and the time you expected it to take will vary. For example I just ran a few tests and I was moving my sprite at 250 pixels per second for a distance of 500 pixels. So naturally it should have taken 2000ms to complete, but it was taking on average 1984ms. This is just due to the way things work in browser and there's not a whole lot you can do about it.

 

In terms of frame rate honestly getting 30 fps on mobile is pretty hard to do consistently With DOM it's easier, but only to a point. It's changing all the time though, mostly for the better!

 

Cheers,

 

Rich

[Jon Goikolea]

Thank you Rich. Got some fresh ideas from your writing.