Question - Code Drawing within With clause


I'm not sure if this is a bug or intended behavior, but it did not behave how I expected:

  • Let's see you have two objects, obj_a and obj_b.
  • These objects are on two different layers in the room, layer_a and layer_b
  • within the draw event of obj_a, if you use:
with (obj_b){
   draw_sprite(spr_name, 0, 0, 0);
  • the sprite actually gets drawn on layer_a, NOT layer_b.
Is this the intended behavior? I had thought that any code within the "with" block was being run from the perspective of the "with" instance, meaning that the sprite should be drawn on layer_b (the layer that the object obj_b is on).


I think it's not actually drawn from the perspective of the other instance, I believe "with" just means you have access to the instance's variables.

Also thinking about it logically, it would be difficult for the computer to draw things on different depths within a single script. The computer goes through the scripts one by one and retroactively drawing something underneath something else isn't possible. (Correct me if this crude technical analysis is wrong).


This is perfectly expected behaviour that I've explained in one of my articles:
A with block in the Draw event does NOT change the drawing depth. If you need to draw at a different depth, change the depth ahead of time. If you need drawing subroutines to happen at a different depth, create instances of worker objects at those depths to do the drawing for you.
A with block allows you to access another instance's variables and execute actions as another instance, but it won't allow you to do things retroactively. Once anything drawn makes its way onto the application canvas, all that matters is which got there first. Layers and depth don't count anymore.


Okay, thank you for confirming. I was confused by the GMS2 documentation which says "[the code within the with clause] is now executed for each of the indicated instances, as if that instance is the current (self) instance."

It does make sense that drawing order could not be "patched in" retroactively in such a way though.