Thanks Alexander!<br><br>I ended up figuring out pretty much the same approach.. instead of dividing by 2 to get the average, i used a variable divisor. depending on the nature of the discrepancy, i either add or subtract .1 for large differences, .05 for small discrepancies. it'll converge in about 5 sec with a tolerance of < 100 ms<br clear="all">
<br>right now i'm working on the second part of this where even though the clocks sync, after time one seems to run faster than the other device. it seems the actual system time is being reported fast/slower depending on what device i'm using :( <br>
<br>It's an iphone game and my testing devices are iPhone 3gs (pretty powerful) and an ipod touch 2nd gen (kinda powerful?)<br><br>does framerate have to do with it maybe? should i limit the faster device to a lower framerate? I'll post a proper solution if/when i've got it. <br>
<br>cheers!<br>--<br>Bill Kouretsos<br>tel \ 647.477.3817<br><a href="http://littleguygames.com">littleguygames.com</a><br>
<br><br><div class="gmail_quote">On Wed, Mar 10, 2010 at 10:47 PM, Alexander Shyrokov <span dir="ltr"><<a href="mailto:sj@sjcomp.com">sj@sjcomp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Bill,<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
client sends time-request packet to server<br>
server stamps and responds<br>
client takes the last send time, current time, figures out the *average*<br>
latency and adjusts the time to predict where the server is right now<br>
the client seems to always be a little bit off though and I think it's<br>
because the sending and receiving speed / packet delays are different.<br>
This would mean the client is /always/ over or under compensating.<br>
</blockquote></div>
Use your procedure to get initial time difference between server time and local time as well as half latency. The next time you get the response, try to predict what the server time should be using information from your previous response. Obviously it will be off, but the direction will tell you which way you should shift your prediction.<br>
<br>
lt - local time; st - server time; lt1 - request time; lt2 - response received time.<br>
1) hl = (lt2 - lt1)/2<br>
dif = st - (lt1 + hl)<br>
<br>
2) predicted_st = lt1 + dif + hl<br>
hl = hl + (st - predicted_st)<br>
<br>
... repeat<br>
<br>
You have two variables dif and hl that you estimate from your times in my example I assume that dif was done properly the first time around, while in fact you need to keep track of how much your prediction is off and see if you need to redo the process.<br>
<br>
I did not try this, just my 2c. Let us know how you decided to solve the problem.<br>
<br>
Blue skies,<br><font color="#888888">
Alexander</font><div><div></div><div class="h5"><br>
_______________________________________________<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/mailman/listinfo/enet-discuss</a><br>
</div></div></blockquote></div><br>