Z ordering

[Laurent]

I disagree. In my opinion SFML has a rather clean internal design, and writing a different back-end would be easy.

The problem with this feature is that it must be part of the public API. All the issues discussed here are about the API changes, not the implementation details.

[Tank]

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?

[Laurent]

What about the render state?

?

[Tank]

I think you missed reply #10.

[Laurent]

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.

[binary1248]

I think the main problem here is the definition of "simple" that people might have. For me, something that is simple is merely something that is easy to learn and understand if you want to. This concerns getting the things done that you want to get done. So if you do not understand how to achieve something with SFML, a quick look up in the documentation should get you up and running in minimal time.

If you compare SFML to other libraries out there then yes, SFML is simple but that is mainly because it does not force you to do things that shouldn't be your concern. As an example, if you want to draw a simple triangle in SFML, you would need to write <30 lines of code, whereas if you wanted to do the same using DirectX and Win32 you would end up with >200 lines of code. This is what the difference between "simple" and "complex" is for me.

If you add depth functionality to SFML it will still stay simple, even if you expose more details to the user because they can opt not to make use of it if they want and SFML won't bother them with unnecessary details. This would make SFML more powerful while still keeping it simple and easy for newcomers to learn. I regret to say, but you are sacrificing the power and flexibility that such a library could provide to those that need it in favour of protecting beginners from a longer list of methods that they might potentially not even need. This is a wrong decision if you ask me, because it deters more "serious" users to go use other libraries or write their own code on top of SFML to get things done which reduces productivity.

SFML has great potential and might even overtake many other libraries out there if you can provide more advanced functionality while keeping to the same principles that you have so far. Just like good computer games, it should be easy to learn and hard to master.

I have another proposal, perhaps SFML can adopt a similar model to what C++ uses regarding its standard library. People can propose extensions that are implemented using the core SFML functionality much like boost is the staging ground for possible inclusions into C++. If you consider the quality to be up to your standards and the extension is widely accepted and used among the community then you can think about adopting and merging it into core SFML. This would make the SFML development and evolution process unique among libraries of its kind and the rationale behind the features in it based on real-world experience as opposed to theoretical/ideological usage concerns.

What do the others think?

[MorleyDev]

I disagree. In my opinion SFML has a rather clean internal design, and writing a different back-end would be easy.

In general it's a very clean from a high-level point of view.

Perhaps an example of what I mean is needed. See RenderTarget::draw. Personally I find this function just has way too much going on in it, the RenderTarget class and that function are directly responsible for too many things.

To talk in terms, it breaks Single responsibility.

From a big design point of view the interface is very nice, the underlying code isn't a sphagetti-like mess, many if statements but the nesting is shallow and they end quickly. It is very easy to understand and modify, but it's not without problems. As I said I favour small functions with very tight focus, and that does not (from my point of view) describe that draw function or some other parts of SFML that have just built up a lot of mass to accomplish their many responsibilities.

Of course this may just be a result of them not being refactored and cleaned up in awhile. Bit rot takes it's toll on us all.

[Tank]

tl;dr
What do the others think?

I fully agree on every single line. Jesus, this is rare, but I really agree to what you said.

However, whilst SFML in itself is greatly designed, it's not best suited for writing extensions in some areas. I guess the reason for that is the simplicity this library was and still is targeted at. E.g. you never have to instantiate a renderer and you mostly don't have to deal with technical details. SFML is, even if often stated otherwise, quite high-level with not sooo much room to be extensible -- at least not without touching the original code.

I, and most likely others, including binary1248, too, would have written some extensions for SFML already if it was easy or even possible to do so. Just like this z ordering discussion. The problem is that I can't really do it myself without patching SFML, while having in mind that my patch probably will never be accepted because the library's author has another philosophy.

