SFML 3 - What is your vision?

[eXpl0it3r]

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

Not really. The main problem is, that there's nothing compareable out there to OpenAL. Some similar libraries are even less permissive and others don't support iOS and Android..

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?

I'm not sure what you're asking. All platform specific code is usually in separated class (see all the XYZImpl.hpp/cpp files).
As for the rendering/OpenGL code, we might investigate a more detached approach.

[Tex Killer]

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

Not really. The main problem is, that there's nothing compareable out there to OpenAL. Some similar libraries are even less permissive and others don't support iOS and Android..

I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?

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?

I'm not sure what you're asking. All platform specific code is usually in separated class (see all the XYZImpl.hpp/cpp files).
As for the rendering/OpenGL code, we might investigate a more detached approach.

Lets say I want to port my SFML game to Xbox360, for example. As far as I know, Xbox360 has no OpenGL support, only DirectX. With the platform code (in this case, OpenGL) in its separated classes, all I would need to do would be to reimplement the platform classes using DirectX (I would imagine classes like Texture, Polygon, Display, or something like this, very low level), while maintaining the same interfaces, recompile SFML with those new implementations, then SFML would work with DirectX instead of OpenGL. The same if I would want to port my game to a platform that doesn't support OpenAL, for example.

[zsbzsb]

I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?

It was permission to statically link libsndfile, however we did not get permission to do so. AFAIK dropping libsndfile as a dependency is what we are going to do about that.

Lets say I want to port my SFML game to Xbox360, for example.

Porting SFML's rendering to DirectX is not really porting to another platform, its just changing the backend. So if you want XBox support you need platform specific code for the XBox and you need to change the rendering backend. That said, allowing multiple backends is unlikely to happen anytime soon. If you want to mess around with porting SFML's rendering to DirectX have fun. It won't be as easy as you make it out to be

[Tex Killer]

I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?

It was permission to statically link libsndfile, however we did not get permission to do so. AFAIK dropping libsndfile as a dependency is what we are going to do about that.

Ok, I stand corrected. I will be on the lookout for potential OpenAL replacements but, if I understood correctly, SFML 3 would only need 1 dll for OpenAL. Is that right?

Lets say I want to port my SFML game to Xbox360, for example.

Porting SFML's rendering to DirectX is not really porting to another platform, its just changing the backend. So if you want XBox support you need platform specific code for the XBox and you need to change the rendering backend. That said, allowing multiple backends is unlikely to happen anytime soon. If you want to mess around with porting SFML's rendering to DirectX have fun. It won't be as easy as you make it out to be

I am not saying it is that easy now, but I am asking if it could be, and how hard would it be to redesign SFML to work with platform (or backend, whatever) interfaces instead of directly to facilitate such ports. We are on the SFML 3 vision thread, after all.

[eXpl0it3r]

I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?

You probably confuse this with libsndfile. I asked again and there wasn't any progress after 8+ month - still hasn't. As such the decision was made to drop libsndfile.
OpenAL itself is well supported on all platforms, so there's currently no issue (iOS comes with its own version).

Lets say I want to port my SFML game to Xbox360, for example. As far as I know, Xbox360 has no OpenGL support, only DirectX. With the platform code (in this case, OpenGL) in its separated classes, all I would need to do would be to reimplement the platform classes using DirectX (I would imagine classes like Texture, Polygon, Display, or something like this, very low level), while maintaining the same interfaces, recompile SFML with those new implementations, then SFML would work with DirectX instead of OpenGL. The same if I would want to port my game to a platform that doesn't support OpenAL, for example.

You're misusing the word "platform"; OpenGL isn't "platform code". SFML could currently potentially be ported to any platform supporting OpenGL 2.x-ish or with the upcoming Android port also OpenGL ES 1.something. The fact that Xbox360 doesn't support OpenGL, doesn't make the OpenGL code "platform code", but Xbox360 simply doesn't provide the nessecary dependency.
However there are discussions going on, on how to refactor the graphics code to make it possible, to implement different rendering back-ends, such as DirectX. How and if this will be done, is still in discussion.

Edit: Hrmpf zsbzsb

[Tex Killer]

I see... There was talk some time ago about asking for permition to static link OpenAL from the developers, or something like that. Did it go through?

