Index | FAQ | Search | Memberlist | Usergroups | Profile | Log in to check your private messages | Log in | Register

CSQC player movement prediction

| Inside3d Forums Forum Index -> QuakeC Programming

View previous topic :: View next topic
Author | Message
--- | ---
Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Thu Jan 15, 2009 11:29 am Post subject: CSQC player movement prediction |

This is actually a request, mainly to Spike, as I heard you had some code which did this, and I don't know how to get hold of you. I'd need to see how it's done. Code, or description works, preferrably both! This would obviously benefit others than me alone.
_________________
Look out for Twigboy

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Thu Jan 15, 2009 2:11 pm Post subject: |

prediction works thusly: client frame start: if player ent updated: read what the server's entity state is save origin, velocity, input frame somewhere
before drawing:
reset pmove variables back to the last known state
for each input frame (serverframe <= frame < clientframe):
read input frame (angles/movement/jump)
update origin+velocity running your prediction code
add view offset, step smoothing, and optionally error correction
update view origin to predicted move and angles to final angles
note: as an optimisation, you could only reset when the ent is updated.
server:
the server changes for prediction are not finalised - there's no direct support in fte.
if you wish to add your own prediction, you'd have to undo any changes done between playerprethink and playerpostthink, and presumably run it at the start of playerpostthink - but this isn't 100% in the case where input frames were initially dropped (using two+ input packets in one client packet). There'd be some qc callback function and some special globals identical to csqc names for consistancy and code sharing.
the engine provides a builtin which runs the engine's standard movement for you, based on the contents of globals.
http://fteqw.svn.sourceforge.net/viewvc/fteqw/trunk/quakec/csqctest/src/cs/player.qc?view=markup
UpdateLocalMovement updates vieworg and input_angles
Predicting other players is harder and my test mod doesn't attempt it, although it could be done quakeworld-style by just extending the most recent input packet from that client a little.
_________________
What's a signature?

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Thu Jan 15, 2009 7:44 pm Post subject: |

Been reading it a bit, trying to wrap my head around the concept, and it's slowly coming to me. Yeah, it'd be pretty nice with a QC override for the physics code, and not just SV_PlayerMovement which is in DP, as it only handles input and isn't really physics related. As it is now you need to hack it in various ways.
But how is error correction optional? I can imagine errors occurring quite often, and what happens if you don't correct those? Won't that mean your client is out of sync for the rest of the game?
Also, I'm confused about where a bunch of the variables are set, are they set by the engine?
EDIT:
Hm, it seems they're all set by that code. Problem is, to me it looks just like it simply reads server fields and assigns them, what sort of prediction is that? I see the physics builtin alright, but if the fields are read from the server as soon as there's an update... Or wait, are those only used as the previously known positions, and then the builtin assigns the new values in this case? In that case, what happens if I don't do error correction?
_________________
Look out for Twigboy
Last edited by Urre on Thu Jan 15, 2009 8:32 pm; edited 2 times in total

Back to top |

r00k Joined: 13 Nov 2004 Posts: 483 |

Posted: Thu Jan 15, 2009 7:57 pm Post subject: |

Hmm, interesting, would it be feasible to have prediction code within the server's QuakeC for netquake servers? This way players even using Zquake for example can /nqconnect to a netquake server and still feel like they are on a qw server. Which could merge a whole bunch of players into one lump group

Back to top |

Urre Joined: 05 Nov 2004 Posts: 1073 Location: Sweden |

Posted: Thu Jan 15, 2009 8:05 pm Post subject: |

r00k: short answer, no. We're talking about CSQC here. And a lot of QW physics are quite different to NQ, so I doubt QW players would deliberately play on NQ servers, even if they get prediction. _________________ Look out for Twigboy

Back to top |

Spike Joined: 05 Nov 2004 Posts: 944 Location: UK |

Posted: Thu Jan 15, 2009 8:55 pm Post subject: |

the globals defined in that file are not considered special by the engine and will never be set/read by it. getinputstate sets input_* runstandardplayerphysics reads input_* pmove_* movevar_* and sets pmove_* *commandframe globals are automatically updated each time a new input frame is generated/acknowledged.
if you have any concerns about a specific variable, you'll have to name it.
error correction is a misnomer. the actual correction happens due to resetting the state to the last-known-good state. assuming the client+server match, the number of errors are increadibly low, and when you do get them, it'll snap back to what it should be. if you get continuous errors (or rather, something blocking the way) then its still smooth enough that few people will notice. The only time when its actually that noticable is when you're standing on a moving platform. Moving platforms can be predicted for the most part too.
if you predict forwards fully on receipt of a new known-good state, reset and predict after, then compare before and after, you know how much you were off by. you then offset the new by the wrong and reduce the wrongness over time, covering the error smoothly.
The greater issue is step prediction, and my csqctest code fails at that. It just can't take two steps at once.
step smoothing is much more important than error smoothing if you want it smooth.
r00k: authentic netquake physics cannot be predicted reliably, which is the whole issue with SV_PlayerMovement. If you're willing to raise the tic rate a little, then you can implement close enough NQ physics in a csqc-supporting qw engine. qw physics were written with high tic rates in mind (mostly anyway).
then you can have nq/qw clients using identical physics, but you'd have to implement the physics purely in qc, as the engine defaults to its own standard physics behaviour for the given protocol.
_________________
What's a signature?

Back to top |

Display posts from previous:

| Inside3d Forums Forum Index -> QuakeC Programming | All times are GMT
Page 1 of 1

Jump to:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2004 phpBB Group