Quake prediction.....ouch !

[nicolasbol]

Hello guys,

I'm trying to read Quake Source code (and also trying to document it).

I've identified 3 keys elements in the engine: Transmission, Prediction and Rendition

Thanks to Michael Abrash, the renditon layer

Code: Select all

SCR_UpdateScreen

was a piece of cake.
The netChannel abstraction was quite similar to Quake 2 and I'm ok with it.

But I'm having a hard time with prediction and linking:

Code: Select all

CL_SetUpPlayerPrediction(false);
CL_PredictMove ();
CL_SetUpPlayerPrediction(true);
CL_EmitEntities ();


I've summarized a game loop as follow:



cl.sim* is used to setup the POV, this is done in

Code: Select all

CL_PredictMove

.


What's the point to generate a list of players without prediction and then redo everything with prediction ()

Code: Select all

CL_SetUpPlayerPrediction

An other thing: Command are saved in cl.frames[outgoing_sequence].cmd and received game_state are saved in cl.frames[incoming_sequence], it doesn't make sense to me, I would have expected game_state to go with cl.frames[incoming_sequenceACK]

Any hint or paper about this ?

http://developer.valvesoftware.com/wiki/Lag_Compensation

this one helped a lot for example.

[Spike]

CL_SetUpPlayerPrediction sets the solidity and locations of other players and stuff.
Remember that QuakeWorld predicts other players, while eg: q2 does not.
Presumably it does it so the local player clips with known-good locations, while rendering is more predictive.

The client fully controls the sequence numbers.
Any incoming_sequence the client receives is guaranteed to be an acknowledgement of a packet the client originally sent.
There is no need for an incoming_sequenceACK.

[nicolasbol]

Thanks for your help Spike.

No Client Side prediction in quake2 ? Does it use Server side Lag compensation then ?

I get what CL_SetUpPlayerPrediction does, I just don't see the usefulness of running it with prediction set to false.

Regarding the sequence number, the client uses the incoming_sequenceACK: most prediction access are done via:

frame = &cl.frames[cl.parsecount&UPDATE_MASK];

where parsecount = cls.netchan.incoming_acknowledged.

[nicolasbol]

Ok, after further work, I turn out that understanding prediction is more about undestanding the "frames" structure:


What I've understood so far is that upon sendingCommands, they are saved in frames[outgoing_sequence] along with the senttime.
When the server acknowledge the message, frames[incoming_sequence_ACK] is used to write received_time and so latency = senttime-received_time.




During server message parsing, the position of other players is read from a svc_playerinfo packet, and stored in frames[incoming_sequence_ACK], particles are received via svc_packetentities and stored in frames[incoming_sequence].

So far, so good.

The problem is that during the prediction phase,I can read:

Code: Select all

   // this is the last frame received from the server
   from = &cl.frames[cls.netchan.incoming_sequence & UPDATE_MASK];


According to what I understood, only svc_packetentities are there, no player state. In order to check the last player info, I would have expected:

Code: Select all

from = &cl.frames[cls.netchan.incoming_sequence_ACK & UPDATE_MASK];


Any idea guys ?