My solution to the overlapping issue in isometric worlds.

[Solstice Project]

Yay, a response.

Well ... i don't really see what you mean. GroundSizeY ranges from top to bottom for every Y.
If it's one more or not doesn't really matter to me. Personally, in my arrays i like to have one additional one,
just to be safe. It's not exact, but it's not really relevant in most cases.

Well ... you think there's nothing wrong with sorting and that's okay, but i don't see a need for wasting time with it,
when there's a much faster way that's also really easy to set up.
I tend to trade pages for cycles ... and that's the outcome of it.

I don't really understand what you mean. It's not irrelevant if a person can or can not see a difference.
Small parts of a code can have a big impact on runtime performance and that's relevant. I understand that nowadays most people
don't care about their slow code, but that's not something i am happy with.


I understand that you think that you need to do that, but you don't. With my approach, no additional sorting at all is needed.

Why would you want to go through the list and compare Z order, when the Z order is obviously there already ?

You render back to front and go from the top to the bottom of the Order-List.

You don't need to stick to tiles, btw. You can add anything to the list.
My "humans" are in it too. I use it for everything on screen, obviously,
because it's so straight forward and easy.

[User137]

I only gave solution which would work smooth 60+ fps even if your map is like 10000 x 10000 tiles, and 10000 dynamic game objects in it, with a low spec computer. All the while using very little memory. Can you say the list works as well? The point of new algorithms is often to improve on something that exists before. That said, i don't completely understand how your code works.

[SilverWarior]

Small parts of a code can have a big impact on runtime performance and that's relevant. I understand that nowadays most people
don't care about their slow code, but that's not something i am happy with.

Most pepole nowadays don't care about their slow code becouse they don't have to. Why? Becouse nowadays computers are so powerfull.
But more and more game and aplication developers are starting to care about their slow code becouse the mobile devices doesn't offer so much processing power and therefore require more optimized code.

As for your example I'm afraid that like User137 I don't exactly understand how it works. That is why I havent posted any coments so far.


But as for general improvment of Isometric map drawing:
The best aproach on speeding it up is to split your map into mulltiple sections (chunks) and then processing only seperate chunks instead of whole map.
This gives you hte ability to have practically endess sized map without much of performance slowdowns.
So in the end you could still use slow tile sorting approach becouse it won't be such a big problem as you will use this approach only on smaller part of the map and not the whole map.