Depth buffer and slanted sprites?

[raidho36]

Try generating atlases dynamically out of individual sprites. Use a canvas to store the atlas, some unpacking algorithm to reduce fragmentation. Sorting the sprites reveals in which order they will be drawn, so you would know exactly which sprites should be grouped together on an atlas. With enough tweaking, all or most of the atlas would be kept between frames, and changes to atlas wouldn't be as great as to rebuild the entire thing (which even then is not as big of a problem as to render the actual scene).

[SPlice]

If you run into too much trouble, try implementing a merge sort, I was able to use this method to have thousands of objects on the screen with z sorting (possibly as high as 10k). Just make sure you cull your list down to only the things that need to be on screen at any given time.

[Nelvin]

That's not going to work in my case, as I've written, it's an isometric game and there's no such thing as a simple single Z value you can correctly sort your objects with. Also it's not the sorting that's an issue, it's having dozens of 2k x 2k atlases with no defined sort order.

Also, missed to reply to radiho36, dynamically creating the atlas would not work either due to this case. Sorting the sprites reveals the order in the frame they've been drawn, next frame is different as different animation frames from different buildings/objects will be drawn, characters have moved to other positions causing them to be rendered at a different time, also with a different animation frame. Last but not least, some frames will be used many times during the rendering, some others only once - for this to work even in static scenes it would require to dupliate some sprites, and not some others etc.

One fallback solution I have, is to test if textures bigger than 2k x 2k are supported on a system and then just combine the most used textures in to 4x4 or even 8k x 8k textures dynamically. But I fear that's more or less an optimization primarily for hardware that can handle thousands of drawcalls per frame and the overdraw easily.

[raidho36]

Well, Z-buffer too has exactly one simple Z value used for "sorting". If it doesn't work with actual sorting, it wouldn't work with depth test either.

Also, "doesn't work" and "I assume it wouldn't work" are two very different things.

[Nelvin]

Not sure what you mean with I assume - it's really no new finding that you can't sort iso objects by a single depth value (that's derived from the objects size/position) - if you never had this problem, you've never implemented an iso engine with variable sized objects and you're the one assuming.

But it's also nothing I ever asked for, as already written, I have implemented the sorting and want to optimize the rendering.
Given a correct sort order it's of course easy to assign a single Z value per object to get the correct visual results independent of the order of the actual draw commands. And this, in turn, allows to optimize for batching instead of having to draw each sprite in the correct order of appearance.