Jump to content
  • Advertisement
Sign in to follow this  
EternityZA

FPS position update packets come through in bulk.

This topic is 2617 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi. Im creating a multiplayer FPS. Im hosting the server on a virtual box with linux on it .player positions should get updated 20 times a second but it doesnt. the 20 updates gets send out in proper intervals but they arive more or less 10 at a time causing player models to apear very jumpy. Ive thought of timestamping each position update and then do interpolation between them but im not sure if thats the best approach. Any suggestions? Im not sure if im suposed to solve the problem of packets ariving in bulk or if im suposed to work around it.

Thnx in advance.

Share this post


Link to post
Share on other sites
Advertisement
Yes, you should stamp your packets with time/tick information. You can use this to reject out-of-order updates, and/or you can store the server-supplied (and client-predicted) into a ring buffer to produce smooth visual movements.

Are you using UDP?
Are you planning on using an interpolation or extrapolation scheme?
Do you have client-side movement prediction?

Share this post


Link to post
Share on other sites
Some network APIs don't send the data right away, if you're only sending very small packages. Instead it buffers them until the package has a decent size. This is done to minimize the overhead of each package. To avoid this, you should be able to either tell the network API not to do that, or you can flush the connection. I can't say exactly how you should do this without knowing what language you are using.

BUT as you mentioned yourself: you're supposed to work around it :) even if you send the packages one at a time, latency can still make your game appear jumpy in no time :( Instead you should simulate/predict what the user is doing. Instead of sending each update, you should only send each player action. When the player starts moving forward, send a message to the server, that the player is mowing forward, and let each client simulate the entire movement, until the player stops moving forward. This should keep all clients in sync, and allow for smooth movement.
You ought to correct the player position once in a while as well, in order to avoid a minor difference on the server and a client, means the difference between bouncing into a wall, or not. This can be done with every player action update.

Share this post


Link to post
Share on other sites

they arive more or less 10 at a time causing player models to apear very jumpy



First, if you use TCP, your problem is likely not setting TCP_NODELAY. Check the forum FAQ for more info on that.


Second, virtual machines tend to be time sliced on the host CPU, and often introduce siginficantly more jitter than "native" hardware; leading to most VMs not being useful for real-time uses. However, as long as you don't over-tax the hardware, you can often be OK for development purposes. For example, I have a Core 2 with 4 hyper-threaded cores. I give 4 "virtual" cores to a linux VM, and make sure to not use more than 2 hyper-threaded cores on the Windows host side, and they will play nice.

Share this post


Link to post
Share on other sites
Thnx for the replies. in response to some of youre questions. Ive written the server in java and i use UDP. I have a tcp ip connection that runs in paralal but its idle pretty much always. It mostly gets used to send chat messages etc. As for time slicing the CPU. my cloud server plan states that i get a CPU for myself so that should not be a problem. interpolation or extrapolation scheme? can you please explain the difference :D. And then about flushing, I dont have the java API docs open in front of me but i dont recall a flush method anywhere usefull. How would i flush out UDP packets in java?

Share this post


Link to post
Share on other sites

[color="#1C2837"]my cloud server plan states that i get a CPU for myself so that should not be a problem.




[color="#1c2837"]This means that, for a machine with X hardware threads, they will not have more than X customers. That does not mean that the VM system will always schedule your CPU resources. We've seen that just running under a hypervisor will increase scheduling jitter from 3 ms (raw linux box) to 30-80 ms (virtualized guest on otherwise unloaded linux box).
[color="#1c2837"]Under really high load, we've seen hosts like Amazon ECC reach scheduling jitter of 1500 ms (that's 1.5 seconds).

[color="#1c2837"]Try this program in your VM:

http://www.enchantedage.com/scheduling-latency

Also, other things may cause your program to stutter. The Java GC, for example -- if you generate an inordinate amount of garbage.

You might want to measure the outgoing packets at the point of sending by using tcpdump.

Share this post


Link to post
Share on other sites
Thnx. Im going to test with that app when i get home from work tonight and il let know. <BR><BR>EDIT: Sorry but im still new to the world of linux and ive never realy touched c code. What should I use to build the app in your link? The only thing ive used so far for getting new apps is yum install wich sounds very tasty and makes me go "YUM!" every time i type it.

Share this post


Link to post
Share on other sites

Thnx. Im going to test with that app when i get home from work tonight and il let know. <BR><BR>EDIT: Sorry but im still new to the world of linux and ive never realy touched c code. What should I use to build the app in your link? The only thing ive used so far for getting new apps is yum install wich sounds very tasty and makes me go "YUM!" every time i type it.


The app has instructions in the comment at the top:

[font=Verdana, sans-serif][color=#FF0000]build with g++ -o calclat calclat.cpp -lrt[color="#ff0000"]
[/font]If you don't have g++, you may need to "yum install g++" or something similar.

Share this post


Link to post
Share on other sites
OK

I have tested with that app. Latency varies between 250 and 400 ms!
I dropped my cloud server and I ordered a dedicated server from iweb. Just waiting for the instalation to be completed :D thank you for your time!

Share this post


Link to post
Share on other sites
On 9/20/2011 at 12:30 AM, EternityZA said:

interpolation or extrapolation scheme? can you please explain the difference

Interpolation: Filling In the In-Betweens

Let's say that you have some packet drops, or out of order delivery, or just receive a bunch at the same time. In any case, you'll generally want to go ahead and use the latest known value and ignore any that never arrive, or are already out-dated by another update by the time they do. Now lets say that at 20 updates per second, you've lost several updates. As a result, one of your entities has moved a bit in the mean time. Now this is probably not enough to make much of a difference to game-play mechanics, but it's enough to be visually jarring if you just snap it to the new position (it'll look "jittery", especially if this keeps happening).

You might choose to interpolate the displayed position from the last displayed position to the last known correct position, by calculating progressive in-between positions for each frame rendered. This won't get the entity to the last known correct position as fast as possible, but it will keep it close, and always approaching it in a smooth manner.

Extrapolation: Predicting the Next Values

Let's say you're uncomfortable with the idea that not only might your displayed position lag a little behind the known correct position, but even the latest known position always lags behind the actual current position (as known by the server).

You might choose to analyze the previous updates and use your knowledge to extrapolate the state that the server probably knows now, by predicting how the state has most likely been changing over time, given recent conditions. If you're generally successful, this will cut down on apparent network lag significantly, but will become even more jittery whenever your extrapolated values have diverged from the actual values sent.

Hybrid Approach

To tackle both issues, you could extrapolate future state, and interpolate current displayed state towards that. If you tune both sides of the system up really well, you can theoretically keep your entity position right-on most of the time, with the occasional awkward (although smooth) correction, as actual conditions change unpredictably.

Edited by vreality

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!