4 replies to this topic

[Angus Hollands]

Hey all, a typical question here today.
I have been using a form of prediction correction for a while, but I hadn't noticed that it failed with certain latency.
Whilst it may have been something i did in a later commit, I'm still not happy with it

Some notes:

• I am unable to perform rollbacks / rewind physics
• I am therefore forward predicting the receipt of the input packet on the client

At the moment, I am checking what the server state is in comparison to the prediction for that receival tick
Then I get the error vector, add it to the current position, and add it to all later received states. However, if an object is falling when it shouldn't be this creates some problems.
How would someone do this?

[hplus0603]

Typically, rather than "add the error vector," what you should do is predict where the server object would be X time from now, and make the local object velocity be such that it will reach that predicted position at the time when the next packet should arrive (or some other fixed time into the future.)

For example, if you are currently display the object at (8, 12) and you get a packet saying the object is at (7,5) moving with velocity (-20, 10) and you use a 0.1 second extrapolation window, you would calculate the position in the future as (7,5)+(-20,10)*0.1, or (5,6). Because you are displaying the object at (8,12) you will set the velocity of the local object to ((5-8),(6-12))/0.1, or (-30,-60) in this case.

Look at the <a href='http://www.mindcontrol.org/~hplus/epic/'>Entity Position Interpolation Code</a> for a working example.

[Angus Hollands]

Indeed, I am using EPIC for extrapolating remote entities already! However, how would you recommend correcting the client local agent?

[Angus Hollands]

My reasoning against using inputs was because now that I use displacement and not velocity (independent from the Physics simulation) I could actually work out where the client would be from the inputs, except it wouldn't account for gravity, nor collision, so long time steps would mess it up. It seems an impossible solution, unless I were to write my own engine.

[hplus0603]

If you speculate the client ahead of the server, and cannot re-run client simulation on correction because your physics engine cannot be made to do that, then you're in a tough place. You could try snapshotting all entity positions, place the player where it should be, step the physics forward, and then put all entities back where they are supposed to be. This could work if you can step the physics engine faster than real time when needed.

Another option is to display the player extrapolated just like every other entity. This, unfortunately, will lead to some "skating" in steering, and won't get rid of the initial latency when starting a movement.