Pause support.

I think it’d be really nice to have some built in pause support. Could work like the following:
Runtime:pause

  • slows the game down to 4 frames a second

Runtime:resume

  • back up to 30 fps
    Events:
    applicationPaused
  • fires when Runtime:pause is called

applicationResumed

  • fires when Runtime:resume is called [import]uid: 70 topic_id: 349 reply_id: 300349[/import]

What are you trying to do? As it stands, you can remove the enterFrame listener, and resume by adding it back. [import]uid: 5 topic_id: 349 reply_id: 561[/import]

Yep, that’s how I’m currently doing it, but when I remove listeners the app is still running at 30 fps which is ostensibly still eating up battery life.

Right now I use a scene manager that essentially wraps a top level group of ‘scenes’ which are themselves also just groups of layers which are just groups of game objects etc. When my pause button is hit an event is fired that runs a ‘pause’ method on all of my scenes and then moves a pause scene to the front of the group, which is given focus.

There’s also a lot of general cleanup to handle when pausing and resuming such as disabling hit tests and removing all listeners, stopping movie clips, transitions, etc.

I think timers, sprite animations and transitions all use the enterFrame event so it’s not actually clear to me how you would trivially resume those with just removing the enterFrame listener from a display object and reattaching it.

My scene manager does basically what I need at the moment, but my main concern was reducing battery usage when I’m not doing any simulations and just waiting for one of x buttons to be pressed.

Is there a better way of doing this? How would you go about resuming transitions etc without keeping state and simply restarting them where they left off? [import]uid: 70 topic_id: 349 reply_id: 563[/import]

I see what you mean, but if you’ve turned off the various listeners and timers, and nothing much is happening on the screen, then the app shouldn’t consume much battery at that point (and the iPhone will go to sleep after 60 seconds). Actually halting or slowing the runtime framerate would have some bad side effects, such as making interaction really poor.

As an aside, you can avoid some coding for disabling hit tests if you have your game in a master group and just move the entire thing offscreen (set x=1000 or whatever). This is admittedly a lazy solution, but I’m a fan of lazy. [import]uid: 3007 topic_id: 349 reply_id: 568[/import]