SFML 3 - What is your vision?

[eXpl0it3r]

As promised we as the new team, would like to be more open towards the community especially regarding the current development. We're currently discussing on how to approach things after SFML 2.2 and as such, we need to figure out what SFML 3.0 should actually be about.

Keep in mind this shouldn't really be about simple feature requests, for that we have dedicated forum, this should be more about what SFML 3 should offer besides a few new feature. For example: How the graphics API should be changed/opened/advanced, or whether C++11 should be non-optional, or should we change the way window states are handled, or etc...
We won't make any decisions here, we simply want to hear the ideas from all community members.

What is your vision of SFML 3?

[Oldie]

C++11 is by now almost entirely supported by major compilers. Also SFML 3 is still far away, which means there is more time for the last C++11 features to be supported. With this in mind, I think there is no doubt that SFML 3 should be using C++11 in its implementation as well as in its public API, and therefore make it not optional.
C++1y should wait though, as the norm is not definitive yet.

[infinitebox]

Things I could think of on top of my head:

• Better input handling (mouse grab, scancode & etc).
• Expose OpenGL handles.
• Modern OpenGL backend and context creation options.
• C++11
• Separate window and it's draw methods? (having both the view and renderer all in one object seems kind of strange to me :S)
• More awesome features!
• Replace the vector stuff with GLM (could also pave path for 3D support).

Pretty please!

updated: I remembered more!

[Veltas]

Okay, I hope this doesn't count as off-topic.

Firstly, how exactly does optional C++11 work? You could insert new features that define code better or swap-out with older style code, like override, or nullptr etc.?

And then secondly, if there's discussion to be had on

whether C++11 should be non-optional,

then what advantages could there be in designing the library around the latest C++ standard?

Also, C++14 is due soon enough, and VS, GCC and clang will also support it soon enough (if Herb Sutter's projections for VS weren't too optimistic). Would it be worth using C++14 in place of C++11?

[Doodlemeat]

You can take a look at the Kinetic framework which is written in JavaScript.
It has really nice features like transitions, tweening, group/layer -rendering and neat on-events like onClick, onHover and so on... This clearly fits within the multimedia limit.

[eXpl0it3r]

Firstly, how exactly does optional C++11 work? You could insert new features that define code better or swap-out with older style code, like override, or nullptr etc.?

Not sure, moste likely with a lot of ugly #ifdef, I just add the non-optional thing to make it clear and since currently there's optional C++11 support targeted for 2.x - which ofc could change.

Also, C++14 is due soon enough, and VS, GCC and clang will also support it soon enough (if Herb Sutter's projections for VS weren't too optimistic). Would it be worth using C++14 in place of C++11?

It's really to early to tell for sure, C++14 is still just a draft and how fast compiler vendors will implement the proposal is also an open question.
However since the proposed features are not very complex, they most likely won't have an influence on designing SFML 3, thus it's not very important at the moment and we can decide once we get there.

You can take a look at the Kinetic framework which is written in JavaScript.
It has really nice features like transitions, tweening, group/layer -rendering and neat on-events like onClick, onHover and so on... This clearly fits within the multimedia limit.

It would be nice, if you could elaborate on things a bit more, especially given that JavaScript and C++ aren't easily comparable in certain regions. It would be especially interesting to hear your thoughts on the event things that you mentioned.

[Jesper Juhl]

My personal wish list (at least the bits I can remember right now):

- C++11 non-optional.
- Integrate parts of Thor into SFML proper (stuff like the vectors, big texture, clock and math bits).
- Improved iOS and Android support.
- Official support for FreeBSD.
- Get something like BuildBot or Jenkins up and running so we can get continuous integration up and running (build every commit on all supported platforms + run tests for each build).
- Native support for playing video.

[ChronicRat]

I need only shaders in OpenGL ES port. =) And, i think, base support of 3D may be? I see slogan - SFML3 is SFML3D! =)

[Ricky]

Since I don't really feel limited by SFML (yet) I don't really know what I can say but I think these ideas would be cool:
Use modern openGL under the hood and expose more openGL through the API for advanced users
Incorporate community projects that I feel should have been part of SFML from the start (SFNUL, 3DEE)

I'm glad to see my favorite open source project receive a second life! Goodluck guys!

[AbelToy]

A way to make sprite batching easier to use and more integrated with SFML.

[therocode]

Two things that I'd find awesome are these:

1.
If possible, render and audio context management. In other words, separate the contexts out from the Window and wherever it is stored for the audio into sf::RenderContext and sf::AudioContext and provide an API for using custom contexts. This would make it way easier to integrate SFML in certain situations and would mean better ownership-based design with less magic stuff going on. That magic stuff is sure arguably easier and more simple but I find that in the long run, it is a drawback.

2.
I am a fan of Emscripten and I have written some code in my own game framework to make it compatible with emscripten out of the box. This means that any game I make with my framework, I can easily compile to have it run in the browser. Some silly examples: bladepit  ants   space. As you can see they run with good framerates and it is just javascript and webgl so will work on pretty much any browser that supports that. Would be neat to have web-compile capabilities for SFML as well!

For emscripten support, what is required is a special way of handling the main loop so that the browser doesn't freeze, and compiling all the dependencies, and tieing browser events to the SFML events. It could be hard to support _all_ the features of the Window module since the browser app acts pretty different to a desktop application but that can be alright imo as long as it is well documented.

[Laurent]

If possible, render and audio context management. In other words, separate the contexts out from the Window and wherever it is stored for the audio into sf::RenderContext and sf::AudioContext and provide an API for using custom contexts. This would make it way easier to integrate SFML in certain situations and would mean better ownership-based design with less magic stuff going on. That magic stuff is sure arguably easier and more simple but I find that in the long run, it is a drawback.

I totally agree with that.

Would be neat to have web-compile capabilities for SFML as well!

This is less likely to happen. But if someone provides an implementation, why not.

[eigenbom]

C++11 required
Filesystem api
Opengles
Support for all modern platforms including Xbox, ps4, and web via emscripten
More interesting suite of demos

I can dream right?

[therocode]

Context stuff.

I totally agree with that.

Awesome!

Would be neat to have web-compile capabilities for SFML as well!

This is less likely to happen. But if someone provides an implementation, why not.

Ah, any particular reason why it is not likely to happen? Running things in the browser is all the rage these days.

[Tank]

Ah, any particular reason why it is not likely to happen? Running things in the browser is all the rage these days.

I think because nobody on the team has a single clue of how that's going to work. Perhaps we can elaborate what changes are exactly needed to make this happen. With help from someone who has a good knowledge of emscripten we can probably work something out.