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 the emulator to 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: > = -- 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