Like binary1248 I'm also convinced that SFML could be a lot better regarding acceptance in the "more serious" field by enabling the user to use or attach advanced features and techniques. But without that possibility I assume that many won't consider using SFML for projects because of its limited scope. I already said it a million times already, but I'm seriously considering writing my own OpenGL rendering code (again *sigh*) for the _small_ game I'm making because I've already hit the boundaries of SFML that I can't workaround without patching it.

Of course making SFML's modules more exchangeable isn't a step you can do in some days or even weeks, and something like this has to be planned carefully. But if you asked me, I'd love to see SFML's future in a collection of core and extension modules. One might argue that SFML already is just that, but that's not quite true. Even if the modules are separated, and if some of them can be dropped if not used/needed, they still form a whole in themselves.

So, +1 for an SFML App Store.

[Nexus]

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.

On the other hand, I don't see that more low-level functionality necessarily improves the library. It is always a trade-off between abstraction and flexibility. And you can never achieve everything you could when using directly the underlying libraries, so it's just a question of where to draw the border. The k.o. criterion would be the utility of a new feature vs. its complexity in API and implementation.

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. This approach does not steal Laurent's rare free time, and with a working and clean implementation, it might be easier to convince him

[Tank]

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.

[Laurent]

My best members are having a passionate discussion about philosophy and design choices. I really love that

My first answer was "I'm not against this feature", and it's still true. The problem is that there are obvious design issues to solve, so when I say "I'm not convinced" you should understand "wait after SFML 2.0 is released so that I have time to experiment the idea", not "I won't do it".

Make SFML more extensible/flexible to allow add-ons... it's already the philosophy. I changed the graphics API to provide a single low-level entry point for rendering (vertex array + render states), base classes that allow to reuse common code/interfaces in any class, and now all higher-level classes are built on top of that and anybody can provide its own graphical class which would be at the same level as SFML built-in classes. That was already an important step (remember, in SFML 1.6 every graphical class had direct OpenGL calls in it).

But providing enough flexibility so that you can add the Z-buffer feature without touching SFML, seems like impossible to me. It requires to add a Z component to the lowest-level possible graphical entities, to adapt the context creation code to force a Z-buffer, and to manage additional OpenGL states. It's a core feature and I don't know what kind of design SFML could have to allow that as an external add-on.

But yes, of course I agree with this philosophy, and I'll try to take this direction whenever I can.

[MorleyDev]

The best way I can think of is if your render target is split down into a series of components that determine how rendering takes place. So if you disable alpha blending, the alpha blending rendering component isn't present. If you want the Depth Buffer, replace the parts of the render target that it needs to in order to allow for depth buffering. Basically render-target would no longer contain any OpenGL calls, it's dependencies would handle all of that so all you need to do is swap out those dependencies.

In theory this also means you could have an implementation that, when the depth buffer is missing, fakes one in code by buffering render calls until the very last second...

It'd require a pretty big refactor of the draw code before even beginning. I mean, it'd be incredibly flexible but a lot of effort would have to go into it.

[Laurent]

That would work in a perfect world. In the real world, things are never completely independant. Especially when you start to implement optimizations. The context handling of OpenGL, which is tightly linked to the windowing system and OS dependant, makes it even harder (to have a depth buffer you need to modify this part too). It doesn't even belong to the same SFML module.

And don't forget that SFML will soon switch to a shader-only implementation (GL 2 architecture). Which makes it easy to customize the rendering, you just have to provide your own shader, but it becomes impossible to combine several pre-defined rendering features together at runtime.

[MorleyDev]

Ah, the requirements at Window creation managed to completely split my mind...yeah, that does make things even more complicated...although in theory dependency injection would still be very doable there since it means you're just swapping out the dependencies of RenderTarget depending upon whether or not the depth buffer is there. But still more complicated especially given the current approach where classes manage their own creation instead of a factory pattern.

But then when you throw the shader-only implementation...hmm, very interesting. I thought they didn't properly deprecate the state system until OpenGL 3.0? Still, shader-only is always good. New challenges brought by that, but good.

[Laurent]

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.