My (Possibly stupid) Ideas for the Future of SFML

[lolz123]

Hello everyone,

I would like to share with you some ideas for new features for SFML. I hope the new development team takes some of these into consideration. That said, the following ideas may be impractical or not fit with SFML's design philosophy. Also keep in mind that I have not extensively studied SFML's source. I also know that a lot of these features would require major alterations to SFML, so think of these features as being part of SFML Version 8.0 or something 

Graphics:
I think SFML should be less of an abstraction of OpenGL and more of an interface for it. Think of something like OpenTK. Basically, wrappers that simplify using OpenGL, but do not obscure OpenGL functionality from the user. It could still supply functions for making handling 2D easier, but they should not make interfacing with OpenGL code a pain like they currently do (you may disagree, this is just from my experience). The 2D helper functions would have to have well-defined GL states (documented), and should make as few GL State transitions as possible. It might also be a good idea to include a GL state tracking system.

Networking:
binary1248's SFNUL library looks awesome. I wouldn't mind seeing it become part of SFML.

System:
I would drop the current threading system in favor of the C++11 threading system.

AI Module?
Here is a totally crazy idea. I am obsessed with AI, so there is an obvious amount of bias here. Perhaps SFML could have some AI related functionality. Some basic pathfinding, state machines, descision trees, and perhaps even some more hardcore machine learning algorithms (LSTM-RL is my current favorite  ). There are not really many decent AI libraries out there, so I think SFML could get some edge over the competition by offering AI functionality. Does this fit with SFML's design philosophy? Perhaps not. But from what I can tell SFML is used mostly for games, and games need AI.

[binary1248]

I also know that a lot of these features would require major alterations to SFML, so think of these features as being part of SFML Version 8.0 or something 

Why 8.0? That is 6 API breakages from 2.0 and (maybe I'm being a bit too optimistic) now that there are more hands to help around, I can imagine more bigger features being added between successive major versions than e.g. between 1.x and 2.x. Maybe saying that they will make it for 3.x is being a bit too optimistic, but if we have a solid roadmap laid down and tasks distributed among us, I don't think it will be a problem to get some in for 4.x.

Graphics:
I think SFML should be less of an abstraction of OpenGL and more of an interface for it. Think of something like OpenTK. Basically, wrappers that simplify using OpenGL, but do not obscure OpenGL functionality from the user. It could still supply functions for making handling 2D easier, but they should not make interfacing with OpenGL code a pain like they currently do (you may disagree, this is just from my experience). The 2D helper functions would have to have well-defined GL states (documented), and should make as few GL State transitions as possible. It might also be a good idea to include a GL state tracking system.

I think we will probably need to reassess the current situation regarding the graphics module. I think we can agree that the current feature set should be changed as little as possible. Keeping that in mind, maybe the internals can be refactored to support direct interfacing with OpenGL a bit better than it currently is.

Sonkun is currently working on an experimental DirectX rendering backend as well, so it is possible that SFML will end up interfacing with the lower level libraries through a unified rendering interface.

Also, I think going forward, SFML should slowly deprecate OpenGL state management in favour of modern OpenGL when the platform permits. This would not only make it easier to share an interface with the DirectX renderer but would also limit SFML less in terms of direct OpenGL interaction because less state housekeeping would need to be performed. We'll wait and see what further discussions reveal .

Networking:
binary1248's SFNUL library looks awesome. I wouldn't mind seeing it become part of SFML.

I don't know about it all becoming a part of SFML. Maybe the idea behind sfn::Message can be transferred over to sf::Packet in order to allow the user to stream data structures as well as POD types. I do hope that TCP connection management can be improved though, as I always feel uneasy when sf::TcpSocket sends a RST instead of initiating a connection teardown as described in the standard. TLS support would also be nice and would allow sf::Http to be usable with HTTPS once again. As for the major feature, the synchronization, maybe a bit more discussion is needed .

System:
I would drop the current threading system in favor of the C++11 threading system.

I think this is something everybody will agree on easily. Maybe the threading system shouldn't be outright dropped, but instead marked as deprecated and a recommendation should be present that informs the user to use their standard library's implementation. One issue with this is that on certain platforms, standard library support for C++11 still isn't 100% complete/bug free.

AI Module?
Here is a totally crazy idea. I am obsessed with AI, so there is an obvious amount of bias here. Perhaps SFML could have some AI related functionality. Some basic pathfinding, state machines, descision trees, and perhaps even some more hardcore machine learning algorithms (LSTM-RL is my current favorite  ). There are not really many decent AI libraries out there, so I think SFML could get some edge over the competition by offering AI functionality. Does this fit with SFML's design philosophy? Perhaps not. But from what I can tell SFML is used mostly for games, and games need AI.

Hmm... I don't know if AI support is within the scope of a multimedia library. But I guess it really depends on how one interprets it .

I think one factor that will speed up implementation of new features is the fact that we already have reference implementations to assess and discuss over. It makes it easier to see what can and can't be done and how or how not to do things. They might not be transferred 1:1 but a lot of the initial designing will have been done already and is probably reusable. This is also the way the C++ standards committee adds features to the standard library from what I can understand.

And before I forget: Doesn't this thread belong in the Feature requests sub-forum?

[Ixrec]

Might as well throw out my crazy long-term ideas too.

1) Consider adding a Game module.  There are many features currently beyond SFML's scope that are only really useful for games, but since that's the main thing SFML gets used for, it might be nice to deliberately expand the scope in that direction at some point.  Grimshaw suggested something very similar the other day, and I pretty much agreed with his list:
- A entity system (component based)
- A premade renderer for that entity system
- A nice state manager approach
- Model loading and a basic scene format
- Particle system behaviors

2) Have some sort of official extension system.  Currently, whenever someone asks for something like vector arithmetic or GUI widgets or video, we have to tell them to go use Thor or SFGUI or sfeMovie or whatever.  It would be nice if the official website, tutorials and maybe even distribution included some of these extremely useful extensions.  Even if they aren't as actively maintained as the core of SFML, it would save a lot of people from reinventing wheels they had no way of knowing were already published on these forums.  Plus, having a lot more people try out those extension libraries would make it a lot easier to figure out which features are worthy of being merged into the core (SFNUL comes to mind).

[Nexus]

1) is rather unlikely to happen. As you see in the other discussion, we would like to focus on features that cannot easily be provided as an extension.

2) might be a good idea

Concerning Artificial Intelligence: lolz123, you have already made a lot of projects in that area, so you probably have quite some experience. Have you considered outsourcing some often-used functionality into an AI library?

[Grimshaw]

My opinion and philosophy is still to create specifications for the basic features a game/multimedia app needs. Rather than implement things in a given way on the high level, which might be hard to agree on, just create the file format specifications and some basic loading and other lower level features.

This could allow for a set of useful extensions that are unified by common elements, and therefore compatible between each other for some extent.

For example, SFML could have a 3D model specification and the community could build converters from any format in collaboration. SFML would be clean and it would certainly attract more users to the new functionality and 3rd party extensions/tools.