Finally fixed a client-side rendering issue I introduced while trying to implement multiplayer.

See, for normal entities, their positions are only updated roughly every 3 frames (1 tick w/ 20tps & 60fps). Because of this, the render thread actually keeps track of each entity’s current and last position, and then interpolates between those positions based on how far through the current tick is when rendering. This is the same method I used for determining the camera position for the player. However, there is an issue with this method.

It’s very hard to get the tick thread to run on an exact 50ms interval because of OS-level limitations. Because of this, based on how the render/tick threads are aligned, the render thread may find that the value used for seeing how far along the current tick is (usually 0.0-1.0) is actually 1.0+. When this happens, it causes visible stuttering and jittering with entity positions.
Now, this issue doesn’t really affect entities, as there is a simple solution, which is to simply keep a slightly larger buffer of entity positions. Then, instead of using the current/last tick positions to interpolate, it uses the 2/3 last positions in the buffer, allowing the tick thread some wiggle room.

Of course, this doesn’t work for the player, which needs to update visually as quickly as possible. And I finally made the connection that this method I was planning to use on other entities wouldn’t work on the player. So I’ve finally changed the engine to query player input and apply player physics every frame, separate from all other entities, and I’ve refactored the physics system to be able to handle being called at differing rates (20tps vs 60fps);