Discussion Objects are NOT being drawn properly (2.0.5.72)

[psyke]

Hi,

I just installed the new version of GMS 2 (2.0.5.72) and it completely broke my game. Everything is being drawn in reverse order.

I came to the conclusion that in the new version, newly created objects on the SAME layer are being sent to BACK, when in the correct situation they should be on TOP of the other instances.

Here are some screenshots to compare:

(OLD VERSIONS OF GMS 2 - CORRECT!):



(NEW VERSION 2.0.5.72 - INCORRECT!)



As you can see, this is extremely important and needs to be fixed as soon as possible.
Can you guys please take a look into this? This is very important and may break other projects.


EDIT: I tried an empty project and it has the same issues as you can see in the screenshot below:

If I create the "objBlack" on the same layer of "objWhite", it sends the "objBlack" to the back, when in fact it should send the "objBlack" to the front of the "objWhite".

 

[PhenomenalDev]

Seems like a bug, imo there's a few too many issues with gms 2 at this point so stick to 1.x for now until it's properly stable.

 

[nesrocks]

My game also had differences with today's update. It turns out that instances inside the same layer had their depth order changed. I fixed it by changing instances to different layers to ensure depth. But my game has little content so far, so it was quick for me. I can imagine it being a pain for people on already large projects.

 

[psyke]

Yeah it's definitely a bug, but I can't stick with GMS 1.4 because I already ported my game to GMS 2 last year, it has a lot of code.
This is the only problem affecting my project right now, I hope they can do a hot fix for this weekend because we're going to show our project in a big event here. =(

 

[Nocturne]

My game also had differences with today's update. It turns out that instances inside the same layer had their depth order changed.

Draw order within any given layer is NOT guaranteed... If you need something drawn in a specific order, either make it on a different depth or draw it yourself from a controller object in the order you require.

 

[Christoffer Karlsson]

Draw order within any given layer is NOT guaranteed... If you need something drawn in a specific order, either make it on a different depth or draw it yourself from a controller object in the order you require.

Not in this update it seems

 

[Nocturne]

Not in this update it seems

I have no idea what you mean by that? If the user is adding instances to a single layer (and they do say they are), then they can't rely on draw order. The manual clearly explains that to draw things in front or behind you need to use a different layer or depth for the object, so placing them all on a layer does NOT guarantee draw order. This is undocumented behaviour and you can't rely on that as it may change at any time. This was always the case and has nothing to do with the update in that sense. The update however has obviously changed how rendering is done for a single layer and so people that relied on this undocumented behaviour are having issues. But the issues are not a bug to be fixed, but rather a dependence on something that was never documented as a feature.

newly created objects on the SAME layer are being sent to BACK, when in the correct situation they should be on TOP of the other instances.

There is no "correct" situation here. You were using the layers wrong and expecting the results to be consistent, when there has never been any guarantee that this will be the case. If you want something to draw in front or behind something else, either have them on different layers (or at different depths), or create a single object that draws everything and you control the draw order in the draw event of that object.

 

[gnysek]

Yeah, usually it was, that GM ordered instances by their ID (so also creation order), but in case of deactivating instances, or optimizing some pipelines (there was a bug in recent runner version, that deactivated instances were still taken into account in engine-loop, but events were skipped - and probably is now fixed) this behaviour could be broken according to manual, and that actually happened.

 

[psyke]

By consistent, you mean not consistent in THIS version, right? I just gave you a simple example on this topic, you can reproduce it on the older versions and in the new version, the new version is just broken.

I have no idea what you mean by that? If the user is adding instances to a single layer (and they do say they are), then they can't rely on draw order.

Then why it worked as expected on the older versions? Creation order was something that was always considered in Game Maker, and it always worked, but somehow it stopped working on this version.

The update however has obviously changed how rendering is done for a single layer and so people that relied on this undocumented behaviour are having issues.

Yeah, and the question is WHY did you changed that? What are the benefits of that change?

I think it's very inconvenient to create extra layers just to order pieces, I have monsters in my game that have like 12 separated pieces, do I have to create 12 extra layers to get everything showing properly now? This is absurd. And creating a single object to draw everything will compromise the Network experience, this is not a solution.

 

[gnysek]

Yeah, and the question is WHY did you changed that? What are the benefits of that change?

Because documentation says, it can work randomly, so they can changed it. Probably by fixing some other issue or making things faster (like sorting arrays).

 

[Nocturne]

Then why it worked as expected on the older versions?

It worked as YOU expected it, but not as it was designed to be used, which is that if you want an explicit draw order then you GIVE an explicit draw order using layers or depth. And it only works as you expected because you tried it and it worked for you, but that doesn't mean it wasn't different before nor that it won't be different in the future. You can't use something in a way that it was not designed to be used and then complain that it's not working.

