Re: Delaying Between applicationWillResignActive and applicationDidEnterBackground
On 21 March 2012 05:25, Brian Barnes gga...@charter.net wrote: I'm facing a real puzzle that might have an easy answer. I've ported my game development software dim3 to iOS. Works fine, but I'm having a problem with the application moving to the background. My problem is twice as complex because I'm trying to figure out what changes might be required in SDL to make this work properly. My biggest problem is this: My game runs in a tight loop. When I get applicationWillResignActive (after the home button is pushed), I immediately put up a flag to stop the loop BUT the loop could be in ANY place. In physics, in rendering, etc. What I need to do is let the loop complete another complete revolution so it finishes everything it needs to do and then get held up at the flag that halts it. Without this, I can't save, and the restart will happen at a random place. The problem is applicationDidEnterBackground gets called immediately without any more time given to my application. I can't save state because state might be in a strange place! The easy solution is to block between the callbacks. This blocking will be in the milliseconds. But my application gets no additional time between the two calls (as far as I can tell, it's hard to debug these calls.) Another good solution would be someway that when I get into applicationDidEnterBackground I can tell it to recall me and then return. [Additional notes: I *suspect* I'm only getting applicationWillResignActive etc when events are pumped; the problem is SDL has a number of routines that auto-pump events which means I could receive this message at numerous places in the loop]. These kind of problems are never ending because SDL's model just doesn't fit on the iPhone. In the end I was only using the audio subsystem, touches wrapped up as multiple mice the GL wrapper which are easy to replace with CoreAudio, [UIResponder touchesBegan:withEvent:] and an EAGLContext. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Delaying Between applicationWillResignActive and applicationDidEnterBackground
On 3/21/2012 6:14 AM, Rhythmic Fistman wrote: On 21 March 2012 05:25, Brian Barnesgga...@charter.net wrote: I'm facing a real puzzle that might have an easy answer. I've ported my game development software dim3 to iOS. Works fine, but I'm having a problem with the application moving to the background. My problem is twice as complex because I'm trying to figure out what changes might be required in SDL to make this work properly. My biggest problem is this: My game runs in a tight loop. When I get applicationWillResignActive (after the home button is pushed), I immediately put up a flag to stop the loop BUT the loop could be in ANY place. In physics, in rendering, etc. What I need to do is let the loop complete another complete revolution so it finishes everything it needs to do and then get held up at the flag that halts it. Without this, I can't save, and the restart will happen at a random place. The problem is applicationDidEnterBackground gets called immediately without any more time given to my application. I can't save state because state might be in a strange place! The easy solution is to block between the callbacks. This blocking will be in the milliseconds. But my application gets no additional time between the two calls (as far as I can tell, it's hard to debug these calls.) Another good solution would be someway that when I get into applicationDidEnterBackground I can tell it to recall me and then return. [Additional notes: I *suspect* I'm only getting applicationWillResignActive etc when events are pumped; the problem is SDL has a number of routines that auto-pump events which means I could receive this message at numerous places in the loop]. These kind of problems are never ending because SDL's model just doesn't fit on the iPhone. In the end I was only using the audio subsystem, touches wrapped up as multiple mice the GL wrapper which are easy to replace with CoreAudio, [UIResponder touchesBegan:withEvent:] and an EAGLContext. The goal here is to SDL up to snuff when I figure out exactly what the problems are. dim3 runs on OS X, windows, and now iOS with all the same files, and I'd like to keep it that way. I guess one important question will help: when is it possible for applicationWillResignActive callback to hit the delegate? Anytime? Or just during an event pump (SDL is using: CFRunLoopRunInMode(kCFRunLoopDefaultMode, 0, TRUE); to pump.) If it is only during this pump (which I suspect is true as it's in the same thread), then the first solution is to remove all unnecessary pumping from SDL itself. If it's not true, then my problem is outside of SDL. [] Brian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
RE: Delaying Between applicationWillResignActive and applicationDidEnterBackground
Julius Oklamcak wrote: Have you looked into using UIApplication's -beginBackgroundTaskWithExpirationHandler: in the UIApplicationDelegate's-applicationDidEnterBackground: to give you some background run time to finish the loop? The problem is I need my loop to finish before didEnterBackground is called so I know the state is in a good place (i.e., not right in the middle of running physics.) I have all the time I need to actually save the state. I'm beginning to suspect I'm out of luck. I'm going to have to do a lot of runs to see how and win I get the original message, I suspect there's something in SDL that makes it harder (i.e., some additional pump events in there.) [] Brian ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
