On 8/12/2019 at 9:16 PM, hplus0603 said:
I have no idea how the Unity FPS sample does it.
Perhaps you can adjust the FPS sample to make fractions of small adjustments if you receive a small delta, and only make the "big jump" adjustment if you really end up with a big offset.
One possible, somewhat simple implementation, is to make the server send back in each packet "I received commands for tick X when I was at tick Y" (which is really just a simple difference) and "your adjustment value was Z."
The client will send its adjustment value to the server, together with the target tick number.
The client can then easily adjust its adjustment value to target a specific number of ticks-ahead -- say, 2.0. Because the server tells you what the offset is as well as the delta, you can adjust the offset correctly without much risk of feedback / oscillation. If you don't want to include this value in each packet (it's 4 to 8 bytes, depending on representation,) then you can instead apply dampening and hysteresis to the adjustment, where if you see an unaccecptable value (less than -2.0 or greater than +20.0 in this case, for example) then you would adjust the entire difference in one big chunk, and forbid any more large adjustments for the next 2*RTT packets.
At the moment, I have the server sending the client:
-
Server's current tick (ie tick 100)
-
Latest tick for commands it has received from that client (ie tick 105)
Using this information, the client assumes the server has 5 commands buffered (for each tick 100-105) for that client. This is delta.
I have a setting that says "if the delta is > than X, tick slightly slower" And "if the delta is < Y, tick slightly faster"
This appears to somewhat work, it has a tendency to bounce around a lot when I set it to 2. I would expect the delta to stay close to 2 commands buffered, but it oscillates between 0 and upwards of 3-4 kind of rapidly. It never settles on 2 for a long time at any latency I throw at it from 0 to 200.
The Unity FPS sample does something pretty much identical, but it stays close to 2-3 when set to 2 as well. I'm wondering if maybe my tick timestep are wrong somehow.
You suggested sending the adjustment value "Z" to the server, I presume you mean the # of ticks the client is guessing it should be ahead. Can you expand on that and how that would help? I don't mind the extra 4 bytes if it keeps my command buffer rock solid.
Thank you again by the way.