Different simulation speed on higher refresh rate monitors

[BeckettOBrien]

Hi! I've been playing around with matter-js and noticed that when I switched from my laptop to a high-refresh rate display, the speed of objects falling under gravity increased dramatically. When I change the monitor settings down to 60 Hz, the object falls normally. I tried using this when creating my runner:

runner = Runner.create({
    isFixed: true
});

but the simulation looks the same. Is there anything I'm missing? Thanks!

[wokalek-work]

@BeckettOBrien can you provide full code or at least part with renderer?

[liabru]

Yeah that looks like it should work, could you share a minimal working example?

[BeckettOBrien]

I recorded an example on the matter-tools demo and I added a breakpoint before starting the runner and set isFixed to true. It isn't noticable in the video, but I changed my monitor's refresh rate from 240 to 60 Hz in between both example drops (around 10-12 seconds into the video). I also tried changing my G-SYNC settings between fullscreen, windowed, and off, but nothing changed. If you need any more information, I'd be happy to help!

demo.mov

[liabru]

Ah I see - what you need to do is make sure you set the correct delta e.g. runner.delta = 1000 / 240.

You'll likely need to detect the frame rate of the browser though for it to be portable, or a better solution is to implement frame skipping and limit it to e.g. 60fps fixed.

Matter.Runner doesn't yet have these features as it is designed for debugging and simple uses, but I do hope to get around to it now that high frequency monitors are becoming common.

[BeckettOBrien]

I started messing around and found that if I comment out the delta limiting (deltaMin and deltaMax) it seems to work out. The odd thing is that if I just set the deltaMin and deltaMax to values that would make it just not matter, it doesn't seem to do anything. And even if it did, would this come with any unexpected behavior? Also, I saw that there is a pull request open for fixing timing/frame rate inconsistencies: #777, would this be one of the issues that gets solved in that pull request?

[Errorbot1122]

You could also try Engine.Update()
https://brm.io/matter-js/docs/classes/Engine.html#method_update

//put in the main animation loop, returns an array with [FPS, delta, lastCalledTime]

function getCurrentFPS(lastCalledTime) {
     if(!lastCalledTime) {
        lastCalledTime = Date.now();
        fps = 0;
        return [fps, 0, lastCalledTime];
     }
     delta = (Date.now() - lastCalledTime)/1000;
     lastCalledTime = Date.now();
     return [1/delta, delta, lastCalledTime];
}

and you could use it like this:

var {Engine} = Matter;

var engine = Engine.Create();

var lastCalledTime;
var fps = 0;
var delta = 0;

function getCurrentFPS(lastCalledTime) {
     if(!lastCalledTime) {
        lastCalledTime = Date.now();
        fps = 0;
        return [fps, 0, lastCalledTime];
     }
     delta = (Date.now() - lastCalledTime)/1000;
     lastCalledTime = Date.now();
     return [1/delta, delta, lastCalledTime];
}

function MainLoop() {
   // Get "getCurrentFPS"'s Output
   GCFPSOutput = getCurrentFPS(lastCalledTime);
   
   // Set fps, delta, and lastCalledTime
   FPS = GCFPSOutput[0];
   delta = GCFPSOutput[1];
   lastCalledTime = GCFPSOutput[2];
   
   // Updates engine with delta
   Engine.Update(engine, delta*1000);
}

[fcisio]

Hey, the solutions above didn't work for me.
Are there any updates on this?

[Errorbot1122]

sorry, I commented on this so long ago, that I forgot how it works :p

[liabru]

Closing this thread to refer to updates in #702 on this topic, thanks again for the reports here.

[liabru]

As of 0.20.0 there is now built in Matter.Runner support by default for fixed timestep with high refresh displays see #1300.