GMS 2 Creating a pause screen with a background of the state of game screen before pausing.


Hi, lovely people in the community,

I came across this tutorial today about how to create a pause screen. COFFEE-BREAK TUTORIALS: PAUSING YOUR GAME (GML). This tutorial really provoked lots of new thoughts for me.

This tutorial creates a game screen capture background by deactivating all except the calling instance, drawing the application surface to another custom surface and drawing this custom surface to the screen, all of which happens in the draw event. This really has me wonder that how can you be sure that after deactivating the instances, the application surface will have all instances drawn to it?

This seems to have something to do with the event order. Let's say we have five instances. Instance 1-4 and a control instance that is in charge of pausing and drawing the pause screen. If the draw event of the control instance is called after Instance 1,2,3 but before Instance 4. Does it mean that the pause screen will not have Instance 4 on it? If so, is it a good idea to put the deactivate function in the draw event since you have no idea the order of when all these draw events will be called?

I have tried implementing it myself but with a small tweak. I put the deactivation function in the keyboard I/O event for the designated pause key. It turns out that nothing shows up except the background layer. It seems that If you deactivate the instances in the I/O event, the application surface will have nothing in it when you try to draw it to a custom surface in the draw event.

This goes against my expectations because I thought the application surface would have stuff in it from the previous event loop. But somehow the application surface is cleared after each event loop. If so, when does it get freed? After post draw event?


For draw event ordering; the details are documented in:

About object deactivation:

I do also vaguely remember having to deactivate objects after creating a paused screenshot, but I don't remember why.
Thank you. I made some experiments myself and from that result, I think it's more appropriate to put the deactivation code in an event that comes after the draw event.

For example, if we have instance 1-4 and a control instance, putting the deactivation code in the draw event of the control instance will immediately stop the draw event for those instances that execute draw event after the control instance. Since we have no idea how the five draw events of these instances are ordered, we run the risk of leaving some instances off and they will not be drawn to the application surface.

It would be better to put the deactivation code in events that come after draw event such as draw end.