You probably confuse this with libsndfile. I asked again and there wasn't any progress after 8+ month - still hasn't. As such the decision was made to drop libsndfile.
OpenAL itself is well supported on all platforms, so there's currently no issue (iOS comes with its own version).

I've already answered that to zsbzsb...

Lets say I want to port my SFML game to Xbox360, for example. As far as I know, Xbox360 has no OpenGL support, only DirectX. With the platform code (in this case, OpenGL) in its separated classes, all I would need to do would be to reimplement the platform classes using DirectX (I would imagine classes like Texture, Polygon, Display, or something like this, very low level), while maintaining the same interfaces, recompile SFML with those new implementations, then SFML would work with DirectX instead of OpenGL. The same if I would want to port my game to a platform that doesn't support OpenAL, for example.

You're misusing the word "platform"; OpenGL isn't "platform code". SFML could currently potentially be ported to any platform supporting OpenGL 2.x-ish or with the upcoming Android port also OpenGL ES 1.something. The fact that Xbox360 doesn't support OpenGL, doesn't make the OpenGL code "platform code", but Xbox360 simply doesn't provide the nessecary dependency.
However there are discussions going on, on how to refactor the graphics code to make it possible, to implement different rendering back-ends, such as DirectX. How and if this will be done, is still in discussion.

Edit: Hrmpf zsbzsb

I don't know, it seems to me that any code that isn't ANSI C/C++ is to be considered a platform specific code, even if it has ports on multiple platforms. But if you preffer, you could interpret my posts as referring to backends then.

[Jabberwocky]

However there are discussions going on, on how to refactor the graphics code to make it possible, to implement different rendering back-ends, such as DirectX. How and if this will be done, is still in discussion.

I'm not downplaying the difficulty of this task.  However, this is highly desirable, from an SFML user perspective.

It is a make or break feature for any user or game studio evaluating SFML for use in a console game, or even a PC game with a potential console port down the road.  This is a large user base to turn away from SFML due to lack of necessary cross-platform support. 

It may be worth looking at Ogre3D's decoupling of RenderSystems (DirectX, GL, GLES) when considering a similar architecture for SFML. 

[eXpl0it3r]

I don't know, it seems to me that any code that isn't ANSI C/C++ is to be considered a platform specific code, even if it has ports on multiple platforms. But if you preffer, you could interpret my posts as referring to backends then.

