Yes it makes sense. I've already tried that, was what I meant by "delayed client side interpolation", but the delay is a major problem with that technique, since the characters only starts moving when the first position update arrive from the server. Besides it still looked jumpy (what I did in more detail was constantly interpolating against the received absolute position over 33 ms (since my server tickrate/heartbeat is 30hz)).
Funny thing is, I tried sending the heading instead of absolute coordinates, I still get the jitter, even though the server only updates the clients heading vector, eg the movement is calculated using the usual scale by frame delta time on the client. I then tried running Kevin Glass's space invaders game (
http://www.cokeandcode.com/spaceinvaders/si101.jnlp) and noticed that the movement of the player character is also jerky as hell (and that example is using frame delta based movement too).
Using delta frames works very well in OpenGL so i'm a bit puzzled why its so bad for java2d graphics. I think its a combination of regularly occurring FPS bursts as well as the cast of float values to int (actually displaying the graphics with java2d) which causes this.
I'd did a little more browsing on Kevin's excellent site and found this tilemap collision example demo:
http://www.cokeandcode.com/collision/tilemaps/tilemap.jarThis demo exhibits much smoother movement albeit still a little jerky but a vast improvement over the 2d space invaders implementation. Curious as to why I looked at the code and found this snippet:
long delta = (System.nanoTime() - last) / 1000000;
last = System.nanoTime();
// now this needs a bit of explaining. The amount of time
// passed between rendering can vary quite alot. If we were
// to move our player based on the normal delta it would
// at times jump a long distance (if the delta value got really
// high). So we divide the amount of time passed into segments
// of 5 milliseconds and update based on that
for (int i=0;i<delta / 5;i++) {
logic(5);
}
// after we've run through the segments if there is anything
// left over we update for that
if ((delta % 5) != 0) {
logic(delta % 5);
}
Which imho is a quite brilliant implementation of frame delta smoothing. Far as i understand I would get the same result by keeping the last 5 frametimes in a buffer and averaging them, so its a clever way of averaging the frame delta over time.
Now I'd love to apply this technique to my game, but since i'm running the movement on the server and sending back absolute coordinates I don't use the delta for anything client side.
What I could do is apply this to my server movement, but I thought using a Timer/Timertask at 33 ms intervals (1000/30) would guarantee a somewhat steady 30hz tickrate. Can anyone confirm this? and do you guys think it would be good idea to calculate delta time (and smooth the values) on the server? (even though its supposed to run at a fixed rate).
