Dianne, I don't know why but I found that my games were jittery using SystemClock.uptimeMillis(). It's as if there was a little inconsistency and when doing time-interpolated movements, it shows. I've never run a test comparing the output of nanoclock vs uptime so I have no empirical evidence, but that's what I eyeballed. I switched to nanoclock and everything goes back to looking smooth. Strange.
On Mar 29, 9:07 pm, Dianne Hackborn <[email protected]> wrote: > 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%2Bunsubs > > [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.