Not really. If you use library X one OS K, the library API doesn't become "platform code", the API itself has nothing to do with OS K, it's just an API on it's own. The issue that library X isn't supported on OS J still doesn't make the library API platform specific/platform code.
I can write a library just using standard C++ (it's probably better to use ISO than ANSI, even if ISO stuff is automatically ANSI), like my library has a public function test() which prints out "Hello World". By your definition my standard C++ library would now turn into platform code, since my function test() isn't part of the standard C++. However since my code is written in standard C++, it will work on any platform, thus my API (the test() function) isn't platform code.

OpenGL is also "just" an API (okay it's a bit more tricky than that), it's not platform code, but the API isn't available on all platforms.

Anyways to end this discussion and to repeat the conclusion: Yes, SFML might be getting the possibility to implement different rendering back-ends.

It is a make or break feature for any user or game studio evaluating SFML for use in a console game, or even a PC game with a potential console port down the road.  This is a large user base to turn away from SFML due to lack of necessary cross-platform support.

We're aware of that. However one should also not forget that developing for consoles usually comes with a licensing price to begin with, thus officially porting SFML to such "pay-first-develop-later" platforms probably won't happen, unless there are generous sponsors or something.

It may be worth looking at Ogre3D's decoupling of RenderSystems (DirectX, GL, GLES) when considering a similar architecture for SFML.

I don't think, it's worth looking at that too much, then again I don't know it in detail.

[Jabberwocky]

\However one should also not forget that developing for consoles usually comes with a licensing price to begin with, thus officially porting SFML to such "pay-first-develop-later" platforms probably won't happen, unless there are generous sponsors or something.

I understand eXpl0it3r, and that makes sense.
But it only applies to one of the 3 steps involved

• decouple the rendering backend (opengl) from SFML
• create a DirectX back-end for SFML
• create SFML console port(s)

Of course console ports may not be realistic for the SFML team (without the generous sponsors).  But the other two steps at least do not have the licensing issue.  One or both would be extremely helpful.

Ogre3D is an open source example (MIT licensed) that does exactly what we're discussing, except in 3D rather than 2D.  I just mention it as a reference.  The sample programs begin with a startup dialog which allows you to select the render system (OpenGL, DirectX).  And the code demonstrates one approach to creating a render system independent graphics API that can hook into different back ends.  Anyway, I am highly encouraged you are considering some work in this area, and just wanted to express my enthusiasm for the idea.  I am sure, given the quality of the SFML code, that should the SFML team pursue this, the code will be very well done.

Regardless, I am highly appreciative of SFML and the team's work.  But since we're discussing the future of SFML, this would probably be the single most important change for SFML to bring in a larger audience of professional studios.  I'm pretty new around here - I'm not sure whether this is important to you or not.

Thanks for your time!

[Tex Killer]

I don't know, it seems to me that any code that isn't ANSI C/C++ is to be considered a platform specific code, even if it has ports on multiple platforms. But if you preffer, you could interpret my posts as referring to backends then.

Not really. If you use library X one OS K, the library API doesn't become "platform code", the API itself has nothing to do with OS K, it's just an API on it's own. The issue that library X isn't supported on OS J still doesn't make the library API platform specific/platform code.
I can write a library just using standard C++ (it's probably better to use ISO than ANSI, even if ISO stuff is automatically ANSI), like my library has a public function test() which prints out "Hello World". By your definition my standard C++ library would now turn into platform code, since my function test() isn't part of the standard C++. However since my code is written in standard C++, it will work on any platform, thus my API (the test() function) isn't platform code.

OpenGL is also "just" an API (okay it's a bit more tricky than that), it's not platform code, but the API isn't available on all platforms.

I might have expressed myself poorly, but that was not what I meant. Your library (with the test() function) would not be platform dependent, since it would work on any platform. I would tell your library is platform independent, since it only deppends on ANSI C++ to work.

On the other hand, if your library required some Windows API (for example) to work properly, I would consider it platform dependent. It is the same for OpenGL: as far as I know, OpenGL is an API that requires an implementation interfacing directly with the platform functions, so it is platform dependent. Any code that uses OpenGL would also be platform-dependent, since it would require the platform's implementation and support for the OpenGL API.

In other words, I consider a code platform independent if and only if it works on any platform that has an ANSI (or ISO, don't realy know the difference) C/C++ compiler, without requiring anything else. My suggestion would be to separate this kind of code from the platform dependent code on SFML, so it would be easier to port it to whatever platform.

[Tank]

Replaceable backends is definitely something that's at least on a "would be nice to have" list.

[tyrion]

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

use another context
 (actually i am using ogre3d and commented out the glcontext stuff)

//#include <SFML/Window/ContextSettings.hpp>
//#include <SFML/Window/GlContext.hpp>

[Zyl]

I tried some SDL. I find SFML better for OOP, Documentation and Guides/Tutorials.

2 cents:
- GL core spec should be used by default. Yes I can recompile SFML, but defaults matter. 
- http://www.sfml-dev.org/tutorials/2.0/window-window.php says it uses sf:sleep for managing framerate limit, and that sf:sleep's "resolution depends on the underlying OS, and can be as high as 10 or 15 milliseconds". I find it very important to use the best (most accurate) solution on every OS. i.e. Windows has Multimedia Timers. Using an inaccurate thread-sleep in non-v-synced mode kind of defeats the purpose of a non-v-synced mode (reduced input lag).

Cheers.

[binary1248]

GL core spec should be used by default. Yes I can recompile SFML, but defaults matter

sfml-graphics is still written to use legacy OpenGL, so as long as you use it, you will have to use a compatibility profile context. Work is already under way in the gl_dev branch to add support for selecting between compatibility and core profiles. If you don't need to use sfml-graphics and only use sfml-window, you will be able to create a core (and debug) context.

[eXpl0it3r]

- http://www.sfml-dev.org/tutorials/2.0/window-window.php says it uses sf:sleep for managing framerate limit, and that sf:sleep's "resolution depends on the underlying OS, and can be as high as 10 or 15 milliseconds". I find it very important to use the best (most accurate) solution on every OS. i.e. Windows has Multimedia Timers. Using an inaccurate thread-sleep in non-v-synced mode kind of defeats the purpose of a non-v-synced mode (reduced input lag).

The discussion about this, has been moved to this thread.