Suggestion: Separate update loops

[ITR13]

Currently physics are framerate dependent, which can cause inconsistencies down the line. A common solution to this is having physics only run at a fixed rate (I.E. 60 or 120fps) with a potential catch-up mechanic if rendering is slow.

Some benefits from this:

• 599 Can probably be fixed by making sure something doesn't update too frequently

• 533 Can be alleviated by allowing multiple "physics" frames and input polls per full render.

• Vsync can be made to only affect the "rendering" rate.

Some drawbacks:

• Rendering would require interpolation of physics (I think this is already implemented for networking though, so might not be a huge change?)
• Would require a larger amount of work to split physics and non-physics updates

[IntegratedQuantum]

Another disadvantage is that it would increase input lag for players without vsync, because the physics will always be up to one physics tick behind the player input.

I think #599 is happening because the player moves an amount smaller than the margin used by collision. A solution would be to find a way to store more exact collision results without a margin.

533 can be solved by just implementing the catch-up mechanic without fixing all updates to a certain frequency.

[ITR13]

Another disadvantage is that it would increase input lag for players without vsync, because the physics will always be up to one physics tick behind the player input.

This is the case for almost any game though, even competitive ones. Could also be possible to separate stuff driven more directly by player input like rotation or placing/removing blocks & interacting with UI to not be bound by a rate.

I think https://github.com/PixelGuys/Cubyz/issues/599 is happening because the player moves an amount smaller than the margin used by collision. A solution would be to find a way to store more exact collision results without a margin.

Hmm, collision does in theory set the position to the collision point near the end of the frame though. I tried disabling the spring & friction logic in case it was that, but didn't seem to do anything. I'll try disabling that part and see if it is.

https://github.com/PixelGuys/Cubyz/issues/533 can be solved by just implementing the catch-up mechanic without fixing all updates to a certain frequency.

That might not work since the physics happen so quickly. If the GPU take 16ms to render for example, and the physics only take 0.1ms, then it could end up doing all the catch up physics frames immediately then have to wait for the GPU to finish rendering before it can bind it again. I guess if vsync was made to only affect rendering then that might automatically balance it though (or maybe that's what you meant?)