Is GLB_ON_QUIT called after SHOWSCREEN?

Previous topic - Next topic

Wampus

Hi! Does anyone know if GLB_ON_QUIT is called after SHOWSCREEN or immediately upon application exit, if there is a difference.

It has occurred to me that if a game is saved in GLB_ON_QUIT and the game is half way through a status and physics update the result could be disastrous on reloading. If its called after SHOWSCREEN then no problem, since status and physics updates will normally have been through one full step by then, unless your code is crazy.

If no one knows I'll code a test routine to find out. I imagine different devices might behave differently.

spacefractal

I ment have seen that in greedy mouse, but dedicated save on level change and when user change to menu. It's could without thinking it have been same issue.

Howover you could add a stastus variable that change when you paint your graphics.
Genius.Greedy Mouse - Karma Miwa - Spot Race - CatchOut - PowerUp Elevation - The beagle Jam - Cave Heroes 2023 - https://spacefractal.itch.io/

MrTAToad

It should be called on application exit...

Wampus

spacefractal that might be. I've been getting strange error reports for PowFish on WebOS for some time and haven't been able to recreate them. Saving the game state half way through a status/physics update may have been the issue all along.

MrTAToad I know its called on application exit but I was wondering if the application is typically exited during 1) the middle of a game loop, or 2) at the end when SHOWSCREEN is called.

So far I've discovered that on the Android platform the case is 1. GLB_ON_QUIT can be called if the application is exited right in the middle of the game loop, so before SHOWSCREEN is done with. That's a problem. In fact, its kind of a huge, massive problem for games that save their entire game state within GLB_ON_QUIT so that players can start exactly where they left off. Oh well. I've added a little code to measure whether all the status/physics steps have been completed in my games that save on exit. If the steps aren't complete the game is not saved. Might piss off some players but its better than a saved game that potentially causes gameplay glitches or crashes the app.

From now on I'm only going to include console style fixed save points and maybe a 'please do not exit app' message while saving.

kanonet

Wampus im pretty sure that the game can get stopped at any time in the loop, which of cause means that GLB_ON_QUIT gets called anywhere in the loop. This is just how i always expected it to work, cause you need to remember, that the OS can force the game to stop - and than the game needs to stop and not just run longer, like the programmer wants. So an immediately stop is what should be intended. If you save your game in GLB_ON_QUIT, you should just add a status variable in your loop (which tells what you are doing right now) and have a backup of your data before the process, so if the game ends, and GLB_ON_QUIT gets called you can decide if you finish the calculations and save after this, or if you just save the backup data from last calculation step. But be sure that you dont get a problem when the stop happens inside the backup process. :nana:
Lenovo Thinkpad T430u: Intel i5-3317U, 8GB DDR3, NVidia GeForce 620M, Micron RealSSD C400 @Win7 x64

MrTAToad

I would think it could happen at any time - would depend on what sort of handler is used, I presume

Wampus

Quote from: kanonet on 2012-Sep-09
If you save your game in GLB_ON_QUIT, you should just add a status variable in your loop (which tells what you are doing right now) and have a backup of your data before the process, so if the game ends, and GLB_ON_QUIT gets called you can decide if you finish the calculations and save after this, or if you just save the backup data from last calculation step. But be sure that you dont get a problem when the stop happens inside the backup process. :nana:

A way to monitor internal status is what I've gone with. I will be using that from now on where appropriate. Its quite simple really. Two global variables are prepared. One is increased just before a 'step' in the main game loop that changes the status/physics of things in the game. The other is increased immediately after a full step is complete. If the game was interrupted somewhere during a step the two variables won't match up. If this is the case the saving feature is disabled. Most of the time the game is interrupted during the screen drawing phase or the pause for the vsync from SHOWSCREEN so saving generally works.

Re: the backup process getting interrupted I've thought of that before now. A similar technique to the above can detect whether the game was successfully saved before being interrupted. Even better would be a full CRC. However, some saves will be huge so there just isn't enough time to run a CRC before the app is forced to close completely. For example, PowFish saves are between 10044 bytes and 10066 bytes because the entire game state is saved like a snapshot. Depending on hardware/software I've found that is often too much data to run a CRC on before saving.

spacefractal

#7
There more annoyring part as I was and is concern extractly this issue could been happens in Greedy Mouse, which have around 50-60kb total (in 2 files, one for progress and one for level).

To detect a succesfully save could just been add a dummy line or a variable, which could should allways been the same in the endline. If that is missing, then the savegame would been corrupted, and then trying to reload from the backup instead. Howover I have not tried that yet.
Genius.Greedy Mouse - Karma Miwa - Spot Race - CatchOut - PowerUp Elevation - The beagle Jam - Cave Heroes 2023 - https://spacefractal.itch.io/