Update function call rate

[hellspawn_bg]

A noob question over here. Is it safe to update the position of the character in the update function. My concern is that on faster devices the character would appear running faster than on slower ones. How can I make sure that on faster devices the update function will not be called more than 60 times per second and the game would look as smooth as on slower ones, running exactly on 60 frames? Is it something that is build in phaser, or do I have to implement some custom logic to work around this?

 

Thanks in advance!

[JUL]

http://docs.phaser.io/Phaser.Time.html#advancedTiming

 

I think this might help.

[hellspawn_bg]

Thanks, Jul. I usually use advanceTiming to debug my current frame rate. Does it have any impact on the frame rate or is it just intended for profiling? If set to true does it restrict the frame rate to 60 frames on faster devices?

[JUL]

I don't know.

 

I see it as potentially useful to solve your problem, but I've never used it, and I've never planed to regulate the frame rate.

 

"How can I make sure that on faster devices the update function will not be called more than 60 times per second"

 

I think it just can't.

Unless you change the delta cap value, it's 60fps max no matter what.

 

Not sure about that though, rich could certainly enlighten us.

[lewster32]

Phaser will run at 60fps maximum using requestAnimationFrame - it should never run faster than this. It can however run slower than that, so if you have to ensure a consistent speed for something to happen at you have to factor in the elapsed 'delta time' (the time taken since the last frame) as a multiplier.

// Get the time in seconds since the last framevar deltaTime = game.time.elapsed / 1000;// Move the character to the right at 500 pixels per second, regardless of frameratecharacter.x += 500 * deltaTime;

[Sebi]

Almost, requestAnimationFrame runs as fast as the monitors frame/refresh rate which can be 120 fps for a 120Hz monitor. (of course most people don't have those)

But as said, the best would be to travel over time, using deltas, instead of frames.

 

http://www.blurbusters.com/wp-content/uploads/2013/08/InternetExplorerRequestAnimationFrameBenchmarks.png

[chg]

Almost, requestAnimationFrame runs as fast as the monitors frame/refresh rate which can be 120 fps for a 120Hz monitor. (of course most people don't have those)

But as said, the best would be to travel over time, using deltas, instead of frames.

 

http://www.blurbusters.com/wp-content/uploads/2013/08/InternetExplorerRequestAnimationFrameBenchmarks.png

50Hz is also an uncommon but possible refresh rate eg. where a PC is connected to a PAL "television" via HDMI

[hellspawn_bg]

Thank you very much everyone. lewster that can actually solve my problem, thanks

[lewster32]

I wasn't actually aware RAF ran above 60hz - it makes sense that it's synced to vertical refresh but for some reason I figured it was capped. I guess in the majority of cases (almost all modern flat-screen displays, mobile phones and so on) you can expect 60hz, but yeah, there are gaming panels, CRTs and newer mobile screens which support higher refresh rates. Interesting stuff Sebastian!

[hellspawn_bg]

So, should I set the advancedTiming = true or deltaCap = 0.016?

[lewster32]

I'm not sure either will help with what you're trying to do. Just ensuring that your objects are moved by consistent amounts in a way that respects the frame rate via the deltaTime method should be enough.

[hellspawn_bg]

Hi, lewster. The deltaTime method doesn't work as expected, because game.time falls behind 'real' time when running on 50hz. Opened a separate topic with example.

[lewster32]

Yeah I've just replied - taking a look into the code to see what's going on...