• Hey! Guest! The 40th (!!!) GMC Jam will take place between February 25th, 12:00 UTC to March 1st 12:00 UTC. Why not join in this very special anniversary jam! Click here to find out more!

GMS 2.3+ Perspective and collision

Elicarus

Member
I've been looking on a lot of tutorials, but I can't find anything about that. Maybe it's too simple?
Let me explain myself :
Front of tree.PNGThe red parts are the collision boxes i put on my tileset.
Here my character is following what i want to be the perspective of the game.
But if he goes further, trying to go behind the tree by the right,
NOT behind tree.PNG
Well, he's still in front of them, and needless to say that this does not follow what i want.
I understand that he is in front of the trees because the tileset layer is behind the instance layer, but, i don't know, that perspective issue seems so logical that i came to think there was an obvious way to solve it. I didn't find it though.
Any help to teach that lil big boy how to go behind or in front of trees when i want him to would be very appreciated, thanks! :)
 

Yal

🍋 *lemon noises*
GMC Elder
You manually need to depth sort things for cases like this:
  1. give all the sprites a "bottom center" origin
  2. put depth = -y in the create event of anything that doesn't move, and the end step event of anything that does move.
 

Elicarus

Member
It works perfectly with instances! Thank you very much!
But it leads me to two questions :
How does that mysterious line solving all my problems does work, and what is the link with the bottom center origin?
How can i create the same effect with tileset, if possible? Even though it would be logical if it's not
 

Yal

🍋 *lemon noises*
GMC Elder
what is the link with the bottom center origin?
That's the part of the sprite that's in contact with the ground in threequarter perspective, so that's what determines how north/south something is located.

How does that mysterious line solving all my problems does work
It means "the further down something is in the room, the closer to the camera it should be". (depth is the built-in depth sorting variable, higher values means that something is further back --> lower values means something is closer to the camera)

It won't work with tiles, since tiles all need to be on the same layer. The easiest solution is to only use tiles for things that's always the furthest back (e.g., ground) and then using instances for everything that could potentially be in front of the characters, e.g. trees.
 

TheouAegis

Member
I mean, you COULD use tiles, but you'd need a layer for every row of tiles. You'd essentially need N tilemaps, where N is the number of rows of tiles. I don't remember how that plays out performance-wise, but I would expect the rooms to take a hit as the number of rows go up, since the Draw routine will need to loop through the entirety of every tilemap. However, that does mean you could stabilize performance by limiting the size of all tilemaps to just one row (i.e. room_width/tile_width x tile_height) and offset each tilemap vertically based on what row it's on. It'd be a pain to set up, but I suspect (I don't have GMS2 anymore) it would be a significant performance boon compared to using the default tilemap settings for each layer.

Edit: If memory ain't a concern for you, which it isn't for most people nowadays, it should be a relative cinch to automate the whole process and allow you to keep using one or two tilemaps for all your room editing needs. Basically you would have a Room Start event (or the Room Settings code) loop through the tilemap that has all of the height-adjustable tiles, creating a new tilemap layer set at depth -D, where D is the current row*tile_height, with the size of one full row of tiles, and add each tile data blob in the main tilemap to the new tilemap. Once the loop has finished hide the main tilemap layer. If a layer is invisible, the entire Draw subroutine for that layer is skipped (except for instances, which exist outside of the layers they are on).
 
Last edited:

Yal

🍋 *lemon noises*
GMC Elder
One of the reasons I don't really bother depth-sorting tiles in my game is that you can't have partially transparent tiles without multiple layers (since you just get a hole through the entire world if the tiles are transparent...) so there's no cases where it looks good if a character can be partially behind tiles anyway. So having the divide between tiles ("ground") and stuff with real volume feels natural enough.
 
Top