A peculiar layering problem (isometric)

ID:265143
 
Jul 15 2002, 7:57 am
I'm working ou tthe initial designs for my next game, which will be more of an action, and I've decided to go with isometric because it will have a better look.

But I have a problem. Because I'm going isometric, it's now possible for a layering situation to occur like this:
      /
   / /     <-- Back
  / /   /
 / /   /
/     /
     /     <-- Front

This means that I can't accurately choose a layer for my sprites. (NOTE: The items above don't represent one object split over 4 tiles each, but an object slightly smaller than 2 tiles. Each will have different pixel offsets.)

Now, the sprites are going to be about 64x64 (the tiles will be 64x32 but I'm accounting for height), so it would be possible to give each a different layer, but this isn't necessarily the right solution, because the pixel offsets mean that overlaps can happen beyond the standard 32x32 tile boundary.

Basically this works out to a Z-buffering issue with flat sprites. They're representing objects that can be turned in different orientations, so an object whose center is behind another object's can still appear in front of it. This isn't so much of a problem when just two objects are involved, but as you can see from the figure above, when more than two get in on the act, it can be a big deal. (Actually the figure above is an easily resolved case, but that's beside the point.) Conceivably you could get a chain of objects going; it could even get into a worst-case circle.

Matters are worse when you consider the turf tiles underneath--or obstructions in front.

The only solution I can possibly think of is to give sprites layers that vary with the x coordinate of the icon, but that's kind of ridiculous--I think. It'd require a revamp of the BYOND drawing engine, which is something I wouldn't even suggest unless isometric were to become a much bigger deal in the future.

Does anyone have any thoughts or helpful suggestions on this?

Lummox JR
Jul 16 2002, 10:20 am
The only solution I can possibly think of is to give sprites layers that vary with the x coordinate of the icon, but that's kind of ridiculous--I think. It'd require a revamp of the BYOND drawing engine, which is something I wouldn't even suggest unless isometric were to become a much bigger deal in the future.

My apologies in advance, because I didn't understand a whole lot of your post -- but why is it ridiculous to have layers vary with the x coordinate (or for that matter, the y coordinate) of the icon? Couldn't you just do something like this:

mob/Move()
. = ..()
if(.)
layer = MOB_LAYER + (y / 100) + (x / 10000)

...or something like that. I think we actually do something along those lines with Living and Dead, but I don't know for sure -- I remember discussing it with Deadron at one point, but I don't know how he finally implemented it.


Jul 16 2002, 10:34 am
In response to Gughunter
Gughunter wrote:
The only solution I can possibly think of is to give sprites layers that vary with the x coordinate of the icon, but that's kind of ridiculous--I think. It'd require a revamp of the BYOND drawing engine, which is something I wouldn't even suggest unless isometric were to become a much bigger deal in the future.

My apologies in advance, because I didn't understand a whole lot of your post -- but why is it ridiculous to have layers vary with the x coordinate (or for that matter, the y coordinate) of the icon? Couldn't you just do something like this:

mob/Move()
. = ..()
if(.)
layer = MOB_LAYER + (y / 100) + (x / 10000)

...or something like that. I think we actually do something along those lines with Living and Dead, but I don't know for sure -- I remember discussing it with Deadron at one point, but I don't know how he finally implemented it.

What I meant is the x coordinate within the icon; that is, having an icon whose layer is some kind of plane function:
L = A*x + B*y + C

That is, a simple numeric layer won't do because of the way sprites may overlap.

Lummox JR
Jul 16 2002, 1:58 pm
In response to Lummox JR
What I meant is the x coordinate within the icon; that is, having an icon whose layer is some kind of plane function:

Ahh, the pixels on the left side of the icon would have a different layer than those on the right. Gotcha.

Nope, can't help you there!
Jul 16 2002, 2:47 pm
In response to Gughunter
Make each side a seperate object. That's the only way.
Jul 16 2002, 3:11 pm
In response to Garthor
Garthor wrote:
Make each side a seperate object. That's the only way.

That would tedious to do because he needs it vary for each x position. So he would have 32 icon states for one icon. This could be simplified, however, to be done through code if a couple procs were created.
<code> icon.copy(x1,y1,x2,y2) icon.paste(icon,x1,y1) obj/New() var/icon/i = new(icon) for(var/x = 1 to 32) var/icon/part = i.copy(x,1,x,32) var/icon/new = new() part.paste(new,x,1) var/obj/o = new() o.layer = x overlays += o icon = null return ..() </code>

That seems like a pain in the ass on loading time though. But after this was done, maybe the icons could be saved into a better format so they don't have to be created like that every time?
Jul 17 2002, 4:13 am
In response to Ebonshadow
Ebonshadow wrote:
Garthor wrote:
Make each side a seperate object. That's the only way.

That would tedious to do because he needs it vary for each x position. So he would have 32 icon states for one icon. This could be simplified, however, to be done through code if a couple procs were created.

Yep, that's the basic problem. I can't just take the 2+ different icons for the sprite and give them different layers, because the overlap could happen over both of them.

<code>icon.copy(x1,y1,x2,y2) icon.paste(icon,x1,y1) obj/New() var/icon/i = new(icon) for(var/x = 1 to 32) var/icon/part = i.copy(x,1,x,32) var/icon/new = new() part.paste(new,x,1) var/obj/o = new() o.layer = x overlays += o icon = null return ..()</code>
That seems like a pain in the ass on loading time though. But after this was done, maybe the icons could be saved into a better format so they don't have to be created like that every time?

Well, here's the problem: Each icon is actually part of a 2- to 4-icon sprite sitting in 64x32 isometric space. If I even split each icon into 31 left-right pairs and a solid, that's 63 icons--making up to 252 per sprite. The icons certainly couldn't be built on the fly, though, from vertical strips.

This is way too memory-intensive and CPU-intensive, and would never do for an action game. Even if the icons are calculated in advance and cached, there'd be that many more objects to show on screen.

Lummox JR