SFML 3 - What is your vision?

[Nexus]

There's an important advantages of exceptions, that may sound counter-intuitive at first. When employing exceptions in the right scenarios, you end up with less error handling than with any other technique. The reason is that you can separate code that possibly throws and code that catches exceptions. Code that does something that may throw doesn't have to care, things can be handled at a much higher layer. Exception handling in C++ requires usually very few try-catch statements; this paradigm is fundamentally different from languages like Java, for example.

On the other hand, exceptions disrupt the program flow. In critical situations, this is intended, but they should not be overused in situations where no actual exceptional situation is present. And in my opinion, assert should be preferred for logic errors.

The pattern used by MorleyDev also exists, and it will be introduced in the C++ standard as std::optional. It's similar to boolean return types in the handling (which definitely have their use cases). But you're performing a heavy and unnecessary copy, a mistake that might be made by many people.

[dk123]

I added a few opinions in a previous post, but I'd like to also add one thing:

- movie playback (desktop + android/ios)

With narrative becoming a key part in modern day games, movie insertion in games are becoming more and more an important element. It would be great if SFML could get this internally done and also on mobile platforms for SFML 3.

[migizi]

I'm just getting started with SFML but I'll put in my 2 cents so far.

C++11 required
OpenGL 3.2+ Core Profile (for desktop OGL).

Both of those offer performance improvements right off the bat. Mesa already has OGL 3.3 support so I think it's getting to that time when we drop legacy OGL and compatibility profiles.

[Ixrec]

@dk123: There is an extension called sfeMovie for playing videos with SFML.

[slotdev]

My vision is: not breaking the codebase on which I have done many, many projects which need maintaining

[slotdev]

I'm just getting started with SFML but I'll put in my 2 cents so far.

C++11 required
OpenGL 3.2+ Core Profile (for desktop OGL).

Both of those offer performance improvements right off the bat. Mesa already has OGL 3.3 support so I think it's getting to that time when we drop legacy OGL and compatibility profiles.

I disagree - there are still a huge number of PCs out there with "legacy" OGL. Implement the new features of 3.3+ by all means, and allow people to use them, but don't break it for people who don't have modern systems.

[migizi]

I disagree - there are still a huge number of PCs out there with "legacy" OGL. Implement the new features of 3.3+ by all means, and allow people to use them, but don't break it for people who don't have modern systems.

If you watch Valve during the Steam Dev Days their hardware survey shows very little legacy hardware out there. Unless you are dealing with Intel cards that are pre 2012 then you'll have core profile support.

If SFML does hardware acceleration off the bat then I'm guessing they have OGL code in use. If you allow the foundation to switch between core profile and legacy then they need to maintain multiple back-ends. Why wouldn't it work to just use SFML < 3.0 for legacy stuff?

It's also been stated that SFML 3.0 is a ways out. Are you saying that by the time 3.0 comes out you are still going to be dealing with a "huge" number of people who can only run OGL 2.1?

To me it doesn't make sense to push for newer technology but leave some parts old because some people might need it. I would think it would be easier to back port some bug fixes to the 2.x branch and make 3.x completely modern.

I realize right now there is probably a lot of people with pre 2012 Intel GPUs, but we are talking the future. It would be naive to think people won't ever upgrade their hardware, let alone people who play games.

If SFML doesn't have any OGL code in use then specifying the context is good enough. It only matters if they use OGL code for the graphics module. If they don't then this whole post is moot.

[binary1248]

I think people are jumping to conclusions too fast regarding legacy OpenGL support.

It is clear that restraining SFML purely to legacy OpenGL is probably not a good idea going forward, but that doesn't mean that SFML will have to completely drop legacy OpenGL support. The nice thing about OpenGL is that it has a (more or less) simple way of probing the hardware for capabilities. Most of the rendering currently done by SFML is agnostic of which API (legacy or modern) it is using. It will work with both.

This does not mean that using the modern API will not be better (faster) than the legacy API. I know from experience that AMD themselves are replacing hardware support for legacy API calls with software emulation, which is the reason why many older OpenGL games (e.g. older Id Tech games) show horrible performance with the latest drivers, requiring workarounds to restore the original performance.

That is one reason (even if a really stupid one) to slowly move forward with adoption of a more modern rendering implementation. Vendors will eventually cease to support the legacy API performance-wise. This is however not a problem for older hardware because chances are, they will use old drivers as well because newer drivers don't support them any more anyway.

The question people might be asking: How can SFML support the same uniform feature set regardless of the underlying rendering implementation?
The answer is simple: The features that SFML currently supports are so general that they are supported regardless of what API is used (this includes a possible DirectX implementation as well). SFML will never have to support any of the more "advanced" features that are only possible with modern APIs because such features are too specific to actually benefit enough users to justify supporting them in mainline SFML. This doesn't rule out any extensions that people might write, but those will come with their own requirements.

