Overlapping Objects in UI/GUI

[Sean Catherine]

Is it possible to program overlapping objects individually on same layer of UI/GUI? Example:

 

[Alice]

Generally:
1. If you put multiple objects with "Draw GUI" logic on the same layer, then they will be drawn one over another; but it's not certain which is drawn over which.
So unless you care about the drawing order, you don't want that.

2. If you put objects with "Draw GUI" logic on different layers, then their overlapping order will be determined by layer depth (the object with highest depth will be below all others, the object with lowest depth will be above all others).
If these objects are created programmatically, then you can e.g. use instance_create_depth function and decrease depth by 1 for each object you want drawn above the previous (I imagine in real GUI there are few enough overlaps for it to be viable).

3. You can also put drawing logic elsewhere, e.g. in "User Event 0" or in some function. Then one central object could use its "Draw GUI" logic to call other objects' drawing logic from depth-bottom to depth-top.
So it could look like:

// in some ctrl_GuiDrawer object or whatever
with (obj_BelowGui) {
    event_user(0);
}
with (obj_MiddleGui) {
    event_user(0);
}
with (obj_AboveGui) {
    event_user(0);
}

And then whichever drawing logic these objects have in "User Event 0", the obj_BelowGui will be drawn below others, obj_MiddleGui will be drawn in between and obj_AboveGui will be drawn above others.
Note that when you perform drawing logic with external object like that, the depths of individual objects are ignored.

 

[NightFrost]

1. If you put multiple objects with "Draw GUI" logic on the same layer, then they will be drawn one over another; but it's not certain which is drawn over which.

And since quite a few beginners fall into a trap here, I feel it is worth mentioning that while the draw order of instances on the same layer may appear stable each time you run your game, it isn't. The draw order is undefined, meaning GM makes no promises about it. In a certain project of mine I had instances in a room I thought I had placed on different layers, but they actually were on the same. Everything looked fine until after one GM update it didn't. Something had changed internally in the engine, maybe in how it built or accessed room contents, but resulted in altered draw order.

In other words when you need to maintain draw order use the tools given; either use layers or take control of draws though code.

 

[Sean Catherine]

And since quite a few beginners fall into a trap here, I feel it is worth mentioning that while the draw order of instances on the same layer may appear stable each time you run your game, it isn't. The draw order is undefined, meaning GM makes no promises about it. In a certain project of mine I had instances in a room I thought I had placed on different layers, but they actually were on the same. Everything looked fine until after one GM update it didn't. Something had changed internally in the engine, maybe in how it built or accessed room contents, but resulted in altered draw order.

In other words when you need to maintain draw order use the tools given; either use layers or take control of draws though code.

In my use case, the alpha of these objects will not be overlapping, only the outskirts of the sprites. I do have a related question though... Would there be any disturbances in overlapping objects on a regular instance layer which I've manually dragged in/arranged? It is important that these objects stay precisely the way I've placed them. In this case, the objects represent pieces of ground that will react with player contact.

 

[Nocturne]

In my use case, the alpha of these objects will not be overlapping, only the outskirts of the sprites. I do have a related question though... Would there be any disturbances in overlapping objects on a regular instance layer which I've manually dragged in/arranged? It is important that these objects stay precisely the way I've placed them. In this case, the objects represent pieces of ground that will react with player contact.

Draw order on any single layer is NOT guaranteed, and may change between runs of the game, between leaving a room and coming back to it, or even across platforms. If you want an explicit draw order for anything that is on the same layer (or on the GUI layer) then you need to create a draw controller and do it yourself.

 

[Sean Catherine]

Draw order on any single layer is NOT guaranteed, and may change between runs of the game, between leaving a room and coming back to it, or even across platforms. If you want an explicit draw order for anything that is on the same layer (or on the GUI layer) then you need to create a draw controller and do it yourself.

Is there such an order/script that a programmer could write which would account for an already-curated layer full of assets or instances; —their overlapping placements— and the script would basically say, "draw that, just how it's arranged"? By the way, I'm not requesting such an explicit piece of code/script here; I just want to know if there is a likelihood or not that an experienced programmer could come up with one (whatever that may look like). thx

 

[NightFrost]

Is there such an order/script that a programmer could write which would account for an already-curated layer full of assets or instances; —their overlapping placements— and the script would basically say, "draw that, just how it's arranged"? By the way, I'm not requesting such an explicit piece of code/script here; I just want to know if there is a likelihood or not that an experienced programmer could come up with one (whatever that may look like). thx

When it comes to purely visual overlap, the answer is no because overlap is not a property inherent to instances on a layer. One could say it is an artifact caused by how the room editor chooses to resolve overlap conflicts when visually presenting the room for you.

Of course one could always attempt to infer the z-order from other cues, such as their vertical positioning, and build an authoritative depth order listing from that.

 

[Sean Catherine]

When it comes to purely visual overlap, the answer is no because overlap is not a property inherent to instances on a layer. One could say it is an artifact caused by how the room editor chooses to resolve overlap conflicts when visually presenting the room for you.

Of course one could always attempt to infer the z-order from other cues, such as their vertical positioning, and build an authoritative depth order listing from that.

Thank you for that. I do know of scripts out there that order instances according to their y axises. Such a script may not solve all of my current design problems, but it's a big help.

 

[FoxyOfJungle]

It's good to remember that while on the same layer, the depth of the items/sprites drawn will be relative to the order they are created/drawn via code. So if for example it's an RPG system, you need to keep this in mind to update this depth in real time. Drawing them in an inverse loop on the draw for example will draw the items with the inverse depth.

 

[Sean Catherine]

Draw order on any single layer is NOT guaranteed, and may change between runs of the game, between leaving a room and coming back to it, or even across platforms. If you want an explicit draw order for anything that is on the same layer (or on the GUI layer) then you need to create a draw controller and do it yourself.

Would it be difficult to write a script that would retain the draw order of sprites already dragged in on an assets layer, for example (sprites which don't use any other code —that I know of— other than to be drawn and be visible in their respective places and sequence)? What I've noticed is that they don't ever change their order (overlap) no matter how many times I run the game... I can't foresee a situation where that order could be disturbed given that the layer properties window shows their order (is that listed order "programming enough")? If there were to be some disruption and the sprites were drawn out of original order, would that not reflect in that window; and if so, could that be considered a glitch...? Either way, it would be good to have a safeguard. thx