just a little followup.. thanks again Robert for encouraging me to use nanoclock. I eventually got around to the conversion (I had been invoking System.currentMillis in a thousand individual locations, of course :-)
Anyway clock sync is better than ever, whether I am on Wifi/3gs or lagging my pooter out with four emulators. - Dan On Mar 11, 12:23 am, Robert Green <[email protected]> wrote: > FYI - Good that you're doing it that way. I have to recommend > switching to nanoTime, though. I've witnessed multi-second time > updates (from the system, not from me) while playing my games and it's > not pretty. I've switched everything to nanoTime / 1000000 since then > (which gives milliseconds) and all seems to be well. > > On Mar 10, 10:01 pm, Samsyn <[email protected]> wrote: > > > > > Thanks, Robert! > > > yes, don't worry, I wasn't doing that. :-) > > > Basically the server has the master time, each client has a dynamic > > ping value to the server, which is also shared with the other clients > > for suitable adjustments. at key moments a client notes the local > > currentMillis() value matching an important server time value, > > computes a delta which it can then use to move between currentMillis > > and server time as needed (until the next Important Event freshens the > > sync). > > > Important Events occur frequently enough to keep the clients > > reasonably well synched, so long as I can depend on currentMillis to > > actually move forward in real time (i.e. 500 ms from now, I need it to > > be roughly 500 counts higher). Though a little jitter doesn't bother > > me, seeing it jump 10 SECONDS in a 2 second period was causing me > > alarm. > > > I will, of course, fail if the client changes their clock setting in > > mid-game. And I suppose the phone itself could initiate such a change > > based on some signal from the provider, but I tell myself it will only > > fail 'a little' in that case (assuming the hardware is not horribly > > defective), so I choose not to worry about that. (knowing that I > > COULD use the nanotime to remove that sensitivity, but something makes > > me prefer currentMillis right now... some unproven suspicion that it > > is a cheaper computation.) > > > And I assume what was happening before was that running multiple > > emulators under eclipse was starving them of cpu to such a degree that > > an internal emulation of the phone clock was missing some important > > polled event. I can't decide if I think that's cool or not. Would it > > be cheating for theemulatorto just read the host hardware clock?... > > I guess so. So instead it probably reads a simulation of the > > nanoclock, which turns out to be unreliable in a low cpu cycle > > environment. > > > And manually running emulators in separate CMD windows seems to help > > it take advantage of the host's multiple cores. Which I guess would > > be asking Eclipse a lot to do, given that it is also giving me all > > those nice debug hooks :-) I shouldn't be so demanding. I love you, > > Eclipse, I really do, except when you crash or that time you deleted > > every source file in my project with nary a warning. > > > Thanks again! > > > - Dan > > > On Mar 10, 5:53 pm, Robert Green <[email protected]> wrote: > > > > Samsyn, > > > > For multiplayer synchronization, you absolutely can not count on the > > > current time of either device. Here's one way to handle it: > > > > Both host and client use System.nanoTime() / 1000000; That gives you > > > a fairly accurate counter to use. > > > Host sends snapshots with their current time. Client adapts the > > > host's time for interpolation by attempting to detect ping and use it > > > as a skew. > > > > On Mar 10, 7:36 pm, Samsyn <[email protected]> wrote: > > > =- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe from this group, send email to android-developers+unsubscribegooglegroups.com or reply to this email with the words "REMOVE ME" as the subject.