Yeah, and the question is WHY did you changed that? What are the benefits of that change?

The change was done to speed up rendering and improve instance deactivation amongst other things. But that's beside the point... the point is that if you want to have a specific draw order you have to TELL GameMaker what that draw order is (using depth or layers) and not depend on GameMaker guessing what you want.

 

[psyke]

The change was done to speed up rendering and improve instance deactivation amongst other things. But that's beside the point... the point is that if you want to have a specific draw order you have to TELL GameMaker what that draw order is (using depth or layers) and not depend on GameMaker guessing what you want.

It's not "beside the point", it's very important to communicate with your costumers when you're going to do major change on the engine like that. If this was announced earlier (geez, at least have it on the release notes), you could have avoided a lot of trouble.

Since there is a REASON behind the change, I will not complain, if it speeds up the rendering process, then good, but next time put that kind of information in the release notes so we can be aware of the situation.

 

[Micah_DS]

@psyke I haven't messed with the new layering system yet, but I did a little thinking and reading around the manual. Couldn't you just do something like this?

var my_new_object = instance_create_layer(x, y, layer_id, obj);
with (my_new_object){
    depth = value;
}

Oops, accidentally pressed tab as if I was doing actual code then posted before meaning to... uh, but yeah. I guess that gives the general idea? You could do that with each object to set the depth for each component of an enemy/whatever while also assigning it to a layer.
Obviously you'd want to do a for loop or something and increment depth for each object as needed or something.

 

[psyke]

Also there is another problem here, if I use DEPTH to order the instances on the same layer, it will change the layer of the object to -1. And this is a big problem since I pass the layer argument to a lot of functions.

@psyke I haven't messed with the new layering system yet, but I did a little thinking and reading around the manual. Couldn't you just do something like this?

var my_new_object = instance_create_layer(x, y, layer_id, obj);
with (my_new_object){
    depth = value;
}

Oops, accidentally pressed tab as if I was doing actual code then posted before meaning to... uh, but yeah. I guess that gives the general idea? You could do that with each object to set the depth for each component of an enemy.whatever while also assigning it to a layer.

I don't think how this could help.

 

[Micah_DS]

Also there is another problem here, if I use DEPTH to order the instances on the same layer, it will change the layer of the object to -1. And this is a big problem since I pass the layer argument to a lot of functions.

Hmm, how are you going about doing this though? Are you using instance_create_depth? Because that doesn't appear to assign to a layer, does it? With my way, I'd expect it would work, but I should do a test to be sure. It's just hard to give an idea without knowing how you're creating all of your multi-object entities.

EDIT: Oh, hmm.. after reading some more on layers, it appears I may have been mistaken and my code is likely rubbish. I'd love to help, but I obviously need to read up even more on layers. Layers appear to have a single depth, which seems problematic.

 

[psyke]

Not being able to order the instances on the same layer is a BIG problem, here's another case:

The player on my game have hair and legs as separated objects (so, there are 3 objects), they are all on the layer "PLAYER", but if I change the depth of the hair or legs to a different depth, they're not part of the layer "PLAYER" anymore, so I can't use the layer name in other functions anymore.

 

[Micah_DS]

Okay, sorry for before for speaking when I didn't know how layers worked, but I gave it some thought. I'm not sure why you are doing the multi-object entities, but you can have one just of your 3 player objects draw the sprites for all 3 parts. Here is an example of what you could do in the draw event of the player body, and you'd still have the hair and legs objects, only they wouldn't draw any sprites, just the body would do the following in the draw event:

//player draw order
draw_sprite(spr_player_legs, index, obj_player_legs.x, obj_player_legs.y);
draw_sprite(spr_player_body, index, x, y);
draw_sprite(spr_player_hair, index, obj_player_hair.x, obj_player_hair.y);

Note that this assumes all instances exist at all times together. If not, you will get an error.

That would end up making the legs furthest back, body in middle, and hair on top. Not sure how you want the draw order, but whatever you want to be top-most, you'd draw at the end, as it would draw over other things. This might not be the best solution, but it's one. Just think a bit and I'm sure you can find a workaround. Many times, programming with a high level programming language means learning to find a solution to make something work nicely within some kind of constraints.

 

[psyke]

As I said on the post #9, drawing everything in the same draw event will compromise the Network experience.
There should be a way to order instance on the same layer without having to change their depth.

Every engine out there works like that, I can have multiple layers on Unity and I can put like 10 objects on the same layer and order them the way I want.

 

[Micah_DS]

