Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: SFML 3 - What is your vision?  (Read 197919 times)

0 Members and 1 Guest are viewing this topic.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10234
    • View Profile
    • development blog
    • Email
AW: Re: SFML 3 - What is your vision?
« Reply #255 on: September 14, 2014, 08:28:31 am »
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.
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Re: AW: Re: SFML 3 - What is your vision?
« Reply #256 on: September 14, 2014, 09:21:07 pm »
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.
« Last Edit: September 14, 2014, 09:22:59 pm by Tex Killer »

zsbzsb

  • Hero Member
  • *****
  • Posts: 1409
  • Active Maintainer of CSFML/SFML.NET
    • View Profile
    • My little corner...
    • Email
Re: SFML 3 - What is your vision?
« Reply #257 on: September 14, 2014, 09:42:25 pm »
Quote
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.

Quote
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 ;)
Motion / MotionNET - Complete video / audio playback for SFML / SFML.NET

NetEXT - An SFML.NET Extension Library based on Thor

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #258 on: September 14, 2014, 09:53:47 pm »
Quote
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?

Quote
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10234
    • View Profile
    • development blog
    • Email
Re: AW: Re: SFML 3 - What is your vision?
« Reply #259 on: September 14, 2014, 09:56:01 pm »
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 :P
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Re: AW: Re: SFML 3 - What is your vision?
« Reply #260 on: September 14, 2014, 10:50:40 pm »
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 :P

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.
« Last Edit: September 14, 2014, 10:53:01 pm by Tex Killer »

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #261 on: September 14, 2014, 11:49:22 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10234
    • View Profile
    • development blog
    • Email
Re: AW: Re: SFML 3 - What is your vision?
« Reply #262 on: September 15, 2014, 12:00:58 am »
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. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: AW: Re: SFML 3 - What is your vision?
« Reply #263 on: September 15, 2014, 02:11:19 am »
\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!
« Last Edit: September 15, 2014, 04:07:39 am by Jabberwocky »

Tex Killer

  • Full Member
  • ***
  • Posts: 242
    • View Profile
Re: AW: Re: SFML 3 - What is your vision?
« Reply #264 on: September 15, 2014, 06:38:00 am »
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.
« Last Edit: September 15, 2014, 06:41:36 am by Tex Killer »

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1485
    • View Profile
    • Blog
    • Email
Re: SFML 3 - What is your vision?
« Reply #265 on: September 15, 2014, 08:45:17 am »
Replaceable backends is definitely something that's at least on a "would be nice to have" list.

tyrion

  • Newbie
  • *
  • Posts: 6
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #266 on: September 15, 2014, 06:36:47 pm »
Quote
What would you do with a window with no GL context?
use another context :P
 (actually i am using ogre3d and commented out the glcontext stuff)
//#include <SFML/Window/ContextSettings.hpp>
//#include <SFML/Window/GlContext.hpp>

Zyl

  • Newbie
  • *
  • Posts: 12
    • View Profile
Re: SFML 3 - What is your vision?
« Reply #267 on: September 28, 2014, 07:25:48 pm »
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

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1404
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: SFML 3 - What is your vision?
« Reply #268 on: September 28, 2014, 07:55:22 pm »
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.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10234
    • View Profile
    • development blog
    • Email
Re: SFML 3 - What is your vision?
« Reply #269 on: September 29, 2014, 06:30:52 pm »
- 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.
Official FAQ: https://www.sfml-dev.org/faq.php
Nightly Builds: https://www.nightlybuilds.ch/
——————————————————————
Dev Blog: https://dev.my-gate.net/
Thor: http://www.bromeon.ch/libraries/thor/

 

anything