Client Side Entity Movement Extrapolation

Replace or at least extend the current client side interpolation of entity movements by an extrapolation based on forces, momentums, masses, velocity and position.


The Q2 client interpolates entity movement between current and previous svc_frame per client refresh, but only for FRAMETIME of 0.1 seconds. The client should get information to extrapolate instead of interpolate. There are two possibilities:

I favour the latter. My goal is to introduce a simple Dead Reckoning to Q3. It is probably not useful to make rather involved changes only to piggyback another mechanism on the existing (and working) one.

There are several benefits with respect to making Q3 a more fast paced game.


This requires a more generic setup of entity_state_t to provide the necessary information for extrapolation, and a different way of thinking about movement generation - that is, on the basis of forces applied instead of offsets and velocities added. Within a server update, the current processing can be kept. The changes are related to the ones also required to a more generic client side prediction

Particular problems:


The reworking of the client side handling, and DLL handling, of entities is a bit involved. The gains might be negligible and not warrant the effort, except that a technique like this should at least be tried once. Future games might benefit from improved network bandwidth, but game complexity, additional features (voice over network) and increasing number of players will keep the constraint present. Further, this is a bandwidth issue only with respect to sampling (half the FRAMETIME means double bandwidth). Roundtrip latency will still be present, and is much harder to decrease than it is to increase bandwidth. The idea is that the player should be exposed to the latest info from the server ASAP.


There is no need to provide the elapsed time from the last update, or keep a particular timing with svc_frame anymore, as the correction will simply override the current state.

Related Proposals:

Applies the same approach as Generic Client Side Prediction. Actually, both could be implemented in one unified module.

The actual difference for the player might be negligible here, one way or the other - the new artifacts are not so bad, the improvements are not really visible. It might just be a matter of philosophy - do you try to provide the player a feedback as fast as possible, or one looking as smooth as possible. Neither will be accurate, but one looks better - ultimately, the question is: which one plays best?

Could be partly rendered obsolete when the client side handling of entity movement is exposed in a Client Side DLL.

Submitted 980328, revised 980307, revised 980320 comments to