Timeline for Interpolating server updates with client prediction: how to actually find time variable
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 3, 2023 at 7:19 | comment | added | Mangata | According to the current scheme (extrapolation is only used to deal with packet loss), the player 1 seen by player 2 is always slower than the player 1 sees himself. Valve's solution is that the server performs delay compensation and performs key operations (such as shot) retest with older data. | |
| Jan 3, 2023 at 7:18 | comment | added | Mangata | Synchronized server time is the more accurate current time of the server. Ideally, it is approximately equal to the current time of the client. In the interpolation algorithm, it is current client time. The server time put into the buffer does not need to be corrected, they are more like a frame number that marks the packet sequence, all you need to do is to select the corresponding server snapshot between synchronized server time - 100ms and synchronized server time interpolate. | |
| Jan 3, 2023 at 6:36 | comment | added | Pumpudu | @Mangata, As I understand it, I need to use synchronized server time? and rewind it 100 ms back during interpolation. And when receiving packets, take the synchronized server time for the time to push it to the buffer, right? | |
| Jan 3, 2023 at 6:20 | comment | added | Pumpudu | @Mangata, I read in a series of Valve articles that they use interpolation, extrapolation is used if there is no data to interpolate (and the prediction is no more than 0.25 seconds). I want the same approach. The main problem with extrapolation is that it is difficult to use in a world where the controls are quite unpredictable (like a shooter). | |
| Jan 3, 2023 at 3:14 | comment | added | Mangata | As for the delay of interpolation, I think it is due to the way of interpolation. The client-side interpolation with prediction needs to predict the content of the data before the server sends the data. stateInterpolateTo should be a state that is inferred based on the existing data. If it is taken from the buffer, then you are not predicting(extrapolation). This(interpolation) will inevitably cause delay, and the degree of delay depends on the frequency of server sending packets and the network delay. | |
| Jan 3, 2023 at 2:53 | comment | added | Mangata | Hello, it is convenient to regard TTRS and TTRC as the same in this time synchronization algorithm. In most cases, the delay comes from network transmission, and they are roughly equal. Even if the speed of protocol parsing is different due to the different technology stacks used by the client and server, their ratio is roughly stable. All clients rely on the authoritative server's time, and it doesn't matter if the server they calculate has roughly the same lag. This time synchronization method has been extensively verified, and I think there is no problem. :) | |
| Jan 1, 2023 at 12:27 | comment | added | DMGregory♦ | Please do not use answers to reply to other answers. If you need to add more information to your question, edit your question. If you need to include more content in a reply than will fit in a comment, we can start a chat room, or you can write the reply elsewhere and link to it. | |
| S Jan 1, 2023 at 12:04 | review | First answers | |||
| Jan 2, 2023 at 10:12 | |||||
| S Jan 1, 2023 at 12:04 | history | answered | Pumpudu | CC BY-SA 4.0 |