Let’s assume the next scenario:
I’ve a server, that sends a snapshot of present recreation state to all of the shoppers at a hard and fast time. Server is authoritative, all of the physic calculations are executed on its aspect.
Each consumer receives a snapshot in a type of information packet that comprises:
server_timestamp
place
rotation
After receiving the information packet, consumer shops it within the buffer for the later interpolation.
The interpolation is predicated on the usual linear interpolation guidelines:
x = x0 + (x1 - x0) * ((t - t0) / (t1 - t0)) and y = y0 + (y1 - y0) * ((t - t0) / (t1 - t0))
the place t is calculated as an estimated_server_time - RTT / 2
All of the above simulation works easy on the shoppers.
The issue seems once I need to add a bodily pressure to the entity simulated within the described technique. Once we ship this request to the server, the entity on the consumer begins to maneuver after full RTT, which isn’t acceptable attributable to lack of duty on the consumer.
To compensate this, I attempt to predict consumer motion by making use of the bodily pressure regionally on the consumer. I am predicting the motion for sure time — after that I attempt to restore the interpolation. I retailer the server time when prediction stops as: prediction_end_server_time = estimated_server_time and wait till consumer receives information packet with server_timestamp greater than prediction_end_server_time. That is manifested by the truth that the entity stops for a a while (which is okay for me in the mean time) and, after this time, ought to begin transferring easily utilizing the interpolation. However the motion is not easy — the entity jumps again for a small quantity, after which begin interpolation from this place.
How can I keep away from this backward shift?
Pattern values, simply after prediction stops and interpolation buffer begin accumulating new values:
t0 | prediction_end_server_time | t1 : 48858 | 48834 | 48909
x0 | current_position.x | x1 : 259.45 | 329.96 | 283.07
Like you may see, the time values appear to be good — t0 i barely greater than prediction_end_server_time, however for place, the current_position is much away from the present interpolation vary.
