The whole process gets easier and also (theoretically) faster.Depends on what you consider "easier". Sure for people who understand how the depth buffer works, they just specify an extra coordinate and thats it. But for beginners in graphics programming, who Laurent holds so dear, the "painter's algorithm" way of doing things is more intuitive and hence easier to learn. If this becomes a feature then at least make it optional and off by default, so that the learning curve doesn't become too horrible.
1. Provide something like sf::isDepthBufferAvailable() or something similar to how you check for shader support.It will be like sf::RenderTexture: the (crappy Intel) driver says it can handle it, but you just see garbage on your screen ;)
2. If the depth buffer is disabled in the sf::ContextSettings, just don't enable depth testing. Nothing will happen with the third coordinate then, if you are using an orthographic projection.That's what I'd like to avoid. By changing an indirect property, which is normally only for your own OpenGL rendering, you disable a major feature of SFML.
Your conception of the depth buffer precision is also not correct.I know Z values are not mapped uniformly, but with 8 bits the number of available Z values will be ridiculously low anyway, regardless how they are mapped to those 8 bits (ok, I shouldn't have said "256").
3. Provide a "copy constructor" that initializes an sf::Vector3 from an sf::Vector2 and sets the z coordinate to 0.I don't like this kind of implicit conversions. And making it explicit won't be less verbose than the regular constructor.
4. Like I said in my previous post, make it optional so that the people who have a clue what they are doing can solve this problem on their own. If you want to use the depth buffer, you will have to make semantic changes to your application to deal with this problem and it isn't the responsibility of SFML to make sure the values that are specified are sane. Garbage In Garbage Out.I'd like to make depth testing optional, but implicitly: assign a depth value or leave the default one if you don't care. Any solution that makes activation of depth testing explicit is already too bloated.
5. Same argument as 4. People have to give it a bit more thought instead of just doing sf::enableDepth( true ) and expecting the application to behave like what they had in mind instantly from the beginning.This is not my philosophy. I'd like things to work out of the box, in all cases, and as expected as soon as you activate them. If users need to figure out a specific context with certain conditions to have it working as expected, it's already too complicated. Especially for this feature, which is really basic and simple (as opposed to shaders, for example).
This is not my philosophy. I'd like things to work out of the box, in all cases, and as expected as soon as you activate them. If users need to figure out a specific context with certain conditions to have it working as expected, it's already too complicated. Especially for this feature, which is really basic and simple (as opposed to shaders, for example).Well, good luck then. Depth testing wasn't around from the start of computer graphics and can be considered an "advanced" technique. That being said, I don't see any way to provide transparent support for depth testing without jumping through loops.
SFML would just be FML if I just implemented a thin wrapper on top of OpenGL without dealing with the annoying rendering issues.
Your experience confirms that enabling depth testing in SFML is probably not a good idea. It feels like it will cause more problems than it solves.I really don't agree with that. I'm doing a really simple game and already have to think about using a custom OpenGL renderer instead of SFML's graphics module because there's no easy way to do my z ordering. As long as I'm in control of everything I can implement my own, but when using external libraries (like Thor's particle system), I'm at a dead end.
Although, I suppose I could just call the render function for whatever external library wherever I want, so maybe it isn't such an issue.If particles stay in one specific layer, then it's not a problem. But just imagine smoke particles that go up in a top-down game. They might start below other objects, but after some time occlude them due to moving up.
QuoteAlthough, I suppose I could just call the render function for whatever external library wherever I want, so maybe it isn't such an issue.If particles stay in one specific layer, then it's not a problem. But just imagine smoke particles that go up in a top-down game. They might start below other objects, but after some time occlude them due to moving up.
Or the problem I currently face: You look along the z axis and simulate sprite depth by scaling them. Sprites need to be ordered so they occlude what's behind them, and the same applies to particles: If an object explodes at z=10, the explosion effect particles have to occlude stuff with z<10 and be occluded by objects with z>10.
It's impossible to do except you implement your own particle system that does z ordering. Considering that Thor already provides a nice particle system, I find it an unacceptable solution (rather a workaround for something that should probably be supported out of the box, because the underlying graphics backend supports it).
In my opinion SFML has a rather clean internal design, and writing a different back-end would be easy.It is indeed very clean, but MorleyDev is also right that several modules of SFML are not exchangable.
All the issues discussed here are about the API changes, not the implementation details.What about the render state?
What about the render state??
I think you missed reply #10.This is also about the public API. When I say "implementation details" I mean the corresponding OpenGL code -- which will probably be straight-forward.
I disagree. In my opinion SFML has a rather clean internal design, and writing a different back-end would be easy.
tl;drI fully agree on every single line. Jesus, this is rare, but I really agree to what you said. ;)
What do the others think?
What do the others think?It sounds interesting. I recently had a discussion about why a lot of professional indie games build their own engine from scratch, instead of resuing at least partially existing open-source libraries like SFML, Irrlicht or Ogre. Apart from religious reasons and the limited spread, one point was that although these libraries allow very quick development, specific features would be difficult to integrate, and people would always end up patching other libraries (which allegedly takes more time than rewriting everything). Nevertheless, it was certainly not the only reason.
Anyway, you can already now fork SFML and try to integrate your own features -- it would be a good way to show what ann implementation might look like, and over time the functionality would be improved with respect to code clarity, bugs and performance.Yes, it can be forked. But to be honest I'd rather contribute to the original source. The risk of patches not being accepted, especially with this project and its philosophies, is quite high, and I don't want to live with a patched library not written by myself. It's what the people say you asked: It's often easier to reinvent the wheel yourself to implement the things you need than taking an existing library, having to learn and patch it.
I thought they didn't properly deprecate the state system until OpenGL 3.0?True, in fact the platform which has the most constraints is OpenGL ES 2 (mobile devices), which has no fixed pipeline.