Fwiw, we generally use SystemClock.uptimeMillis() in the platform. This is monotonic and should not jump. It does not increment when the CPU is not running, but typically this is actually fine or even good behavior. (For example, it is used to time messages in handlers; if you post a delayed message to the handler, that delay will be longer if the CPU is stopped. This is actually a good thing, since it means when the CPU wakes up after being stopped for an hour or whatever, you don't suddenly have a bunch if spurious stuff to do.)
On Thu, Mar 11, 2010 at 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 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]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- 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.
