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 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
