I think I have a solution here. I’m a little nervous, because I’ve never really modified source like this before. Also screwing up the activate/deactivate/update cycle can have huge repercussions.
Anyway, I noticed this line in Stage.hx:
case 21: // etDeactivate
__setActive (false);
When it processed the stage event of ‘deactivate,’ it deactivates the whole application by calling __setActive(false);
I commented out this line, and sure enough, the app ran in the background without pausing like expected. This was too broad of a stroke however- we still want most of the logic in __setActive(false) to process, because it includes re-broadcasting the deactivate event for other scenarios (and I do process a bit of logic when the deactivate event is called in my main app)
So instead I made two small changes to make proper use of the pauseWhenDeactivated field. First off we have this segment inside of __setActive:
if (!active) {
__lastRender = Timer.stamp ();
__nextRender = __lastRender + __framePeriod;
}
I’m not 100% sure what the effect of this is, but since it seems to have something to do with delaying the next render, I changed it to:
if (!active && pauseWhenDeactivated) {
__lastRender = Timer.stamp ();
__nextRender = __lastRender + __framePeriod;
}
So now that will only be executed if we call setActive(false) AND we still want to pause when deactivated
Lastly, I just added this line to the end of the function right before it exits:
if(!pauseWhenDeactivated)active = true;
so while we may still set the ‘active’ field to false to process some logic inside the function, the end result is that active will always remain true if pauseWhenDeactivated is false. Are there additional repercussions for doing something like this? … maybe? but everything seems to run fine so far :x