So I updated the algorithm and it seems to be working pretty well. <br><br>whenever either device detects an incoming event where the packet time is either far in the future or far in the past, a time-sync sequence is started. "far" is determined by gametime - (packet_time + one-way-latency). <br>
<br>these time sync sequences are happening more often than i'd like, but it seems to be the only way to consistently be synced. <br><br>I think what I might do down the road is instead of using a "time sync" packet, i'll build in a flag into the packet ID code, so if a packet is already queued for delivery and it's stamped with the current game time, i can just flag that as a time-sync response packet as well as :)<br>
<br>Cheers!<br clear="all">--<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 Thu, Mar 11, 2010 at 8:39 AM, bill k <span dir="ltr"><<a href="mailto:billiumk@gmail.com">billiumk@gmail.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;">
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!<div class="im"><br>--<br>Bill Kouretsos<br>tel \ 647.477.3817<br><a href="http://littleguygames.com" target="_blank">littleguygames.com</a><br>
<br><br></div><div><div></div><div class="h5"><div class="gmail_quote">On Wed, Mar 10, 2010 at 10:47 PM, Alexander Shyrokov <span dir="ltr"><<a href="mailto:sj@sjcomp.com" target="_blank">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><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><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>
</div></div></blockquote></div><br>