first of all: thx a lot for your comments!
Note that in a true p2p game you wouldn't have the concept client/server like you mention.
well, the server creates a game session and the client connects to the server's ip/port. that's all. anyway, it seems like i'm using the wrong terminology ...
If you'd use raw network updates to render your opponents cars it probably would render very choppy (at least if the network conditions: latency or packet loss are high enough).
that's exactly the problem ...
About extrapolation: It was originally designed (for the millitary simulation environement DIS) to cut down on the bandwidth required to send updates. What happens is that for each extrapolated object all peers run the same extrapolation algorithm. When the peer that is the owner of the object notices that fx the extrapolated pos for the object exceeds some threshold, it sends an update again. That way you wouldn't need to keep sending updates blindly.
yes, but the directions of the cars might change all the time. i don't think this would be a good approach.
For a car game extrapolation would be very usefull indeed, when no update is available we could make a fairly adequate guess what the next pos will be (at least for small timeframes, <150ms or so).
my framerate is 30fps and i'm sending one packet every frame (33 ms).
No if we get a network update and we seem to have extrapolated the cars pos wrong, we should draw the car at that updated pos instead, which causes snapping. To make this some more pleasing to the eye you could apply interpolation between the extrapolated pos and the real network updated pos. Most times a simple linear interpolator (lerp) will do the trick although i've heard cubic splines might give even better results for racing games
how do cubic splines work? (tell me only if it's easy to explain, if not i'll google a bit ...)
Now about your game still stuttering with your extrapolation thread; could it be that your extrapolation thread guesses the next pos, but when a network update comes in, the car will snap back to that network updated pos?
yes, that could be true. especially when a car is steering left or right. the extrapolator is not smart enough to take care of the steering as well. it only does a linear extrapol.
You would need to send somekind of timestamp wth your network updates... if the currenttime > network update, save the difference, rollback to the network update timestamp and use your extrapolation thread to calculate the new pos according to the time difference. And maybe use a lerp to make the transition from the misguessed pos to the newly guessed pos...
i already use a timestamp mechanism. i know the time when the last packet was coming in and the extrapolator uses the difference (now - last update) for it's calculations. i'll have to think about your approach.
but anyway, even if i can do perfect extrapolation there will still be stuttering if the network latency is too big. i wonder how professional games deal with that. i've seen games where many people play against each other over the (slow) internet and the movements are still very smooth. with my game i even have problems in a (relatively fast) intranet.
Show Posts
it would be nice if one of you mac users could do a quick test for me. 
what makes you say that? did you notice a bug?
