Z-order in a Top-down RPG
by Diogo Gomes · in Torque Game Builder · 11/06/2005 (11:57 am) · 5 replies
I have all the sprites in a Simset and every one of them is on the layer 1.
Basically i don't know how i should z order them using .setLayerDrawOrder() to make sure that those that are far below the y-axis go to the front and the other ones go to the back.
How should i keep a track of their z-order and move them foward and backward accordingly?
Basically i don't know how i should z order them using .setLayerDrawOrder() to make sure that those that are far below the y-axis go to the front and the other ones go to the back.
How should i keep a track of their z-order and move them foward and backward accordingly?
#2
I'll copy paste my algorithm psudo-code from another post on the subject. I am not a C++ or TorqueScript guy so good luck implementing this :)
----------------------------
From the "ISO Ideas..." thread
----------
Since each fxSceneObject2D has the ability to set it's draw order (via SceneGraph.setLayerDrawOrder(), this seems pretty trivial to write your own infrastructure to do this.
if you do it in torquescript maybe it wont work so well, but if you know C++ it should be pretty easy.
I personally dont know C++ that well, but here's how i'd do it in C# (which i can, using t2d.net)
Initial setup
1) Set all sprites in your isometric grid in the same layer.
2) setup your draw order, by pushing the sprites to the end of a double-linked list, starting with the front most iso grid and working your way back.
3) when that's done, feed the linked-list to the engine, top-down so everythign is setup in the right draw order (use setLayerDrawOrder(yourSprite,"BACK"))
when that is done, everything is in the right draw order.
movement
1) when something moves, find it's current position in your linked list,
2) find it's new home in your linked list (figuring out what grid it will move to is how you figure out it's new home)
3) determine the distance from the start position to the end position (steps 1 and 2) and move your sprite that distance in your linked list to put it in the new position.
4) then use the "FORWARD" or "BACKWARD" Torque command for setLayerDrawOrder() to move yourSprite by the distance determined in step 3.
seems pretty straight forward to me. object additions can be handled by putting the object in back of the list/grid as it's initial position and then performing the steps in my "movement" section above.
deletions are easy.. just the usual double-linked-list delete.
lookups are easy too, each object can also be referenced in a list for each grid. and each grid can be in a hashtable.
11/06/2005 (2:18 pm)
@Diogo: you say "top down rpg" but what you are describing sounds like isometric view.I'll copy paste my algorithm psudo-code from another post on the subject. I am not a C++ or TorqueScript guy so good luck implementing this :)
----------------------------
From the "ISO Ideas..." thread
----------
Since each fxSceneObject2D has the ability to set it's draw order (via SceneGraph.setLayerDrawOrder(), this seems pretty trivial to write your own infrastructure to do this.
if you do it in torquescript maybe it wont work so well, but if you know C++ it should be pretty easy.
I personally dont know C++ that well, but here's how i'd do it in C# (which i can, using t2d.net)
Initial setup
1) Set all sprites in your isometric grid in the same layer.
2) setup your draw order, by pushing the sprites to the end of a double-linked list, starting with the front most iso grid and working your way back.
3) when that's done, feed the linked-list to the engine, top-down so everythign is setup in the right draw order (use setLayerDrawOrder(yourSprite,"BACK"))
when that is done, everything is in the right draw order.
movement
1) when something moves, find it's current position in your linked list,
2) find it's new home in your linked list (figuring out what grid it will move to is how you figure out it's new home)
3) determine the distance from the start position to the end position (steps 1 and 2) and move your sprite that distance in your linked list to put it in the new position.
4) then use the "FORWARD" or "BACKWARD" Torque command for setLayerDrawOrder() to move yourSprite by the distance determined in step 3.
seems pretty straight forward to me. object additions can be handled by putting the object in back of the list/grid as it's initial position and then performing the steps in my "movement" section above.
deletions are easy.. just the usual double-linked-list delete.
lookups are easy too, each object can also be referenced in a list for each grid. and each grid can be in a hashtable.
#3
Now that i think about it, yeah, Z-order for ISO is the same for Top-down.
Anyways, since im using torquescript to make this i can't use linked lists i will try with arrays.
I will try to implement this and post the results later. Thanks!
11/06/2005 (3:07 pm)
@Jason:Now that i think about it, yeah, Z-order for ISO is the same for Top-down.
Anyways, since im using torquescript to make this i can't use linked lists i will try with arrays.
I will try to implement this and post the results later. Thanks!
#4
I worked on that problem for a while, trying to get characters to cross in front and behind. The problem I kept running into was that changing graphics and animations would cause little lines between the feet and torsos, especially when resizing the sprite.
What I ended up doing was creating a character class that would have two collisions areas. One would be the collision box to prevent movement, built right on the character sprite image. The second collision was a basic fxSceneObject2D with a collision material and no graphics. I used that to use the collision callback to sort out layers if it collided with another character.
That all used the Z-Order, and seemed to work fairly well. It may not be the best solution for everyone, but it worked for me.
11/09/2005 (4:33 pm)
@Ricky Taylor:I worked on that problem for a while, trying to get characters to cross in front and behind. The problem I kept running into was that changing graphics and animations would cause little lines between the feet and torsos, especially when resizing the sprite.
What I ended up doing was creating a character class that would have two collisions areas. One would be the collision box to prevent movement, built right on the character sprite image. The second collision was a basic fxSceneObject2D with a collision material and no graphics. I used that to use the collision callback to sort out layers if it collided with another character.
That all used the Z-Order, and seemed to work fairly well. It may not be the best solution for everyone, but it worked for me.
#5
I thought of doing that but i feared that it would hit the performance badly.
11/10/2005 (4:49 am)
@Daniel Stirk:I thought of doing that but i feared that it would hit the performance badly.
Torque Owner Ricky Taylor
Ricky,