Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Drawable have depth value  (Read 5040 times)

0 Members and 1 Guest are viewing this topic.

Richy19

  • Full Member
  • ***
  • Posts: 190
    • View Profile
Drawable have depth value
« 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

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Drawable have depth value
« Reply #1 on: August 30, 2011, 08:42:04 pm »
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.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Drawable have depth value
« Reply #2 on: August 30, 2011, 08:51:16 pm »
Quote
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.

Quote
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.
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Drawable have depth value
« Reply #3 on: August 30, 2011, 09:00:22 pm »
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.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Drawable have depth value
« Reply #4 on: August 30, 2011, 09:05:35 pm »
Quote
Back to front

Quote
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.
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Drawable have depth value
« Reply #5 on: August 30, 2011, 09:21:49 pm »
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.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
Drawable have depth value
« Reply #6 on: August 30, 2011, 11:11:56 pm »
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.
Laurent Gomila - SFML developer

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Drawable have depth value
« Reply #7 on: August 30, 2011, 11:21:02 pm »
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).
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Richy19

  • Full Member
  • ***
  • Posts: 190
    • View Profile
Drawable have depth value
« Reply #8 on: September 13, 2011, 09:20:16 pm »
Sorry to bother about this again but  just wanted to know if there is any cance this will make it into SFML 2?

Groogy

  • Hero Member
  • *****
  • Posts: 1469
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
Drawable have depth value
« Reply #9 on: September 13, 2011, 09:32:59 pm »
Probably not but you can fork SFML on Github and add it yourself.
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Richy19

  • Full Member
  • ***
  • Posts: 190
    • View Profile
Drawable have depth value
« Reply #10 on: September 13, 2011, 10:07:38 pm »
Quote from: "Groogy"
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

 

anything