How do you avoid jerky movement?
I send out packets about orientation and movement every 100 ms but it still ends up looking jerky. Is this because I'm running it on an Amazon EC2 micro instance?
Jerky movement
Are you interpolating between positions or just setting them on every update?
Are you afraid to provide more than 1 or 2 lines of information when asking questions?
L. Spiro
Are you afraid to provide more than 1 or 2 lines of information when asking questions?
L. Spiro
Jerky movement may be a rendering issue. For example, when making a tile-based game, movement will appear jerky if you don't animate the walking between tiles correctly.
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.
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.
You need to timestamp each update with the global clock for which the update is meant.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
