Vertices z-order and alpha blending

[Tarquiscani]

Hello everyone,
I'm making an isomethric 2d game. I'm trying to find the (performance-wise) better way to display the sprites ordered by a z-level.
The best I can do now is to sort a vector of sprites, before drawing them as an ordered sf::VertexArray.

I know that SFML is built upon OpenGL and that actually every primitive is rendered as a 3D flat polygon (excuse me if I don't use a technical terminology). So I was wandering if I could delegate the z-sorting to OpenGL passing directly the z of each sprite.

Then I found this old topic and this post:

Is there any reason for SFML not to include support for depth buffering? (ie does it alter performance?). Or is it simply based on another way of rendering or something like that.

There are three reasons (from most important to least):
- it doesn't work with semi-transparent entities
- it makes the API slightly more complex for little gain
- user can break SFML by disabling depth buffer

The bolded sentence has somewhat answered my initial question, but I'd like to have a confirmation, also because six years have passed since.

If I use directly OpenGL, bypassing SFML, there would be no way to improve the performance passing directly the z of each sprite. This is because, when doing a 3D rendering, the algorithm doesn't take transparency into account. Only the meshes are used for the hidden surface determination and not the texture. In this case the mesh would be the flat primitive (an sf::Quads for example). So, also by directly using OpenGL, likewise I would end up "manually" sorting the flat meshes, otherwise OpenGL can't deal with transparency of the texture.
Is it correct? Or there would be advanced techiques now to overcome the problem?

Thanks

[Laurent]

Yes, that answer from 6 years ago still applies.

Before diving into possibly complicated implementation details, did you properly benhmark your code and proved that z-sorting sprites on the CPU was actually a bottleneck? You know what is said about premature optimization...

[Tarquiscani]

Thanks, you hit the nail in the head 
I've not benchmarked yet because the game is in an early phase of development. But in the final game there will be something like 1.5 millions quads of vertices in the map (although they won't be all visible at the same time), and I think that the z-sorting could become a bottleneck, but I can't be sure until I touch it.

[Tarquiscani]

I’ve done a benchmark, and a brute depth ordering of 1.5 million sprites per frame it’s really too heavy. I see some tweaks to reduce CPU-usage but each one would bring to some limitations:
-I have a 100x150x50 tiles map. I could draw each floor separately and limit the sort toa single floor. But this would forbid sprites taller than a floor (if each floor is rendered over the previous one, the tallest sprites of the lower floor would be cut).
- I could also render only a small portion of the map around the player, but this would make impossible the use of the zoom out.
 
Moreover in each case I would still have a lot of cpu-side work that would steal resources from the real simulation, so I’d like to delegate as much as possible to the GPU.
Now, since I don’t know anything about OpenGL, I’d like to know if it’s actually possible to do this delegation without giving up the use of flat sprites. I’m only interested in alpha blending for full-transparent parts of the sprites, not for translucent parts.
If it were possible I’d be happy to deal with the lower layer and learn everything about it.

Thanks

EDIT:
I’ve found an answer to the question here. So if I use z-buffering I have to give up translucency (unless I sort the translucent objects) but I can easily keep full-transparency. I can’t figure out what this will entail in the future development, maybe translucency is very important in 2D graphics