The real answer is don’t ever lag, and yes I’m working on that. But, when say one frame takes 200ms instead of 20ms (made up numbers) the mouseAxis * deltaTime is suddenly a sharp 50 degree turn instead of the intended 5 degrees, causing the player direction to change aburptly.
I’m considering how to predict this and prevent it and was wondering if anyone has tried.
I’m thinking of watching the average recent realTimeSinceStartup - last frames realTimeSinceStartup and dampening the camera movement if it spikes in any give frame.
I think imposing a hard cap would be a bad idea, I know some players prefer high sensitivity.
Hard tied to the mouse axis * frame rate, yes. And there are some players that play on really old systems that only run 10 fps, some that run 150+, some that use super high resolution mice, etc. I don’t think lerping will work because I’d have to impose a max per frame, though if I took into account the average frame rate and the mouse sensitivity settings, maybe…
So considering a (hypothetical) scenario where the mouse has just moved one inch in the last frame (irrespective of mouse resolution). Now further considering 2 potential situations (a) that last frame took 0.1s and (b) it took 1s. In the case of (b) did we actually have:
Case (a) + a frame lag of 0.9s with no further mouse movement, or,
Did the mouse genuinely move 10x slower across that full second?
To my knowledge there simply is no way to know the answer with complete accuracy and, even if you did, you have still ended up with the on-screen result being 1 inch (* mouse resolution) behind where it should be.
There would seem to be an analogous situation here in some networking algorithms when they try to represent the ‘current position’ of a network-connected object. There they smooth interpolate on small frame deltas but ‘teleport’ on large deltas. Maybe something like that is worth considering?