Jump to content
  • Advertisement
Sign in to follow this  
Habba

Drawing order in tile-based isometric game

This topic is 4810 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm involved in somewhat insanely large project, to create an isometric RPG engine. It's tile-based and drawn with DirectDraw7 (= DirectDraw in DX7). Now I've encountered a problem. As you know, I have to sort images in correct order before I blit them, to create illusion of 3D. I've done this by calculating a variable, called "RenderPoint" for each object to be drawn. It's calculated by adding it's coordinates together. So practically it's the same as the Y coordinate on the screen. After that objects are sorted by their "RenderPoint" value, in ascending order. Lowest renderpoints are drawn first, and thus are most likely to be overlapped by others. This thing worked quite well until someone said: "We need objects bigger than one tile". Well, I first though that we could just split images half and put to halves in adjecent tiles, creating illusion of one big object. Project's artist strongly disagreed and said "Large objects must be on singular image. I'm not going to start splitting these". Now, I've tried drawing large objects, but those **** things are not cooperative! I'm having problems with drawing order with objects that are not square-based (1 x 5 objects for an example). I'll try to demonstrate my problem here.. (I hope my Code-tags works...)
 
. = empty tile
O = object
i = item

 . . . . . .
. . . . . . 
 . . . . O .
. . . . O . 
 . . i O i .
. . . O . .
 . . O . . .
. . . . . .
Now, both items (i) have same RenderPoint, but item on left should be drawn before and the right one after the large object (O, think of it as a long table) is drawn. However, if the table would be from top left to bottom right, the whole drawing sequence should be reversed. I hope that some one understood my problem and could help me. So is there any way to use large (larger than 1 x 1) objects in tile-based isometric games, without slicing larger images into smaller ones.

Share this post


Link to post
Share on other sites
Advertisement
http://koti.mbnet.fi/oalatalo/DrawingOrder.png

Here's a small picture. I hope it helps you to understand the idea of what I'm trying to tell you here.

Share this post


Link to post
Share on other sites
Quote:
Original post by Leo_E_49
Why not simply create a z-value for each tile and sort by z-order before rendering?


The problem is not the tiles, but the objects placed on the tiles and, in this case, the objects all have the same z-order.

The only way to achieve what you are after is to go with ISO 3D.

Share this post


Link to post
Share on other sites
So given this problem, there *is* a correct sorting order that will make it work. The problem is coming up with a good comparison function that can sort the objects.

Can you explain in a little more detail how you do the compare right now? You said you add up the coordinates, what do you mean exactly with that? (just making sure it's what I think it is)

Additional Question: Does the table have a single RenderPoint or a collection?

Share this post


Link to post
Share on other sites
Hi,

Why not preprocess the sprites and split them, through code, and give them a proper "RenderPoint", which would be an offset from their actual position? We did tools similar to that for a few titles at the first games company I worked for, and it saved our artists a LOT of time (basically, it was splitting textures in max 256x256 to support old voodoo cards, then merging them using different quads).

Its always rewarding (and sometimes artists like to participate to this process) to create tools to manage and preprocess data. Once you've got your tools pipeline, your job is easier, their job is easier, and the final product benefits of a better quality because time has been spent on details else than doing a mechanical job, such as splitting images in pieces.

Sorry for my English, I hope this was understandable

Eric

Share this post


Link to post
Share on other sites
Quote:
Original post by Gluc0se
Can you explain in a little more detail how you do the compare right now? You said you add up the coordinates, what do you mean exactly with that? (just making sure it's what I think it is)

Additional Question: Does the table have a single RenderPoint or a collection?


RenderPoint = (TileX + TileY) * 128 + smallX + smallY

TileX = Tile's X coordinate
TileY = Tile's Y coordinate
smallX = Tile's interior X coordinate
smallY = Tile's interior Y coordinate

So basically objects are drawn based on their parent tile. If there's several objects in a same tile, interior coordinate affects.

So, in other words. The lower the object is in the screen, the later it gets drawn. This works perfectly with 1x1 objects.

Each object (table is an object) has a single RenderPoint, as it is a single object.

Quote:
Original post by Gluc0se
Why not preprocess the sprites and split them, through code, and give them a proper "RenderPoint", which would be an offset from their actual position?


Well, that seems to be the only choice left now...

Thank you all for your time, I'm grateful. If you have any more ideas, I'm all open for suggestions.

Share this post


Link to post
Share on other sites
The easiest solution is definitely to split them up. You can automatically split a n*m object into n+m vertical stripes of width = tile-diameter / 2:

---------------------
| | | X | |
| | | /|\ | |
| | | / | \ | |
| | |/ | \| |
| | X | X |
| | /|\ | /|\ |
| | / | \ | / | \ |
| |/ | \|/ | \|
| X | X | X
| /|\ | /|\ | /|
| / | \ | / | \ | / |
|/ | \|/ | \|/ |
X | X | X |
|\ | /|\ | /| |
| \ | / | \ | / | |
| \|/ | \|/ | |
| X | X | |
| |\ | /| | |
| | \ | / | | |
| | \|/ | | |
| | X | | |
| | | | | |
| | | | | X
| | | | | /|
| | | | | / |
| | | | |/ |
X | | | X |
|\ | | | /| |
| \ | | | / | |
| \| | |/ | |
| X | X | |
| |\ | /| | |
| | \ | / | | |
| | \|/ | | |
| | X | | |
---------------------

Sort these as usual based on their smallest Y coordinate.

Solution without splitting:
-record for each object a line from its leftmost point to its rightmost point:

. X X .
. / \ / \ .
| / \ / \ |
| / \ / \|
| X X __--O
| / \ /__-- /
| / \__--- \ /
|/ __--\ / \ /
O-- X X
\ / \ /
\ / \ /
\ / \ /
X . X
\ . /
\ | /
\|/
X


-Foreach object with line (x0,y0)-(x1,y1), store all objects with lines in the range x0-x1 and lower y values in a list.
-Breadth-first traverse the resulting DAG.

Share this post


Link to post
Share on other sites
I was thinking about the same problem a while ago, and one thing that came to my mind was drawing the tiles diagonally (the numbers show the drawing order):

0  1  3  6  10
2 4 7 11 14
5 8 12 15 17
9 13 16 18 19

I do not remember if there was something wrong with this approach - other than that this system is only able to draw large diagonal objects, horizontal non-square objects must be splitted.

Share this post


Link to post
Share on other sites
I don't understand why you would want the table drawn before the item i on the right. I would draw both items then the table. Every object should have a RenderPoint and it should be the bottom of the object, probably bottom center.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!