• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

Creating a delay for sprites in Android Game

Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all, been having some issues with this for quite a while and I'm hoping someone can advise me on the best approach.

I need to create a way to create a 'delay' before something happens in my game. Best example I could give would be - a grasshopper sprite. It waits 5 seconds, then jumps. then waits 5 seconds, then jumps etc...

Now, if the 'droid receives a phone call or the user presses the home key or for some other reason, then app is sent to the background, and then resumed, the delay needs to stay intact.

So, the grasshopper jumps, then 2 seconds later, the user presses the Home key. Then 4 minutes later, relaunches the app. It needs to pick up where it left off. Therefore, it would need to finish the current delay (3 more seconds to go before next jump) - not start again at 5 seconds or jump immediately.

Currently, I'm trying 2 methods but nether is perfect. If I use the System Time to determine the delay, like so:

Now this does work and the good thing about it is that it isn't tied to my game loops' tics per seconds (which is limited to 60) so if, (however unlikely), my app were to run on a device that could only handle 25 ticks per second, the delay would still be 5 seconds as it's based on the System Time which is constant across all devices.

The problem is that when the user presses the home key, the System Time keeps ticking away, so when the app is restored, the action (the jump in this case) happens straight away because the 5 seconds would have passed (while the game was inactive).

I've tried to mitigate this by saving the current time in a Bundle when the app goes into the background and on restoring the bundle, comparing the current time to the saved time to see how long the app was inactive for - and this does work, but again, there are issues....

* As this is an OpenGL App, every time the app is re-launched after the GL Context has been trashed by the OS, it will need to re-load my bitmaps and textures. This takes about 5 seconds. This happens after the time has been worked out, therefore when the game is re-started, this time comes off the new delay time, so if my sprite's pause time was 20 seconds, and the app was killed after 10 of those seconds had passed, there should be 10 seconds left. App is killed by the OS and 20 seconds, later we re-launch. At this point, it says 'App was dead 20 seconds' so add this 20 seconds to the time that was grabbed in the above code (which has also been restored in the Bundle) and then the app takes 5 seconds before the game actual re-commences, so we only get a further 5 seconds, not 10.

* What happens when the app is sent into the background but not trashed by the OS and then re-launched? The Bundle is never restored and this is when I am doing my time comparisons. Therefore the time would never get updated in this instance and the sprite action would happen straight away.

The seconds option would be simply to set a timer, say 300 and on every game tic, subtract one. When the value reaches 0 carry out the action. As I know I'm operating at 60 tics per seconds, then that should be 5 seconds. As the game-loop wouldn't be running during pauses etc. Then there would be no issues. However, what would be an issue is if the game were to run on a device so slow that the loop dips below 60TPS, (so at 30TPS, all delays would be twice as long).

(This is all based on my current Game Loop which renders as fast as the device can handle and limits the game updates to 60 per seconds, everything is moved by means of a fixed time delta, I don't envisage any device not being able to produce 60 tics per seconds if I'm to be honest, but if possible I would like to prepare for that in case it does happen).

Should I just stick with latter of the 2 methods? (the countdown timer) or is there a better option?

Thanks for bearing with me and I hope someone can help!
    Bookmark Topic Watch Topic
  • New Topic