As I said on the post #9, drawing everything in the same draw event will compromise the Network experience.

Sorry, I did actually read that, but I thought the problem had something to do with not being able to have one player object, so I thought it might still be solution for you to have all the objects and just draw at the positions of each object - I didn't realize the problem was drawing in one draw event. I'm honestly not sure how this would compromise the network experience for your game? But whatever the case, it appears you'll have to rethink how you want to do some things in GMS2, unfortunately. Or perhaps YYG will be able to change it so that newer objects are always drawn later. Sorry I couldn't really help. I program things quite a bit differently.

 

[psyke]

Sorry, I did actually read that, but I thought the problem had something to do with not being able to have one player object, so I thought it might still be solution for you to have all the objects and just draw at the positions of each object - I didn't realize the problem was drawing in one draw event. I'm honestly not sure how this would compromise the network experience for your game? But whatever the case, it appears you'll have to rethink how you want to do some things in GMS2, unfortunately. Or perhaps YYG will be able to change it so that newer objects are always drawn later. Sorry I couldn't really help. I program things quite a bit differently.

It's ok, thanks for trying to help me anyway.
Drawing everything on the same draw event can compromise the network because I would have to send different parameters through the buffer to identify which draw event I should use for each object, I'm not gonna do that, I'm trying to make the draw event consistent among the instances.

The way GMS handle layers and depth are wrong (?).
Changing the DEPTH of an object should NOT change the LAYER of that object, this is a serious problem with GMS 2 right now, there is a conflict between LAYER and DEPTH.

Let's say I have 2 layers:
- PARTICLES = -200 depth
- ENEMIES = -100 depth

If I create an object in the layer ENEMIES and change it's depth to -500, the object should still remains in the ENEMIES layer and behind the PARTICLES (that's what happens on every engine out there, Clickteam Fusion, Construct, Unity), but that's not what happens on GMS 2, if you set it's depth to -500, the object will be sent in front of the particles and the layer of that object will be changed to -1.

 

[Nocturne]

Not being able to order the instances on the same layer is a BIG problem,

I fail to see how this is any different to the way GMS1.4 (and all previous versions) does it? If you draw anything at the same depth in 1.4, you have no guarantee of what order they will be rendered in...

Changing the DEPTH of an object should NOT change the LAYER of that object, this is a serious problem with GMS 2 right now, there is a conflict between LAYER and DEPTH.

There is no conflict between layer and depth. Depth and layer are essentially the same thing in GMS2, so they can't conflict, you just have to correctly understand how they work. If you want to explicitly set the depth then GMS will create a managed layer for you (which is why the layer ID becomes -1)... If you want to make sure that the layer is NOT a managed layer then you create the instance on a layer, or assign it to one, then set the layer depth value.

This whole issue has come up because you have decided how something _should_ work and that it is the "correct" way, when that is not stated anywhere at all. The correct way to ensure that something is drawn over or under something else is to use depth and layers, not rely on GMS to guess which order you want when they are all on the same layer or depth. That is how it has ALWAYS been documented.

but that's not what happens on GMS 2, if you set the it's depth to -500, the object will be sent in front of the particles

This sounds like a bug that is unrelated to the issue you have so far been discussing and should be filed as a separate issue.

but next time put that kind of information in the release notes so we can be aware of the situation.

Noted! It probably should have been mentioned somewhere...

 

[psyke]

I fail to see how this is any differenmt to the way GMS1.4 (and all previous versions) does it? If you draw anything at the same depth i 1.4, you have no guarantee of what order they will be rendered in...

Yes you have, the guarantee is the creation order. Just open GMS 1.4 and do some tests, you have the guarantee that newer objects are going to be drawn on top of the older objects. If you don't want to use GMS 1.4, just use the older versions of GMS 2, they worked the same way.

The problem now with the new version is that the order is reversed, you still have the guarantee based on the creation order, the difference is that newly created objects are sent to back instead of the front (which makes no sense).

There is no conflict between layer and depth. Depth and layer are essentially the same thing in GMS2, so they can't conflict

If they're the same thing, then they shouldn't be called "layers" because they don't act as layers as I explained in my previous post (#20).

The correct way to ensure that something is drawn over or under something else is to use depth and layers, not rely on GMS to guess which order you want when they are all on the same layer or depth. That is how it has ALWAYS been documented.

As I said, if you change the DEPTH of an object, it changes the layer name as well, so there is no point in having layers here. And if you want to use the layer name into other situations (example: to spawn objects on the same layer of the calling instance), you're not going to be able to achieve that, because you changed the depth of that object and the layer is now -1 (instance_create_depth is not a solution to this problem btw).

 

[gnysek]

