next »

[ChevyRay]

Alright, I'm having a bit of an issue. I have no trouble with math, but I'm not educated in it, so I don't really know where to go from here.

I've got an isometric plain, and objects placed at different positions on it. Each object has an x, y, and z value. Right now, I'm using the y-value to calculate the drawing depth of the object...



So as you can see (from that lovely diagram) each object's depth is as so:

Ball A: -7
Ball B: -2
Block: -4

So they're drawn in order: Ball B, Block, Ball A. Easy peasy.


Ball C is my problem . Where it's at, its drawing position is ( x, y+z ), to give the illusion of a third dimension... but with the formula above, its drawing depth calculates out to -3... so in-game it would be drawn behind the block, when I want it to be drawn on top of the block.

I can't seem to figure out a comely method of accomplishing this

Using the y-value to determine drawing depth is useful for overhead-games, but when you throw in that extra "dimension", everything goes to hell. Anybody know how to get around this?

[increpare]

Ball C is my problem . Where it's at, its drawing position is ( x, y+z ), to give the illusion of a third dimension... but with the formula above, its drawing depth calculates out to -3... so in-game it would be drawn behind the block, when I want it to be drawn on top of the block.

I can't seem to figure out a comely method of accomplishing this

Using the y-value to determine drawing depth is useful for overhead-games, but when you throw in that extra "dimension", everything goes to hell. Anybody know how to get around this?

I don't know if I fully understand what the problem is. What happens wrong if you draw things back to front, then bottom to top?

[Skofo]

Oh crap, I remember having a solution for this a long time ago. Completely forgot it, but I know what you're saying. The ball "goes behind" the brick after going past its center point even though it's supposed to be "on" it.

Uhmm... you sure you have your bounding box thingies right?

I think my solution was to make the depth of the bricks the y value plus (or minus?) the individual bricks' z height, but I'm not sure.

Anyway, I can't continue to try to solve this mystery for tonight, because I'ma head to bed. Hit the sack. Get some Z's. Snooze. Bye! Hope you figure this out!

[ChevyRay]

@increpare:

I'm trying to work out how to do that.

Unfortunately the tool I'm using, Game Maker, handles the drawing order. I can just change the depth value, and the program itself draws it in order from there. Maybe I should have explained that.

If everything's on a 2d plain, I figured it should still all be able to be drawn with a single sweep, though. So everything will have a final depth value that determines where its drawn, I just wasn't sure how to go about calculating that.


EDIT: okay, I apologize for my EXTREME amateur-ness, but I'm learning. Would this work:

Each y-increment subtracts 100 from the drawing depth.
Each z-increment subtracts 1 from the drawing depth.

So for each y-step down, I have this buffer-zone which has room for 100 different objects to be drawn in specific order.

So something at xyz (10,10,5) would have a depth of -1005 and an object at (10,10,10) would have a depth of -1010 (and be drawn on top of the prior object).

Does that make ANY sense at all?

[Zaphos]

Yes, that looks right.

[ChevyRay]

Eh, I also found sort of a cheap way around it. I just have it drawn one depth layer on top of the highest object below it. So if it's behind, like Ball B, it'll just be drawn normally, but if it's over top, like Ball C, it uses the block's drawing depth -1.

I bet it'll come back to haunt me, though :D ahh, the trials and tribulations of being a non-programmer.

[Zaphos]

Was the other way not cheap?  Either way it's just storing an integer, and assuming a 32 bit integer, you have plenty of space for your gaps of 100, or even 1000, or 10000.

[ChevyRay]

Yeah, I just used 100. I'm not certain about the max heights yet.

Also, wheeee



In action.

[increpare]

ah!  looks good

[ChevyRay]

Well it works good :D but I don't think it looks good... YET. *rubs hands together*.

EDIT: I'm talkin' something more like this:

[increpare]

Well it works good :D but I don't think it looks good... YET. *rubs hands together*.

EDIT: I'm talkin' something more like this:

hmm.. the plain grass looks a bit boring and...not especially flat: it's like the platforms are emerging from a thick green mist.

[ChevyRay]

Yeah, that's probably because I made it in like 15 second :D

I'm just playin' around right now anyhow.

[Hajo]

In the past I tried the following, each solution has its own problems though:

1) Sort based on the ground level coordinates (Ball c has position x,y and height h - do sorting only based on x,y)
2) Sort by tiles first (back-to-front), then by screen-y coordinate within one tile.
3) Use layers, sort by layer first, then within each layer.

Real troubles start if you have things like walls/fences and want to move relatively big objects over tile borders without clipping artifacts.

[Farbs]

Whatever you do, stick to a single size and shape of block. I've seen some awful awful code try to handle the draw order of elongated blocks, and it had two exciting results:

1) Sorting the tiles took up most of the CPU for the game (!!!)
2) Some arrangements simply cannot be resolved. It's entirely possible to have a situation where you want A->B->C->A. This is seriously uncool.

[ChevyRay]

Yeah, for longer objects, I just break them up into "cubes" and have them drawn separately.

[BenH]

I didn't really think too much into it, but couldn't you just change it to:

depth = -y - z

That way the change in y from the z depth would be cancelled out for the depth sorting part

Ignore me if I'm talking rubbish

[___]

I didn't really think too much into it, but couldn't you just change it to:

depth = -y - z

That way the change in y from the z depth would be cancelled out for the depth sorting part

Ignore me if I'm talking rubbish

It's impossible to ignore you with that damn avatar of yours.

[BenH]

Take that Romeo

[Linus]

Generally, when you're working with multiple heights like this in a 2D environment, you want to sort the draw order per layer. So first you'd draw everything on layer 0, then layer 1, then... etc.
When you have objects spanning multiple height levels, you'll have more fun problems, one solution would be splitting it into several drawable thingamajickers each one layer high and then handling the draw order for those independently.
Either way, it has little to do with math, the draw order based on your y-coord should do fine for each layer.


Linus

[increpare]

Either way, it has little to do with math,

Actually, most of the stuff I'm working on at the moment involves a lot of things that resonate with this problem, trying to come up with a sorting order for high-dimensional sets of data.