<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Exactly. The ball doesn't change its direction after being sent
away, so there's no reason to keep updating it if that way if you
predict the next tick's position on the client.<br>
<br>
On 2012-05-25 18:56, Ruud van Gaal wrote:
<blockquote
cite="mid:CADULfbMtQ9dzuJh=qZstPZAVFPH60ubtdqXQiuDTXQZN=vAuvA@mail.gmail.com"
type="cite">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 moz-do-not-send="true"
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">
_______________________________________________<br>
ENet-discuss mailing list<br>
<a moz-do-not-send="true"
href="mailto:ENet-discuss@cubik.org" target="_blank">ENet-discuss@cubik.org</a><br>
<a moz-do-not-send="true"
href="http://lists.cubik.org/mailman/listinfo/enet-discuss"
target="_blank">http://lists.cubik.org/mailman/listinfo/enet-discuss</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
ENet-discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:ENet-discuss@cubik.org">ENet-discuss@cubik.org</a>
<a class="moz-txt-link-freetext" href="http://lists.cubik.org/mailman/listinfo/enet-discuss">http://lists.cubik.org/mailman/listinfo/enet-discuss</a>
</pre>
</blockquote>
<br>
</body>
</html>