[SDL] iOS MultiTasking and CallBacks

[Forest Hale]

I don't think that behavior would be considered appropriate on iOS or Android, users would complain that they just switched away to check their email and go back and it's back to a checkpoint much
earlier.

The saving of exact current state is an expected feature.

On 03/21/2012 11:16 AM, sdl at union.pl wrote:
> 
> A good example would be a game with checkpoints while progressing
> through it. In this case there is no need to save the state of the game
> between checkpoints, because it was already saved at a checkpoint. When
> such game is terminated and ran again the progress starts from the last
> saved checkpoint.
> 
> regards,
> Piotr
> 
> On Wed, 21 Mar 2012, Forest Hale wrote:
> 
>> What kind of game or application would not have state worth saving?  The point is to dump the current state to disk in case the application is purged from memory (entirely) and when the user starts it
>> again they expect to see it exactly where they left off - usually paused but with no other changes.
>>
>> This functionality exists because apps can be entirely deleted from memory at any time when in the background, a typical example is a very memory hungry highend game which literally can't survive in a
>> background state because running anything else is going to cause the low memory warning and then purge it.
>>
>> On 03/20/2012 07:27 PM, sdl at union.pl wrote:
>>>
>>> HI Brian,
>>> For games or applications where no data neeeds to be saved you dont need
>>> to handle didenterbackground and use mutex to arbitrate: the simpler way
>>> would be to make a global variable, containing the state of
>>> your app and change it in callback depending on type of event received.
>>> The main loop can check this variable and execute game state updates,
>>> rendering and audio depending on this variable.
>>> regards,
>>> Piotr
>>>
>>>
>>> On Mon, 19 Mar 2012, Brian Barnes wrote:
>>>
>>>> I've been doing a lot of research on this and while I haven't attempted an implementation (I just hacked the SDL code to call back into my code), I want to explain where I'm coming from.   It does not look like, especially for me, anything but callbacks will work.
>>>>
>>>> There are really 4 message we are looking at (the patch floating around only handles 2 of them, plus memory low.)
>>>>
>>>> applicationWillResignActive
>>>> applicationDidEnterBackground
>>>>
>>>> applicationWillEnterForeground
>>>> applicationDidBecomeActive
>>>>
>>>> How Apple wants you to handle this is:
>>>>
>>>> applicationWillResignActive - slow down or stop your loops
>>>> applicationDidEnterBackground - save your state
>>>>
>>>> NOTE, and this is *very* important.  If you have a tight loop, it will CONTINUE TO RUN during these messages.  ResignActive is called first (where you should shut down your loops) and EnterBackground is next, where you have 5 seconds to save your state.  After 5 seconds, your code is frozen.
>>>>
>>>> The big problem is you need to deal with your loop.  In ResignActive, I'll need to use a mutex to make sure my loop has completed one trip before I release back to the OS, and before I get EnterBackground.  Otherwise, my game will still be generating state and there will be all sorts of havok.  Yes, I'm running a tight loop instead of responding to timers, I understand the ins-and-outs of this :)
>>>>
>>>> The opposite number, EnterForeground and BecomeActive, basically have the same problem in reverse, but should be solved by making sure the loop pauses in the right place.
>>>>
>>>> Even worse, your code is frozen so you can't poll for events; therefore you will never get the "memory low warnings."  Without a doubt, games are going to be the number one targets of this and iOS will just send a KILL to your app after you do nothing on a memory warning.
>>>>
>>>> As I was looking through this, I also noticed that there is a bizarre bit of code to deal with the terminate message.  This is also something that should be in the callback, we'll just have to know if we write an iOS application to handle quiting in a callback.  The same thing applies -- need to mutex the loop and then quit.
>>>>
>>>> Now, you CAN get away with this (in a manner) in the queued polling, you're just asking for a large number or hard to debug crashes in the future.
>>>>
>>>> The original patch is still good.  It just needs to add:
>>>>
>>>> applicationDidEnterBackground
>>>> applicationWillEnterForeground
>>>> applicationWillTerminate
>>>>
>>>> And probably that wacky long jump stuff can go.
>>>>
>>>> [>] Brian
>>>> _______________________________________________
>>>> SDL mailing list
>>>> SDL at lists.libsdl.org
>>>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>>>
>>>
>>> _______________________________________________
>>> SDL mailing list
>>> SDL at lists.libsdl.org
>>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>>
>>
>>
>> -- 
>> LordHavoc
>> Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
>> Co-designer of Nexuiz - http://alientrap.org/nexuiz
>> "War does not prove who is right, it proves who is left." - Unknown
>> "Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
>> "A game is a series of interesting choices." - Sid Meier
>>
>> _______________________________________________
>> SDL mailing list
>> SDL at lists.libsdl.org
>> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
>>
> 
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
> 


-- 
LordHavoc
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier