Gameplay during lag

[archbirdplus]

Currently, Cubyz physics, networking, and graphics rendering run sequentially. Lag spikes in each affect all of the others. Most noticeably, this means that during lag spikes you cannot jump or change direction.

Two solutions:

• Do physics/networking in a separate thread
  • This might cause its own stuttering and performance penalties
• Between frames, perform several extra physics ticks in even time intervals
  • This would require recording historical inputs for a bit - at that point we could also just calculate physics straight away

I don't know yet if it's going to yield a tangible benefit.

Tangentially related to #532.

[IntegratedQuantum]

Is this actually an issue outside of software rendering?

Also the second option is not going to work. It would only help if glfw gave us a timestamp for mouse and keyboard events. So the only solution would be to use an extra thread, which like you say has its own problems.

[archbirdplus]

If your gpu is sufficiently weak, then framerate would have an effect. My favorite case is running diagonally into a wall, where there is a one block wide gap. At high fps, you would enter the gap as you should. But at low fps, you can sometimes skip over it. Pressing space and releasing quickly will also sometimes fail to get polled.

We could take our own timestamps during glfw events callbacks. But then I also don't know what the latency of that is. It'd basically be delegating the threading to glfw.

If anything, we could just extrapolate the current inputs over the last frame duration, as we do now, but with more granular timesteps.

[IntegratedQuantum]

We could take our own timestamps during glfw events callbacks.

The events are only processed when calling glfwPollEvents which is currently called from the render thread. It would need to get called in its own thread to work,