Crossbones+ - Reputation: 8802
Posted 31 August 2012 - 08:04 PM
Are you afraid to provide more than 1 or 2 lines of information when asking questions?
Edited by L. Spiro, 31 August 2012 - 08:14 PM.
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums
Members - Reputation: 256
Posted 31 August 2012 - 11:04 PM
It may be a network issue if you have high player counts (running it on a cloud server shouldn't matter much at all), in which case you need to change how you send your packets (use asynchronous I/O).
It may be a physics issue as well, for example if your physics timestep is significantly larger than the time between screen updates.
Moderators - Reputation: 4357
Posted 01 September 2012 - 04:10 PM
Then, you need to keep an estimate on the client for when the next update according to global clock will arrive.
Then, you need to use this clock to drive the interpolation of display.
You need to display entities sufficiently far "back" in time that you will get the next update right before it's needed for smooth continuation of the interpolation.
Typically, you will keep a running count of how far off your guess is, and slowly update it as you receive new time stamped packets, to adapt to changes in transmission characteristics.
You may need to keep a queue of received packets, waiting to go into interpolation, if you need a lot of anti-jitter buffering.
And, yes, depending on which kind of instance you're running on EC2, the virtualization may add significant additional jitter. You may need to add up to 1.5 second of anti-jitter buffering to run smoothly if you're using one of the smaller image types.