Depth sorting - almost solved

For questions about using Classic.

Post » Thu Jan 14, 2010 1:01 pm

That's what I'm doing.
I use invisible sprites to represent where the object is on the ground for collisions and stuff and then associate a graphical sprite to that and put it at whatever height it's supposed to be.
That's not really the problem I'm having, the problem is i can't SORT the graphical sprites in realtime in a way that allows for vertical movement (general player movement, tunnels, jumping, elevators etc)
B
3
S
2
G
5
Posts: 351
Reputation: 2,377

Post » Thu Jan 14, 2010 1:47 pm

You can compare the graphical sprites' elevations and draw whichever is higher in front. Basically you go through all invisible sprites that occupy the same position (player, elevator, clouds) and then sort them based on elevation.
B
62
S
21
G
12
Posts: 1,910
Reputation: 13,155

Post » Thu Jan 14, 2010 5:48 pm

yeah you're doing exactly what I am.

We're probably having the same issues, you can see my results in the 2.5d movement thread, there's an exe.
2.5d mov. is essentially iso platforming, done per pixel, which seems to be exactly what you're doing too. Can you post a .cap or an .exe to see your results?

My current line of thought is that there needs to be some fixed relationship between height and depth or it will never sort correctly. Like... a cube size. Which is a bummer, because doing tall or long moving objects that collide becomes a hassle.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Thu Jan 14, 2010 8:44 pm

Here's a link to where I'm at currently

[url:8t8n1azu]http://dl.dropbox.com/u/1289341/REALTEST.cap[/url:8t8n1azu]
(sorry its not commented! If something is confusing lemme know and I'll explain)

It's not using the latest version of construct and Deadeye said something along the lines of clicking on every physics object or something to get it working (I'm using the physics for realistic collisions)
I'm thinking we are indeed stuck on the same thing.
And yeah, I'm -trying- to make it so long/tall ojects are accomodated for, but if I have to split objects up to get it working i will lol

@Mipey - I've been trying believe me haha, it's a lot easier said than done! I can only seem to sort it either by Y coordinate OR height, I can't seem to do both :(
B
3
S
2
G
5
Posts: 351
Reputation: 2,377

Post » Thu Jan 14, 2010 9:02 pm

[quote="Madster":me9n2yb8]My current line of thought is that there needs to be some fixed relationship between height and depth or it will never sort correctly. Like... a cube size.[/quote:me9n2yb8]

[quote="Arcticus":me9n2yb8]And yeah, I'm -trying- to make it so long/tall ojects are accomodated for, but if I have to split objects up to get it working i will lol[/quote:me9n2yb8]

I'm thinking that you will probably have to split objects into uniform sized pieces. This may be why isometric games use tiles that are all the same size instead of having some large and some small.
Moderator
B
5
S
2
G
6
Posts: 4,348
Reputation: 10,971

Post » Fri Jan 15, 2010 3:25 am

[quote="deadeye":3lie6igq]I'm thinking that you will probably have to split objects into uniform sized pieces. This may be why isometric games use tiles that are all the same size instead of having some large and some small.[/quote:3lie6igq]
I've read this plainly stated in some documents regarding classic isometric games =(

Also, I just got the reasoning why Y-sorting could never possibly work with different heights.

Imagine an iso box stacked on top of another iso box, correctly sorted so that the one above is drawn on top of the other one.
Now imagine the box on top going down. It's not moving on Y, only on W (or Z or whatever). As soon as it goes below the other box, since Y has not changed, it will be incorrectly sorted, drawn above the box that sits on top of it.

SO you have GOT to involve height in the equation. I'm still on that. I just know now that Y-sorting only works for level objects.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Fri Jan 15, 2010 3:46 am

Yeah without the 'Z' axis, sorting is cake. It just goes to the whole other side of the difficulty spectrum when you wanna add the 'Z' :(
You may have noticed, with height, I found it a lot easier to have one variable for the 'bottom' edge and another for the 'top' edge of the sprite just to make comparisions one hell of a lot easier. Plus you can use them to tell if something is standing on top of something else etc. I STILL can't however work out an equation that takes into account the actualy Y axis and the two Height variables that sorts them. That picture at the start of this thread was the only one I've thought of so far that had all three elements, if only it wasn't wrong...
Double sad, I need more brains.
B
3
S
2
G
5
Posts: 351
Reputation: 2,377

Post » Fri Jan 15, 2010 5:01 am

i opened this bitchy ass can of worms when i started work on my own iso game. its a real freaking pain.

the only difficulty is getting sprites occupying the same space on the ground level, to sort correctly based on height. if one block exists things will go fine. if two exist, you can hack it so that any above thelower sprite go ontop, but if you add a whole bunch, it just starts getting too complex. y sorting works for objects when they dont share a space/dont cover up eachother. im probably just gonna hack it. yuck.
B
52
S
7
G
6
Posts: 1,945
Reputation: 7,610

Post » Sun Jan 17, 2010 1:23 am

I guess it's okay for sorting not working when objects are overlapping in 3D space, but when they're not there is no reason it shouldn't work.

I tried using the distance to a camera at 45 (seeing as currently I'm displacing by Y = RY-W) but it didn't work. Then I realised my reference point is the farthest bottom point of every object, so that was probably a bad reference. I'll try again soon using the top of the object (I'll try both) and see what happens.


Edit: I see now my previous calculation was distance to the origin, which is totally wrong. I'll see what goes on now.
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

Post » Sun Jan 17, 2010 1:47 am

Seems that sorting by the edge of the virtual "box" closest to the viewer did the trick. Although if you go over the Y axis (in Construct located at the top of the layout) things will probably get inverted. So don't.

I present a stacked objects test case, working perfectly. The objects do clip when near the farthest edge of the object they're standing on, but it seems to be slight. Slopes clip horribly though, surely because slops are not accounted for at all in the sorting (yet). Horizontally sloped "walls" don't sort correctly either and never will, as there's no 3D info on such surfaces. Special sprites may be needed for such kind of thing.

Try this: [url:3f1kt10t]http://octavoarte.cl/25d_concept.exe[/url:3f1kt10t]
B
3
S
2
G
4
Posts: 1,445
Reputation: 4,665

PreviousNext

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 3 guests