Just looked into it. It looks to be the thing to use. TjerkW, thanks for pointing that out! I'm switching to it from here on out.
On Jan 14, 3:23 pm, Robert Green <[email protected]> wrote: > Never thought of that, but I don't know if it would be an issue unless > some kind of time service were to run and update the clock while > playing. You could easily work around that with a sanity check but > you're probably right, uptimeMillis is stable. Is it reliable? > > I don't think the user will be playing the game AND changing the > clock. The game would be paused if that happened and any time you > unpause, you have to reset your lastTickMs to the current time or the > game will try to jump ahead the entire pause duration which surely > won't work. So that makes user time-changes fine, but I have seen > weirdness before where my games seem to jump around a bit in time. I > wonder if that's a time service fixing skew... > > So is andorid.os.SystemClock.uptimeMillis a fast, reliable call? I > know System.currentTimeMillis is very quick and accurate. I just want > to make sure that if I switch, the new one is as well. > > On Jan 14, 12:59 pm, TjerkW <[email protected]> wrote: > > > > > System.currentTimeMillis is not the correct way to go for games, it > > changes if the users changes the time on the phone. > > Use SystemClock.uptimeMillis > > >http://developer.android.com/reference/android/os/SystemClock.html#up...() > > > On Jan 14, 7:14 pm, Robert Green <[email protected]> wrote: > > > > private long tickMs; > > > private long lastTickMs; > > > private long tickDeltaMs; > > > > public void run() { > > > while (running) { > > > lastTickMs = tickMs; > > > tickMs = System.currentTimeMillis(); > > > tickDeltaMs = tickMs - lastTickMs; > > > updateGame(tickDeltaMs); > > > } > > > > } > > > > That's all you need. I've found that the actual tick time doesn't > > > matter but the difference between the last tick and this tick is all > > > you need to have correct physics and most any update I've had to write > > > so far. > > > > Game physics can work like this > > > > updateGame(12) // moves physics 12ms forward > > > updateGame(15) // moves physics 15ms forward > > > updateGame(22) // moves physics 22ms forward > > > > That's exactly what you want the tick delta for. I use that for all > > > movement, sound, collisions, animations and timers. > > > > There's one exception - if your game cares about time of day. Then > > > you need the actual time of day calculated out to use for it, but > > > otherwise if the game runs in its own time, that'll do. > > > > On Jan 14, 7:02 am, Neilz <[email protected]> wrote: > > > > > Hi all. What is most efficient way of keeping a check on time within a > > > > game thread? > > > > > Currently I create a new Date() when the game starts, and was thinking > > > > of creating another Date() within the game thread and comparing it > > > > with the first one. But with a screen refreshing at around 60fps > > > > (hence a new date object each time), I can't help thinking this is > > > > rather inefficient. What other ways are there of doing this?
-- 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
