Am I misunderstanding isFixed?

[TobiasWehrum]

Hello,

I've been using the runner with a isFixed framerate of 60 so far because I assumed that it would mean it updates 60 times per second, independently of the actual FPS (which might be lower due to rendering in my game on low-end mobile devices) by accumulating time like e.g. described here (4th listing).

Instead it seems that if the framerate drops to e.g. 30, it will only execute the physics 30 times while pretending the timestep is 16ms. That leads to the physics reacting half as fast.

Am I misunderstanding something here? If not, what would be a potential use case for this implementation of isFixed?

edit: Okay, to add to this - I just made my own runner using the code described in the link above and it works well with any framerate. I also tried to make it work with dynamic framerates by just calling it e.g. 30 times a second and using 1000/30 as the delta. However, it seems to be running at half speed, just as isFixed before. Is the delta time not used at all?

edit 2: I just tried the default runner without isFixed and if I set 60 FPS, but the app is running at 30 FPS because of rendering, physics seems to still run at half speed. So it's not an isFixed issue, although I am still unsure what isFixed is useful for.

I guess the actual title for this question would be "How do I cope with lower framerates? Is deltaTime doing anything?" Is the only/recommended way to cope with lower framerates to write your own runner and lock it to 60 calls per second via accumulation?

[liabru]

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