Depth sorting - almost solved

Hey as a lot of you know I've been stuck on depth sorting for ages.

I've come up with some sorting events, that in my mind, make complete sense and SHOULD work.

However they don't seem to be working as planned. Here it is:

<img src="http://dl.dropbox.com/u/1289341/sorting.JPG">

Does anyone have any idea why this wouldn't work properly?

I ran a small test that, instead of using a for loop, I used a user controlled variable that was increased and decreased by pressing the up and down arrows and it worked perfectly. But when I'm using the loop it doesn't work

what is it that you're trying to accomplish?

Isometric/orthographic sorting with Z Height.

The loop 'scans' from the ground up and if the 'height' of the loop (the loop index) is between any objects that need to be sorted's height variables (lower edge and upper edge) it sorts any of the picked objects in ascending order of where their Y value (regardless of 'height') and brings them to the front in that order.

Now for debugging purposes I made it so it didn't use a loop but used a user control variable that i could raise or lower, just so i could monitor what's going on wherever the 'scanline' is at. I made the picked objects change tint to see what I was working with. When using this method, it actually sorted everything fine, but the loop method does not work so well.

p.s. this sorting method does however require that tall objects be split up but meh

Ah dam I think I realised why this doesn't work now. As soon as two overlapping objects of the same size are at different heights, the one who has the highest top edge variable will be put in front, even if it's Y co-ordinate is behind it due to the way I'm scanning it

False alarm by the looks of it... as these things usually are.

But I think I'm still pretty close and I'm going to explore some options once i figure them out

Hint: Try out the "For each object (ordered)" under system conditions.

For example, me & Zotged used this in our isometric game:

For each Blue ordered by Blue.Y -> Blue: Send to front

Should make things quite a bit simpler for you

Heheh I -am- using that

That works great if you don't use height, but I'm putting jumping and stuff in, and the sorting becomes a NIGHTMARE.

Imagine a 2D grid, slanted so it looks like a table. Top rows are behind, bottom rows forward. When you add objects, you can influence their Z-ordering by the position on this grid. You can change their elevation all you want, however their position on the grid remains the same. It should always be drawn in front of objects with higher grid position etc.

Let me just put it out there that i'm not making a 'strictly' isometric game, I'm going more for a pixel by pixel treatment rather than a tile by tile, it doesn't stick to the old diagonal layout that most of them have as I'm going for a more natural look. But really, the theory should be basically the same.

Mipey - can you go into further detail as to how you would go about such a thing? I do know how it -should- be drawn, i just can't for the life of me figure out -how- I will be able to do it

Oh, just use invisible sprites that you do actual movement and stuff with, then add 'visible' sprites to them and sort them based on the 'base' sprite's Y position. So when you change the height, you actually don't move the 'base' sprite, you move the 'visible' one up by height.

That should be the simplest way to go, I think.

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)

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.

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.

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

http://dl.dropbox.com/u/1289341/REALTEST.cap

(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

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.

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

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.