The message is: Don't worry about SFML dropping legacy OpenGL support. If we go ahead and abstract the rendering a bit more, whether it uses legacy OpenGL, modern OpenGL or even DirectX it won't make too much of a difference that we will have to even consider dropping support for legacy OpenGL. These things can all co-exist as support for them is not mutually exclusive in contrast to what certain big-name vendors might have you believe (looking at Microsoft's policy of only rolling out support for newer DirectX with newer versions of Windows ).

[slotdev]

If you watch Valve during the Steam Dev Days their hardware survey shows very little legacy hardware out there. Unless you are dealing with Intel cards that are pre 2012 then you'll have core profile support.

But this is SFML, and unless I am mistaken (I hope that I am!), it is not used for high end games such as you would get from proper game studios?

Why wouldn't it work to just use SFML < 3.0 for legacy stuff?

Because the maintainance of the library becomes an issue - who is spend time fixing bugs on 2.1?

It's also been stated that SFML 3.0 is a ways out. Are you saying that by the time 3.0 comes out you are still going to be dealing with a "huge" number of people who can only run OGL 2.1?

Yes, on nearly 63,000 systems to be precise. Some very old systems (Intel Extreme Graphics!) can only use OGL 1.0! We use SFML commercially, and need to support these legacy systems. Sure, they will be phased out over time, but we are talking maybe 3 years from now - minimum.

I realize right now there is probably a lot of people with pre 2012 Intel GPUs, but we are talking the future. It would be naive to think people won't ever upgrade their hardware, let alone people who play games.

There are a heck of a lot. You're forgetting that SFML lends itself very well to automated systems, and I know for a fact that it is used in kiosk, ATM & vending applications.

[migizi]

Well slotdev you pointed out the flaw in my assumptions. I don't think about all the industries that some of these libraries are used in. I tend to stay in my confined game programming bubble.

When you step outside the boundaries of game development then the range of hardware you have to support varies greatly.

But I think binary1248 put the argument to rest by saying that the man power and work required to abstract out the graphics section isn't a concern. I just want to make sure that we can continue to advance without stretching the resources too thin.

If I can have the option to use the core profile for the graphics module I'll be happy (not just creating the context but the built in hardware acceleration as well). For me legacy support isn't a concern like it would be for developers like slotdev.

[Nexus]

slotdev, those applications sound really interesting. Do you see other SFML modifications that could affect the mentioned systems, such as moving from C++98 to C++11?

Maybe in general, are there many people bound to compilers that don't even support basic C++11 (i.e. VS <2010, g++ <4.6)?

[Tank]

I can understand that old systems have to be maintained, but what's wrong with staying at an older SFML version if that's what's already working?

[slotdev]

slotdev, those applications sound really interesting. Do you see other SFML modifications that could affect the mentioned systems, such as moving from C++98 to C++11?

Maybe in general, are there many people bound to compilers that don't even support basic C++11 (i.e. VS <2010, g++ <4.6)?

There are for sure, in more industrial/commercial environments, a lot of people still use VS2008. Personally, I still use VS2005 for "systems" development and VS2010 for actual application (game..) development. So, enforcing C++11 could be a problem.

I worry we will lose the "S" in SFML.

Talking about industrial applications; you have to remember that replacing many thousands of PCs is very expensive - not only in the cost of the hardware, but the time and people required to do it. That is why it takes many years to update. Our oldest system we have to support is an Intel Celeron II based PC with 32mb VRAM. This is a nightmare, but we must do it.

Tank - the problem is more of a support one. If there is a major bug discovered, who is going to fix it? There is no incentive for people to work on 2.1 or whatever when 3.0 is the focus.

[eXpl0it3r]

There are for sure, in more industrial/commercial environments, a lot of people still use VS2008. Personally, I still use VS2005 for "systems" development and VS2010 for actual application (game..) development. So, enforcing C++11 could be a problem.

I worry we will lose the "S" in SFML.

The "S" in SFML stands for "Simple" and the "Simple" stands for simplicity in usage. It's not meant as "simply backwards compatible with 10+ years old hardware".
C++11 has changed C++ itself a lot, but at best it simplifies programming with C++ itself. As such a move to C++11 will enforce the "S" even more.

Talking about industrial applications; you have to remember that replacing many thousands of PCs is very expensive - not only in the cost of the hardware, but the time and people required to do it. That is why it takes many years to update. Our oldest system we have to support is an Intel Celeron II based PC with 32mb VRAM. This is a nightmare, but we must do it.

To be honest, it's not SFML's concern at all, how a company spends their money and whether it's too expensive to upgrade or not. SFML is free and open source, it's nice that it gets used in various commercial products, but it's not something that needs to constrain the software itself. The "problem" here is not that SFML is moving forward, but the problem is that a company is trying to save money (nothing against you or company of course! ).
If SFML was owned/developed by your company everything would look different, but as in the past SFML will go its way in-depended of the needs of corporation.

Tank - the problem is more of a support one. If there is a major bug discovered, who is going to fix it?

At one point we as an SFML Team will move on, as it has happened with SFML 1.6. When this happens there won't be anyone that fixes issues of old versions for free, especially not if it's for a company.
Is it particularly nice? Probably not. Will it upset some people? Probably yes. Keep in mind however that's how things work all over the world. As an example just take Windows XP. Guess how many million machines still run on XP and yet Microsoft has cut-off support for it. Companies have offered millions of dollars to keep up support for Windows XP, but Microsoft declined.
With SFML as being open source you get a lot more options once you hit an issue:

• Offer something enough valuable to the SFML Team, so we might consider fixing it.
• Pay some random developer to fork SFML and fix it.
• Fork SFML yourself and fix it.

Overall, you should not forget that everything we do here, is done for free.

There is no incentive for people to work on 2.1 or whatever when 3.0 is the focus.

The focus is still on SFML 2.x, this thread is merely here to gather what people envision SFML 3 to be, so we can create some sort of roadmap for SFML 2.x as well as SFML 3.x. As such it's kind of pointless discussing that new versions of SFML wouldn't work for you. First we need to figure out what the new version of SFML will be.

[Tank]

Tank - the problem is more of a support one. If there is a major bug discovered, who is going to fix it? There is no incentive for people to work on 2.1 or whatever when 3.0 is the focus.

I can perfectly understand that, however it's important to also understand that SFML does not offer any guaranteed support. You will have to choose between options eXpl0it3r mentioned.

Though we try hard to maintain backwards-compatible as much as it makes sense, of course.