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
