SFML community forums
General => Feature requests => Topic started by: Richy19 on August 30, 2011, 05:41:05 pm
-
Allow any drawable class to have a depth value that way you only need to change 1 value to change what order to draw stuff, instead of having to change the order of all elements
-
He does have a point and I think the hardware depth buffer is a lot faster than everything we got. If done right then it will also help to make it simpler. Plus it will allow the more advanced users to render front to back to optimize razteration.
-
He does have a point and I think the hardware depth buffer is a lot faster than everything we got
It's not faster than what we have now -- rendering back to front. But of course it's faster than sorting an array of drawables every frame, if one can't draw them directly in the right order.
Plus it will allow the more advanced users to render front to back to optimize razteration
Isn't it what all SFML users do already?
I'm not convinced by this feature, I guess I need use cases that would really benefit from it.
-
Currently sfml users have to render back to front. Furtherst object first and nearest läst. Back to front.
Front to back and a z buffer lets the GPU ignore pixels which already have a color.
Damn phone. Last not läst.
-
Back to front
Front to back
I answered too quickly and I kind of mixed everything, sorry.
You're right, back to front (the current method) is not optimal because a pixel may be overwritten many times, while front to back would allow hidden pixels to be ignored by the pixel rasterizer :)
But I wouldn't expect the overdraw factor (average number of times a pixel is written) to be that high for 2D rendering, this kind of optimization is much more interesting for 3D scenes that may have lots of hidden objects, depending on the camera position. I think it's negligible in 2D games.
-
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.
-
In fact the bottleneck in SFML is the number of OpenGL calls -- which is purely a CPU issue. The new drawing classes will solve that, and then I sincerely hope that all performances problems go away in SFML 2. Other bottlenecks are far, far away and hopefully they'll never be reached with 2D games that will never have millions of primitives like what today's 3D games use.
So my opinion is that a Z component would be worth implementing if it made programers' life easier, but not for performance reasons.
-
Well then it would be that they can render things with random access but still have it appear with correct order.
Last thing but not really 2D... It would make it possible to create custom 3D drawables and it would be extremely useful if you have 3D and want to render a opaque GUI over(Back to optimization but where it counts :P).
-
Sorry to bother about this again but just wanted to know if there is any cance this will make it into SFML 2?
-
Probably not but you can fork SFML on Github and add it yourself.
-
Probably not but you can fork SFML on Github and add it yourself.
I wouldnt know how or else I would add it to 1.6