– I’ve added a new somewhat working extrapolation mode featuring collision-correction. It seems to be doing something, but it behaves a bit jerkily (which I had anticipated to some degree). The question is if it’s possible to improve it much more. I doubt it, but might look into it at least a day or two again.
– Added a proper new minimum update setting for the host, which sets minimum amount of milliseconds between each position-update. Using this I then tried out all modes I’ve been working on and noticed some more .. issues, or rather inherent requirements to my implementations which I was not entirely aware of before. For example both the Interpolation and Extrapolation will NOT work/look good if the synchronization delay is within a certain range. For Interpolation it should be positive or at least above the minimum update delay of the host. Similarly but inverted for Extrapolation, the sync delay has to be negative or at least below the minimum update delay of the host.
For a concrete example using Extrapolation consider the following:
– The Host has set minimum update delay to 200 ms, meaning we should get on average 5 updates per second.
– The time adjustment is set automatically on the client to -54 ms (This game-time concept has made me more confused than it probably should, not sure if it’s affecting anything really as this is just a visible indicator of a change it has done, not anything dynamic).
– Recommended sync delay (which in this case translates to the time we want to estimate in the future) should thus be around -200 or below for the extrapolation to work decently. With a sync delay of >200 ms it will detect a mismatch and only display static updates. At 150 ms the static updates will have a few extrapolation updates mixed in, giving erratic camera movment. The lower you go, the worse it gets, and at 0 ms delay the camera jumps each other frame. At -50 ms the algorithm manages to arrive at infinite numbers, requiring a hard reset in the code (which I added after discovering it now). Naturally that also means that the camera is rendered useless, trying to follow a player the estimator thinks is waaaaaaaay off from the map and all relevant entities/game content. -100 and -150 yield similarly unusable or erratic results, and only when reaching -200 does the camera and player entity return to where they should have been (after a few seconds of “correction”. Using a value of -200 causes visual artifacts and if lowering the value even more the errors will become even more obvious, but the movements also become a bit smoother.
A similar description of the above is also valid for the interpolation, except that the errors are not nearly that dramatic, but still not pleasant, and the interval is instead around 0 for static movment up to full interpolation at a sync delay of around 200.
Not sure if that made sense, but it serves its purpose of me documenting the tests anyway. Next up I will look through my plan and start evaluating what I’ve done so far vs. initial expectations, try and do some tests with simulated distance/lag and maybe try and investigate if I should try to improve the collision-correction or not (scoping issue, really). Anyway, I feel that I’m slowly starting to really understand what I’m working with. Have had a bit of a hard time keeping track of all numbers I threw in for the quick iterations, and some are maybe not used anymore (like the “Extrapolation smoothing duration” I had earlier with the erroneous previous solution).