Yes you have, the guarantee is the creation order. Just open GMS 1.4 and do some tests, you have the guarantee that newer objects are going to be drawn on top of the older objects. If you don't want to use GMS 1.4, just use the older versions of GMS 2, they worked the same way.

Manual says that there's no guarantee way, even if in 99% this works as you need. And this is only proper answer.

 

[psyke]

Manual says that there's no guarantee way, even if in 99% this works as you need. And this is only proper answer.

For me It's not 99%, it's 100%.
Give me a situation that when I create instances on the same layer their creation order is not taken into account.

I would understand if this happened a few times or something like that, but I've been using this solution for every version of Game Maker, and it always worked in that way, but in the new version they just flipped the draw order somehow (it's like changing black to white).

 

[Nocturne]

Yes you have, the guarantee is the creation order. Just open GMS 1.4 and do some tests, you have the guarantee that newer objects are going to be drawn on top of the older objects. If you don't want to use GMS 1.4, just use the older versions of GMS 2, they worked the same way.

I would understand if this happened a few times or something like that, but I've been using this solution for every version of Game Maker, and it always worked in that way, but in the new version they just flipped the draw order somehow (it's like changing black to white).

Then you've been using it wrong and by sheer chance it's worked for you and now it's bitten you in the tail...Even in 1.4 this was NOT how it was documented to be used. If you were basing your work on something that the manual expressly says not to do, then you can't complain when it doesn't work...

NOTE: Instances of an object that have the same depth can be drawn above or below each other even when they appear to be placed one on top of the other in the room editor. If you want to guarantee that something is drawn over or under everything else, you should always set the depth correctly.

http://docs.yoyogames.com/source/da...nces/instances/instance properties/depth.html

 

[gnysek]

GMS EAP 1.99.525 (latest) - all created objects are sent to back, so older are on top, newest are on bottom.


But, if I change depth, then create another object, and change depth back to initial, the second object will be drawn as it was created as last one:




Is that enough proof, that even having same depth, objects can be drawn differently ?


In GM:S 1.4 it seems that objects with same depth are sorted by last depth variable change, from oldest (top/foreground) to newest (background), not by creation order.

 

[gnysek]

So, a final proof that it was also not working as you think in GameMaker Studio 1.4:

GMZ file, so you can import and check yourself: https://dl.dropboxusercontent.com/u/33525625/depths.gmz

And screenshot with proof if you don't want to download - same depth, created one ofter one, but are not drawn ordered after you press space (and every space press randomizes them again):

 

[psyke]

it's bitten you in the tail...

It bit me in the tail because it was not a problem in my code (since I didn't changed the code after the update), but a problem in the GMS update. The reason for objects being drawn over or under other objects shouldn't be caused by something added later into the engine (since the quote from manual you posted is older than the new GMS version).

@gnysek Of course changing the depth before creating another object will have different effects, because you're not creating on the same depth/layer (you're changing the depth AFTER creation, so the creation order in this case is irrelevant).

 

[gnysek]

@psyke: No, I'm creating all instances with same depth, as depth is given on creation, so before I change it Also in my second post, I'm changing depth from 0 to 0 by spacebar much much later and what? They all have same depth, but order isn't guaranteed. Download and check - they all have 0 depth at all time when drawn

There seems to be rule in it (they are ordered by last "setting" of depth variable), but it's too unpredictable.

 

[nesrocks]

One thing that should be noted is that this change isn't exclusive to adding instances through code. In the room editor when you have your instances listed in a layer, the upper ones were drawn first. Now it has inverted. It looks kind of counter intuitive, because layers orders are respected (even though their order don't mean much as their depth), but instance order has random draw order...

 

[ShaunJS]

Hello! This behaviour isn't strictly a "bug" but an expected side effect of a fix for a different issue. As Mark has said, the draw order of anything on the same layer/depth is never guaranteed and should not be relied upon. It is poor practice to do so.

However we definitely recognise the usability concerns and unintuitive and unexpected situations this can and has created, especially where discrepancies between runner and IDE are concerned. We're discussing interally what approach to take with these issues moving forwards.

 

[psyke]

Hello! This behaviour isn't strictly a "bug" but an expected side effect of a fix for a different issue. As Mark has said, the draw order of anything on the same layer/depth is never guaranteed and should not be relied upon. It is poor practice to do so.

However we definitely recognise the usability concerns and unintuitive and unexpected situations this can and has created, especially where discrepancies between runner and IDE are concerned. We're discussing interally what approach to take with these issues moving forwards.

Alright, I'm trying to work with the depth functions to see where I can go from here, you can close this topic if you want.
Thanks for explaining the situation Shaun.