Here ya go DGtalx.

I used simple linear interlerplator.

T_0: So tank A on Client C, is moving direction D0 at speed V0.
T_1: on Server S, recives change direction D1 and speed V1 and sends this too all the pertient clients with timestamp T_1
T_2: Client C, recives the packet from the server with D1,V1,T_1 info.

then Client C :
-applies the change direction command to tank A immediately ( remeber this is a request for a change of direction given in relative terms, not absolutes.)
-spawns a ghost entity G which has the same movement parameters as tank A, but whose position is at T_1, not T_2 which tank A is at. Then it applies the same command to this ghost entity G.
-As time goes on Tank A state (pos,dir) is linearly interperlated to ghost entity G. This occurs usually over 1 sec, or when the threshold is too small to matter, which ever first.

As you can see state of ghost entity G is not static, its the projected state of what the true entity position on the Server S is, becuase it applies the command at the retroaticve time T_1, not the current time the client recived the packet T_2.

So there you go, this is just an example, but you can use other methods to generate the ghost entity and find its projected state. I used this, becuase it was easier for how my entites are set up.

Good Luck!

-ddn

Some definitions for DGtalx:

Interpolation = Smoothing: Given points 1.0 and 2.0, you can approximate 1.1, 1.2, etc.
Extrapolation = Prediction: Given points 1.0 and 2.0, you can estimate 3.0 and 4.0.

Nice post red_mage.

So interpolation means smooth movement from 1.0 to 2.0 along 1.1, 1.2, 1.3 etc... Client A is at 1.0 on client B monitor... When client B receives a packet from the server which informs client B, that client A was at point 2.0 in past, client B can begin interpolating player A on its monitor from 1.0 to 2.0, but 2.0 is client A position in past, so client B can never know where is A in current time moment... When B finishes interpolating A is at 2.0 on his monitor, but A could be at 3.0 already at the moment when B finishes... So there''s always lag. Client B can only draw A at its positions in past, but can never know where is A actually, unless B is using some kind of prediction... And the question is: if B can never know where is A in current time moment, how can interpolation help to fight lag?

No, the interperlator target can indeed by the best projected state given the available data at the current time. In my example, the tank A state on C is interperlated to the ghost entity G state.

But note ghost entity G state is not static, it''s one example of a dynamic interperlator target. Entity G state changes with time as well. So as time goes on, client C gets a closer and closer to the predicted state of tank A, as it is on the server S.

It fights lag in 2 ways.

-avoid unsightly jerks caused by latency and loss
-you don''t have to send as much data, as interperlation can fill in the blanks.

-ddn

Hmmm... as far as i got it, G is current projected state of A on client C. So C interpolates position of A between some point in past and current projected point G... But this means that A is never drawn at its current position on C, it is drawn at some position between a point in past and G. G is position of A on server, but there's also lag between A and the server. It takes some time for the packet to get from A to server, and the position of A on server is also lagged... So when a packet gets from the server to B the A position is double-lagged on B. Is there a way to find (predict with some amount of accuracy) the real position of A on B?

[edited by - dgtalx on December 8, 2003 10:44:56 PM]

I see where its getting confusing. Each step of the interperlation loop brings A closer to G. So the difference between them becomes smaller over time. For my case i set it to be 1 sec interperlation from A -> G, or when A and G state difference is small enough as to make them indentical to the viewer.

Also since your describing G and A state paramerticly, that is through a series of equations, as long as you know the inital params and have a synchronized clock, the error between the projected state G and the true state on the server S is pretty small, within the error of your clock sync algorithim.

There have been many discussions on how to sync timmers on this board, im sure you can find plenty of refrences.

Good Luck!

-ddn

thanks a lot, ddn, i think i finally got it now