I haven’t done this myself, but it should be the way.
If you have any issues, please post as I might have broken this when tidying up AndroidGameWindow
IResumeManager and the default ResumeManager implementation are there to help alleviate the long wait while MonoGame reloads all graphics content. It’s intended for drawing a resuming/loading animation of some kind.
The DeviceReset event is the right place to recreate procedural graphics content. If it’s not being called when the app is resumed and the GL context is lost (as the black textures would indicate), then something is definitely wrong.
The DeviceReset event is the right place to recreate
procedural graphics content. If it’s not being called when the app is
resumed and the GL context is lost (as the black textures would
indicate), then something is definitely wrong.
Uhm.
Do you think something is wrong with our application (it’s running fine on Windows Phone)?
Or could it be a bug in MonoGame?
Thanks for the help in any case, Aranda and daveleaver!
It sounds to me like the problem is with MonoGame. In fact I’d be willing to bet it was due to Dave’s recent change here: https://github.com/mono/MonoGame/commit/50638fcb28181beb38957f41b3b07764de61b5bb. I recall adding the _contextWasLost variable was required to detect that the GL Context needed to be recreated and hence textures needed to be reloaded.
I’m probably the cause of the problem. When describing the issue #2427 I said that I thought that the _contextWasLost variable was not being set correctly. Dave submitted the PR and he thought that I knew what I was talking about
However that was true for my device (Galaxy Tab 3 10.1"), _contextWasLost was not being set when I was pausing/resuming my game, despite the textures were obviously lost (black rectangles).
I just tested my game with the aforementioned Galaxy Tab and a Nokia X, and in both devices the DeviceReset is being called and textures restored. Other than taking eons to restore in the Nokia X I see no problem on those two devices.
Are you sure Emiswelt that you’re using the MonoGame version with Dave’s #2443 patch?
Ok that’s interesting, perhaps the old logic for setting _contextWasLost did not work for all devices and the new logic does not work for the device @emiswelt is using.
it could be possible. However in the old code DeviceReset wasn’t being reseted in most devices because CreateFrameBuffer was not being called even after app pause/resume event (that was the original problem which caused the modification)
That’s why I asked @emiswelt about the version he’s using, that would make clear wether _contextWasLost is the problem or not (it could be just than he didn’t update and he’s having the problem some of us have had too).
actually, if I’m not wrong, the absence of _contextWasLost should mean that the context was being restored when it shouldn’t (losing precious time) rather than not being restored, isn’t it?
Hi @Aranda, @daveleaver - not sure if this is related or not, but whenever I switch between my game and another app, then switch back, it takes a very long time for the screen to reappear. Looking through the log, it seems that the graphics context is being trashed and then it is having to recreate all the graphics internally automatically again when the app is resumed - causing the massive lag.
Why is it doing this? Is reloading of the all the graphics really necessary? Other games manage to switch instantly between themselves (and the Home screen) and back again with no noticeable lag - why is it with Monogame?
Note that if I lock/unlock the device, the game returns instantly.
Also note that all of the textures are restored, so that isn’t the issue - just the massive pause when the app is resumed after being backgrounded.
Can a fix be applied to stop it from trashing the context if its unnecessary? Is there another workaround to reloading the textures?
I’m waiting on releasing an Android game and I can’t do that until this issue is resolved - pausing/resuming and having massive lag times inbetween just makes the product look totally amateurish.