SFML 3 - What is your vision?

[AlexAUT]

My wishes for SFML3/SFML2.x:

• Better support of multiple display setups, so we can choose if we want to create the window on the primary display or secondary.
• Option to create a core context, maybe only for sf::Window due to the legacy code in sfml-graphics.
• OpenGL ES2.0 on mobile platforms
• Drop glew and use glLoadGen (less dependency when linking statically, less typing  )
• Expose the OpenGL ID from textures

AlexAUT

[binary1248]

• Option to create a core context, maybe only for sf::Window due to the legacy code in sfml-graphics.
• Drop glew and use glLoadGen (less dependency when linking statically, less typing  )
• Expose the OpenGL ID from textures

You might want to try this. It's been around for a while. Just hasn't been promoted that much .

[AlexAUT]

Looks nice, thanks for pointing that out!


AlexAUT

[Cmdu76]

Is there a place to regroup all ideas ?

I mean :
- A place of the features which "will be added" in SFML3
- A place of the features which might be added in SFML3
- A place of the ideas which will not be added in SFML3 (with a short explication why)

So what it's m'y vision for SFML3 :
- C++11 no-obligatory (to allow older platform)
- Filesystem
- GUI (like SFGUI)
- Easier ressources managements with containers (like Thor)

Build SFML, and then each others libraries is a bit boring (and hard for users the first time), thoses projects are "linked" with SFML and are very usefull and stable, why dont add them to SFML3 ?

[Ixrec]

- C++11 no-obligatory (to allow older platform)

I'm pretty sure using C++11/14 only restricts the compilers you can use, not the platforms the final executable will run on.  It's not like OpenGL versions.

- Filesystem

Considering the C++ proposal for a standard filesystem library has gotten far enough to have a technical specification, is there really a need for SFML to implement this now? (the proposal is based on Boost.Filesystem which is obviously already available)

- GUI (like SFGUI)
- Easier ressources managements with containers (like Thor)

For SFGUI/Thor/etc, putting them directly into SFML is probably a bad idea (they're really a layer on top of SFML, not additional modules for it), but it would be very nice to see those extensions officially distributed alongside SFML so their build processes could be streamlined and they'd get more exposure/usage.

[FRex]

I'm pretty sure using C++11/14 only restricts the compilers you can use, not the platforms the final executable will run on.  It's not like OpenGL versions.

Latest visuals had minor issues with deployment onto XP but there is update for that. I know, 'XP is dead' but many people still wanna support it and who knows how long compilers will support building for XP, especially Microsoft's.

For SFGUI/Thor/etc, putting them directly into SFML is probably a bad idea (they're really a layer on top of SFML, not additional modules for it), but it would be very nice to see those extensions officially distributed alongside SFML so their build processes could be streamlined and they'd get more exposure/usage.

Honestly, every SFML module except system is extension or 'layer on top of' to system (and graphic is also extension to window). There is nothing preventing you from discarding one module and pretending it doesn't exist, they are not internally tied to each other and there is no reason new ones like GUI, Thor, Whatever should be. It was just issue of 'out of our scope of SFML' and API stability so far for not including more stuff.

[zsbzsb]

I really don't understand why you guys insist on discussing things that are clearly marked as off topic to this thread. If someone wants to suggest something like it again just ignore that point and pretend it was never mentioned.

The proposals in this thread should focus on functionality that cannot easily be implemented on top of SFML, because of a limitation within SFML itself. That is, not features that can as well be part of external libraries.

[MW2TopTenWORLD]

I Can't think of much, I've just started using SFML... But one of the reasons I didn't used VS2013... Was because sfTheora was incompatible with 2013....

WHAT I MEAN IS : Let the next SFML Version play video natively

[zsbzsb]

WHAT I MEAN IS : Let the next SFML Version play video natively

Did you really not just my last post?

[lolz123]

@zsbzsb: I think his suggestion was perfectly valid. A video player should exist for the same reasons that the audio module exists in my opinion. You say we should only suggest things that cannot be built on top of SFML, but then really what is SFML? It's not a multimedia library anymore. Since graphics, audio, networking are relatively independent, you can always just use another library and add on functionality. They are not so intertwined that you cannot have one without the other. SFML in my eyes is supposed to be a collection of easy to use interfaces to multimedia functionality, and video playback falls under this just like audio playback does.

So, I am for MW2TopTenWORLD's idea.

[tyrion]

• Better support of multiple display setups
• glcontext optional for windows
• hardware cursor

[Laurent]

What would you do with a window with no GL context?

[firstep]

cLion support

[Strelok]

cLion support

Support an IDE? SFML works with CLion as I've already shown you here

[Tex Killer]

Laurent, is it possible (and are you planning) to remove all of the dynamic dependencies of SFML?

Another question: Would it be possible to separate all of the platform specific code from the SFML logic code on different files? Like, the OpenGL code separated from the Drawable/Window/Whatever code, in a way that the platform specific code could be easily ported without messing with SFML's logic?