Crossbones+ - Reputation: 16318
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.
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums
Members - Reputation: 259
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: 6298
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.