drawing large objects

Started by
5 comments, last by EDI 19 years, 7 months ago
I'm trying to find a way to draw objects (isometric engine) which are larger than one tile properly. Like a wall object could be 1x5 tiles, or maybe a table that is 3x3 or something. I can't figure out a way to do it by drawing left-to-right, top-to-bottom. I found the thread that EDI had, but that goes diagnally from my understanding, and wouldn't that create some issues with certain types of sprites? help please :(
Sidra Headquarters
Game engine is currently at version 0.9.8! Currently Down
Advertisement
Hark, my name is called :-D

So, I assume that when you mean drawing from top to bottom, you mean that your are sorting all of your sprites by some y value, right?

if so, i "imagine" that there is a way for you to modify the Y reference of your table image for instance, to ensure that it is drawn properly, I could be wrong though. Also you may need to incorperate the X into your sorting weight as well.

The LORM rendering system, requires knowledge of what will be occluded as a result of drawing a large object (and ensures that it is drawn first), in a free-form system where objects are not associated with the tiles they are over makes that impossible.

depending on your system, you might be better off using your tiles as drawing cues for your objects.

As far as 'issues with certain types of sprites' the only issues we have found so far are concave sprites, that is sprites wherein the entire object is not a closed figure, but there are easy enough ways around that though art modification.

Unless you are using iso in some weird way *not keeping in concept with the 'rotated square' concept for your art* LORM should work fine, it only works with diagonal area displacements, and basicly works in concept like a square 2D map, except the actual graphics look iso.

Raymond Jacobs, Owner - Ethereal Darkness Interactive
www.EDIGames.com - EDIGamesCompany - @EDIGames

To illustrate my point,

As long as your large objects 'go with the grain' of the map, then it will work.



When you go against the grain, it isnt possible to specify a proper displacement in X,Y tiles to make lorm work right.

Since going against the grain rotates the reference system of X and Y, I will speculate that it might be possible to, also, rotate your map's reference system to work against the grain, and as such making lorm work, but I recomend you use the 'simpler' system.

Raymond Jacobs, Owner - Ethereal Darkness Interactive
www.EDIGames.com - EDIGamesCompany - @EDIGames

:D
everything is attatched to the tiles already. So, do you apply the algorithm to the entire map and then only draw what is seen (because it is possible for an object to have its anchor outside the screen but still be able to be seen)?

This would be my first isometric game, but not my first game. So there may be more questions on this in the future :D

BTW great job on your game!
Sidra Headquarters
Game engine is currently at version 0.9.8! Currently Down
our engine, (the Flare engine) draws a little past the screen border, so it usualy works fine for objects with anchors=D

the LORM proccess determines your draw order, it can be used on a map subsection, which is how we use it.


Thanks for the compliment=D

Raymond Jacobs, Owner - Ethereal Darkness Interactive
www.EDIGames.com - EDIGamesCompany - @EDIGames

A bit on the off topic side.. I used LORM until I decided I wanted to have large object stacked ontop of eachother. And I came up with this routine:



To accomplish this I must sort the scene prior to drawing it. Each box (tile) scans the area behind it, if he finds another object within the scaning area he sorts himself after them. So in the above case the orange box would scan the blue area behind him. He would find the grey boxes and sort himself after them. He wouldn't find the red boxes so those have no impact at this time.

Then when the red boxes are to be sorted they in turn scan their area and finds the orange box (and any other boxes that are inside their scan area) and then they sort themselfs after them.

The only problem I have found with this algorithm is when you have a scene with looping and overlaping objects (very rare), like this:



This wouldn't be possible to sort because you can't tell what object should be placed first and which should be placed last. You could ofcourse cut the objects in half and get away with it.. but that is cheating!! ;)
_____________________________
www.OddGames.comwww.OddGames.com/daniel
Impressive=)

Raymond Jacobs, Owner - Ethereal Darkness Interactive
www.EDIGames.com - EDIGamesCompany - @EDIGames

This topic is closed to new replies.

Advertisement