Framerate issues at 144hz

[EJanuszewski]

Hi all, I'm pretty new to this and I'm only really a beginner JavaScript developer too so sorry for potentially being naive.

I can't share code as I'm not at my PC now but essentially I've got a mesh that I'm moving with the arrow keys, (player.position.x += .1; as an example) however on my 144hz monitor it moves twice as fast due to running more frames, does anyone know what the solution to this would be, or point me in the right direction and I'd love to try solve it myself.

Cheers,

Edward

[Ahiru]

You could use: player.position.x += 0.1 * scene.getAnimationRatio();

 

This should give you an equal movement independent of the actual FPS-Rate.

[RaananW]

Hey, just wondering - how does your [N]Hz monitor affect the FPS? 

[Ahiru]

Don't think it's really the monitor? I understood he tried on two different computers - one with better specs (and the better monitor) and one on a lower one? That was just my guess 

[EJanuszewski]

@Ahiru

Awesome I'll give that a try out later.

@RaananW

Since I request animation frame and it refreshes 144hz that means it requests frames at 144fps, I confirmed this with the debug layer too

[Ahiru]

The monitor actually won't make any difference - the rendering is using requestAnimatonFrame, which limits the FPS to 60 FPS max - independent if your monitor has 50, 100 or 144Hz.

[RaananW]

That's what I thought, and this is why I asked...

You can fake a higher fps with setTimeout (or setInterval fro that matter).

Besides, babylon's engine is actually taking out the need to use requestAnimationFrame.

[jerome]

Besides, babylon's engine is actually taking out the need to use requestAnimationFrame.

 

What do you mean ? no RAF any longer ?

[RaananW]

What I mean is that you never use it yourself. It is already integrated in the framework :-) So using it on your own will (i can only assume) drive the engine a bit crazy

[jerome]

aahhh... oki oki oki

[chg]

The monitor actually won't make any difference - the rendering is using requestAnimatonFrame, which limits the FPS to 60 FPS max - independent if your monitor has 50, 100 or 144Hz.

To quote Mozilla's docs: "The number of callbacks is usually 60 times per second, but will generally match the display refresh rate in most web browsers as per W3C recommendation." https://developer.mozilla.org/en/docs/Web/API/window/requestAnimationFrame

I believe the standard offers no promise that rAF will max out at 60Hz, and instead that browsers are encouraged to sync to the refresh rate of the video mode (it just happens that 60Hz is somewhat common)

[EJanuszewski]

I am actually using runRenderLoop and scene.render() my pc at home has a 144hz and a 60hz, that's how I spotted the issue, so apparently it doesn't limit to 60

 

I'll try out Ahiru's suggestion tonight at home and see if it fixes it.

[RaananW]

that's really nice to know :-) Will keep that in mind. 60 is not the holy grail anymore...

[Ahiru]

Yes, keep us informed - would be nice to know if the monitor frequency can really influence the FPS - Rate in the browser!! 

[fenomas]

I've got a mesh that I'm moving with the arrow keys, (player.position.x += .1; as an example) however on my 144hz monitor it moves twice as fast due to running more frames, 

 

Short answer: Many games solve this problem by doing "game rules" (processing inputs, doing physics, etc.) in one loop and rendering in another. The idea is that your game rules should probably use a fixed timestep - you don't want physics behaving differently on slow and fast machines - but the render loop can run as fast as the player's machine will go.

 

Long answer - go read this article right now! Required game developer reading in my humble opinion. 

[jerome]

this reminds me some parallelized dream : http://www.html5gamedevs.com/topic/14372-demo-webworkers-for-babylon/?p=81799

[fenomas]

For my game I just run both loops in the same thread, it's pretty straightforward. The render loop runs off RAF like normal, and for the tick loop, I call it at 30fps and I always always pass it dt=33ms, regardless of how long it's really been since the last tick.

[EJanuszewski]

Interesting read fenomas, a lot of it goes over my head as an amatuer but I'm sure I'll understand it in the future

 

Can't believe how much of a discussion I stirred up

[jerome]

@fenomas : what do you mean with "I call it at 30fps and I always always pass it dt=33ms" ?

Do you simply use some JS setInterval() or do you manage your own ticks with some embedded loops (so you get your own time measures) ?

[fenomas]

jerome: It took me a while to figure it all out, but basically I have functions like:

function tick(dt) {   // step game world forward in time by tick_time}function render(tick_dt) {   // for each mesh: position += velocity * tick_dt   // render world}

tick() does things like step the physics engine, handle the AI, apply game rules, etc. The function takes a time step but I always pass it a fixed amount. render() renders the state of the world (including calling BJS render). Note that the render function also takes a dt, and moves meshes along their velocities a little - this lets you run physics less often and still get smooth movement.

 

As for how I call the functions, I use a handy library called game-shell that manages the timing, along with other features. But I think it would work just as well to do use a setInterval for tick() and an RAF loop for render().

[EJanuszewski]

Just a follow up on this, scene.getAnimationRatio(); seems to do the job 

 

So as for tick, as I need the same thing are you saying I can just run a setInterval outside of the runRenderLoop? Do you happen to have a code example you can share?

[fenomas]

Like I said I use that game-shell library, and it manages the timings for me. To do it manually, I would do something like this:

var tick_time = 40  // desired ms between ticks.. 40 would be for 25 ticks/secondfunction RAF() {   var now = performance.now()   var dt = now - _last   _last = now   if (game_paused) { return }      accumulator += dt   if (accumulator > tick_time) {       accumulator -= tick_time       game.tick(tick_time)       last_tick = now   }   var time_since_tick = now - last_tick   game.render(time_since_tick)   requestAnimationFrame(RAF)}

That's off the top of my head, but something along those lines. Note that I don't pass dt to the tick function, I pass a constant value so that I get fixed timesteps. The accumulator variable is so that you get the right number of ticks over the long run, and the time_since_tick variable being passed to the render function is so that it can update mesh positions (assuming they're driven by key inputs or a physics engine.. for a plain animation I guess this would work differently).

 

Does that make any sense? 

[jerome]

What does exactly game.tick(tick_time) do ?

[fenomas]

The tick function advances game rules - steps the physics engine, NPC AI, checks for collisions, or whatever. The purpose of that code is to avoid running the game rules at variable timesteps.

[jerome]

Nice

 

and what are the pro/con compared to an equivalent of tick() just called by a simple setInterval() indepedant from the RAF of course ?

 

I mean :

• render only in the requestAnimationFrame() callback
• physics, AI, controls, etc in the setInterval() callback

say, with setInterval called every 33 ms for instance