# Legacy GM2D top-down problem with depth

#### jobjorgos

##### Member
Hi,

I got the following problem in a 2D (fake 3D) top-down game with the depth order between objects:

The movings cart depth = -160 (i cant expalin this number, i got it purely from just guessing untill it kinda works)
The trees depths = 0

In all static objects (like trees and rails) i have in CREATE: depth = -y;
In all moving objets (like player and carts) i have in STEP: depth = -y;

I though what ive done with the depth = -y; would be all i needed, but running the game proofs its not

Right now with my experience and knowledge the only thing i can do is set the depth of EVERY SPECIFY item in every room in my whole game... is there any way the depth order between objects in a top-down 2d game can be automated?

Thanks in advice, i hope i can safe alot of time with any method

#### NightFrost

##### Member
Remember that the code you use reads the origin point y-value. If the origin point is on the top of the sprite on the cart, and on the bottom of the sprite on the tree, the tree's y-value is greater, and will be given depth that is nearer to the screen surface.

A

#### Aura

##### Guest
The depth = -y logic should work. Some things might affect the output, though. For instance, different sprite origins would lead to different depths in spite of being at the same level. I would recommend using the bottom-centre point as origin of all the sprites.

#### jobjorgos

##### Member
Remember that the code you use reads the origin point y-value. If the origin point is on the top of the sprite on the cart, and on the bottom of the sprite on the tree, the tree's y-value is greater, and will be given depth that is nearer to the screen surface.
first of all thanks for your time.

hmmm, alright im reading what youre saying... but i dont see the conclusion of it? what do you wanna say with it? (top down games with many different depths is very complicated anyway)

#### jobjorgos

##### Member
The depth = -y logic should work. Some things might affect the output, though. For instance, different sprite origins would lead to different depths in spite of being at the same level. I would recommend using the bottom-centre point as origin of all the sprites.
Alright! I gonna try if that might works

#### NightFrost

##### Member
What I implied is what Aura explained above: have the origin point in the same spot for all sprites, bottom center being one such good spot.

#### TheouAegis

##### Member
One object:
End step event:
with all depth = -bbox_bottom

#### hippyman

##### Member
One object:
End step event:
with all depth = -bbox_bottom
To further explain to those who might not understand the benefits of this... bbox_bottom is always the very bottom of the sprite regardless of origin or image_angle. Using depth=-y will use the point on the sprite that was set as the y-offset in the sprite editor. The built-in bounding box is a rectangle that constantly updates to the objects current orientation so depth=-bbox_bottom is always guaranteed to be at the "foot" of the sprite regardless of the sprite's origin.

This is actually a clever use of the built-in variables that I'm bummed I never thought of before.

#### TheouAegis

##### Member
Or bbox_top, if using tiles for trees and stuff.

#### jobjorgos

##### Member
amazing! useing in the step of moving objects:
Code:
``depth = -bbox_bottom``
and setting the origin of all sprites to the middle bottom solved everthing!
thanks alot for sharing this very usefull info that saves alot alot of time struggeling for me

A

#### anomalous

##### Guest
I am doing a full game and I have way too many sprites, and have to import them back in way too many times, to mess with changing sprite origin through the GUI.

If you find this is an issue for you as well, you can change the sprite origins programmatically, record the new position once, and no matter how many times you change the sprite, you never have to move that origin from the default upper left. (unless your sprite size changes, then you need to adjust that number once again).

If its smaller stuff, I'd change it using the GUI as recommended. Just a consideration.

#### jobjorgos

##### Member
Oh nice never know it was possible at all do change it programmatically. is it done with an extension?

I just did it manual for my 250 sprites (all of different sizes) i had, took about 20 minutes to do it, but its alright its good now

the most time i lose is with importing every sprite individual to my project, and then assigning it to an object aswell, but in gamemaker:studio 2 this will become more automatilly if im not wrong