Well remember this is optimization for the GPU not the CPU. We can have smaller tiles than 32x32 for various gameplay reasons, I for instance want 16x16 in my game. Already big tiles give performance issues. If we can ignore 50% of the tiled pixels the GPU can almost go on vacation =)
Also if we add a particle system over this the count goes up!
That is the case if, the razterisation of several smaller quads is the bottleneck of course.
On my computer now so can give a detailed example for how this could be taken advantage of if implemented.
Layers, they are pretty common and can exploit this because they can be easily chained together in what order to be drawn and don't need to but can internally sort their sprites. So each layer gets it's own Z value depending on what order we want it to be drawn. Sort the layers depending on the Z value(which should be a minimal amount and only needs to be done once) and then render them. So if the highest/lowest(depending on if we are looking down positive or negative Z) is the tile layer. A huge chunk of that layer will be ignored and together with the upcoming batch draw, this is perfect making drawing tiles really trivial.
I am not experienced with shaders but I guess if you were bad at it or made an advanced enough pixel shader it might have been enjoying those extra pixels ignored?
Enough for you at least testing it? :twisted:
DISCLAIMER: I learned this stuff yesterday when we were introduced to the 3D rendering pipe-line at school.
Also after talking to another SFML user who is an old school mate I realized that this will force users to render transparent images back to front as a special case. So unless you handle something internally or I donno OpenGL has something for this I think we can just ignore having a z value on drawables all together. Because if we do add it... "Simple" will have to be removed from SFML.
A thing you can do is let us add a "true" flag to enable depth buffer for window( like in render texture ) and then have Set/Get Z on Drawable which is only used by SFML if z buffer for the render target is enabled. The Z value should still be in drawable and usable because someone might want to use it in the application for something, just that SFML/OpenGL itself ignores it.
The much inferior HGE library provides this. Though it allows only a z value between 1.0 and 0.0 which is annoying.
