In that case, wouldn't just typical multiplayer prediction logic be better? I don't expect that you'd get 60Hz packets neatly over the internet (you do over LAN though), but I could be wrong there.<br><br>How about letting the server send out update packets for the ball; position+velocity. The clients handle time offsets (wrt the server) and ballPos=position+t*velocity.<br>
I do that type of interpolation (prediction really) in my racegame, and it works better than expecting packets to drop in neatly every 1/60th of a second.<br><br>You probably looked into this, otherwise check out Half-Life 2's multiplayer page on prediction/lag. There's a bunch of ways to either predict (HL2 really takes the last 2 packets and interpolates between those; I take the latest packet and start interpolating from there, to combat lag).<br>
The tricky part is getting a good client time offset (to calculate a servertime which is quite correct on all clients; something which can be tested by flashing the screen every second for example, quite a nice visual test).<br>
<br>The only real events for a tennis ball are when it gets hit, which will be the main concern. But if clients predict this as a player hits the ball, you'd see virtually no lag.<br><br>Ruud<br><br><div class="gmail_quote">
On Fri, May 25, 2012 at 4:51 PM, Emmanuel Rivoire <span dir="ltr"><<a href="mailto:manu.n02@laposte.net" target="_blank">manu.n02@laposte.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">At 19:55 25/05/2012, you wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In that case it sounds like the optimization chances are more at your end, trying to aggregrate information. If overhead is larger than the data, you're probably sending too little data. ;-)<br>
</blockquote>
<br></div>
Damn, I sweat my brain off to get the smallest data needed to go over the network, and got blamed for it..! ;-)<br>
<br>
More seriously, I have to send 60 packets / second, coz sending only 30 packets/s would mean to add 16.67ms of latency and that'd be bad for my game : it's a tennis game, it's very latency dependant ; for example, the ball can travel almost 1 meter during 16.67ms on the start of the service.<br>

I did a lot of things to fight back the latency at the game level and network level, but the 1st thing is to have the smallest packet possible sent 60 times / second, thus my concerns about all optimizations. <br><div class="HOEnZb">
<div class="h5">
______________________________<u></u>_________________<br>
ENet-discuss mailing list<br>
<a href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a href="http://lists.cubik.org/mailman/listinfo/enet-discuss" target="_blank">http://lists.cubik.org/<u></u>mailman/listinfo/enet-discuss</a><br>
</div></div></blockquote></div><br>