Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » [A5] iOS - Touch Events non-functonal when game resumes from hibernation

This thread is locked; no one can reply to it. rss feed Print
[A5] iOS - Touch Events non-functonal when game resumes from hibernation
thebignic
Member #14,419
July 2012

I notice that if my iOS game hibernates for more than a few minutes (closed from the Home button) that when I resume, it seems like the event queue is not always notified of new touch events. Seems the longer I leave it in hibernation, the more likely it is to not respond to touches when I resume.

As far as I can tell, I am properly handling the switch in/out, acknowledging, etc (as well as handling display lost/found events.)

Background audio stream always resumes fine, and the screen displays the proper "paused game" graphics. Since I am not manually refiling my stream buffer, I'm not sure if the audio playing is evidence that the event queue is actually functioning or not. And since the paused graphic is drawn before the game actually yields to iOS, I'm not sure if that's just buffered graphics or if its actually processing redraw events either. Tonight I'll try drawing something dynamic to the screen to see if this is the case... but meantime...

When the display is switched out/in, should I detroy/recreate my event queue/sources? Are there any pitfalls in doing so?

I haven't played with code yet, just brainstorming what the problem might be and any potential solutions.

Trent Gamblin
Member #261
April 2000
avatar

I had this problem at one point. You solution might work. What turned out to be the problem for me was timer events still ticking, so on resume the game pumped through thousands of them causing a long delay. You could either use al_flush_event_queue, or stop and restart the timers on pause/resume.

Thomas Fjellstrom
Member #476
June 2000
avatar

I'd suggest stopping anything and everything on pause. shouldn't need to destroy stuff, unless you want to be super memory friendly. or just free temp stuff on a low memory warning.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

thebignic
Member #14,419
July 2012

Ahhh Trent I definitely think you're onto something because sometimes if I just wait a while, it seems to come back (if I don't get impatient and end the task first.)

I guess my assumption was that events wouldnt be generated while it was in background. DOH!

Thomas: What do you mean by stopping? Unregistering the event sources?

Everything as far as my game's drawing/update processing is stopped on pause. I just wasn't aware that events would still be firing after the switch out.

Trent Gamblin
Member #261
April 2000
avatar

I agree with Thomas, you should stop anything that might generate repeated events, mainly timers. I was just giving some options. I bet it's your timers though. Stop them on pause (al_stop_timer) and restart them after (al_start_timer.)

Thomas Fjellstrom
Member #476
June 2000
avatar

thebignic said:

Thomas: What do you mean by stopping? Unregistering the event sources?

What Trent said. stop the timers. And if you have any secondary threads or other async tasks, try and pause or stop those as well. Unless its some background download you want to keep going.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Peter Wang
Member #23
April 2000

Also consider al_pause_event_queue

SiegeLord
Member #7,827
October 2006
avatar

I'm a big confused about what's happening here. I thought the app still functioned when minimized, it just couldn't draw?

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Thomas Fjellstrom
Member #476
June 2000
avatar

There is no minimization... but you can do stuff in the background if you really want, but you generally don't want to. people will complain about power use.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

SiegeLord
Member #7,827
October 2006
avatar

but you can do stuff in the background if you really want

Hence my question. Timer events should be firing off in the background, and, unless you purposefully do something, should be handled as normal. I don't get why they are backing up.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Trent Gamblin
Member #261
April 2000
avatar

It depends how you write your program. You can do it so that what you said is true, but then you're wasting resources on a limited device. Here's an example of how this can happen:

if (event.type == ALLEGRO_EVENT_DISPLAY_HALT_DRAWING) {
    // some cleanup code here
    al_acknowledge_drawing_halt(display);
    while (true) {
        ALLEGRO_EVENT e;
        al_wait_for_event(display_event_queue, &e);
        if (e.event_type == ALLEGRO_EVENT_DISPLAY_RESUME_DRAWING) {
            break;
        }
    }
    al_acknowledge_drawing_resume(display, NULL);
    // reset as needed and continue
}

If you need to process stuff in the background this doesn't work, but it spares the (possibly insignificant, but not necessarily) processing of your logic. NOTE: I intentionally left the stop/start timer out to show the potential problem. Also I used a separate event queue for display events only so you're not processing the other events.

Which brings up a good point, why not just skip those events in that loop? You could do that and it wouldn't cost much of anything.

SiegeLord
Member #7,827
October 2006
avatar

I see. I just make the timer events a nop in my app when it is switched out, so this issue didn't hit me.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Thomas Fjellstrom
Member #476
June 2000
avatar

Of course you can even save whatever cpu time that takes by just stopping the timer. The only events that you'll get after that are resume events. So your loop shouldn't even run till you get switched back to.

--
Thomas Fjellstrom - [website] - [email] - [Allegro Wiki] - [Allegro TODO]
"If you can't think of a better solution, don't try to make a better solution." -- weapon_S
"The less evidence we have for what we believe is certain, the more violently we defend beliefs against those who don't agree" -- https://twitter.com/neiltyson/status/592870205409353730

Elias
Member #358
May 2000

I think it's better to stop the timer. The app really shouldn't do anything at all besides wake up on the switch-in. Otherwise if you have 100 apps thinking like that (and since no app ever quits that is easily reached) you drain your batter just handling 6000 timer handles / second (each of them 60). It doesn't sound much, but it means the kernel has to do 6000 context switches and keep/reload code into memory just to handle the NOP timer events.

--
"Either help out or stop whining" - Evert

SiegeLord
Member #7,827
October 2006
avatar

Maybe for a future app. Going through the pain of sending out a new version just to fix this minor issue isn't worth my time :P.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

torhu
Member #2,727
September 2002
avatar

That's exactly the attitude that makes me want to try your app, don't you ever change it ::)

SiegeLord
Member #7,827
October 2006
avatar

torhu said:

That's exactly the attitude that makes me want to try your app, don't you ever change it ::)

Not doing iOS development out of my own volition, so see if I care :P.

Seriously, I was just curious why my app didn't hit this bug, then explained why... and everybody ganged up on me because I'm this evil person who decreases their battery life by 0.1%. Obviously I didn't do it on purpose, but it's obvious that this isn't really an issue either. If you care that much, amend the bloody iOS readme and documentation for the display halted event to explain the best practices for it.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Go to: