SFML 3 - What is your vision?

[slotdev]

As such a move to C++11 will enforce the "S" even more.

..and people who don't use C++11 will have to go and learn a whole new set of skills. A good thing, but you're only going to get questions from people who don't know it inside out. Allow it, but don't enforce 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.

Indeed. But there are real people who want to make games or whatever using SFML, who maybe don't have much money, and so buying new hardware also isn't an option.

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

I know, but also remember that there are companies and individuals who donate hundreds, if not thousands of Euros every year to allow the purchase of hardware, etc, which also allows the project to continue...

[select_this]

I know, but also remember that there are companies and individuals who donate hundreds, if not thousands of Euros every year to allow the purchase of hardware, etc, which also allows the project to continue...

If someone was bankrolling the development of SFML I'd sympathise with this argument, but as it stands it's a little too indirect.

I'm not even sure how you'd enforce the end user to use C++11 anyway; SFML's ultimately a library, not a framework.

EDIT: forgot to mention that overall I'm sympathetic to your viewpoint, though I don't share the same concerns.

[Laurent]

Supporting C++11 will allow nice additions, but it won't replace many things. After this change, I think you'll still be able to write a program that uses mostly C++98, if you want to.

Regarding backward compatibility and maintenance of older versions, it's true that we'll move forward and focus on improving the latest versions, but I think it would be wise to spend some time back-porting bug fixes to the latest revision of the previous major version (i.e. 2.x after 3.0 is out). If we want SFML to be used in the real world, and not only for short-term small projects, we have to care a minimum about backward compatibility, and not abandon users who would not stick to the latest version. So where should the limit be? I don't know, but this should definitely be discussed.

[eXpl0it3r]

Supporting C++11 will allow nice additions, but it won't replace many things. After this change, I think you'll still be able to write a program that uses mostly C++98, if you want to.

Regarding backward compatibility and maintenance of older versions, it's true that we'll move forward and focus on improving the latest versions, but I think it would be wise to spend some time back-porting bug fixes to the latest revision of the previous major version (i.e. 2.x after 3.0 is out). If we want SFML to be used in the real world, and not only for short-term small projects, we have to care a minimum about backward compatibility, and not abandon users who would not stick to the latest version. So where should the limit be? I don't know, but this should definitely be discussed.

If it can be done easily/nicely then sure. So yeah we'll have to discuss this in detail.

..and people who don't use C++11 will have to go and learn a whole new set of skills. A good thing, but you're only going to get questions from people who don't know it inside out. Allow it, but don't enforce it.

The discussion around C++11 is only whether the compiler has to support it or not. As for using SFML's public API you most likely won't have to know C++11, but if you do, you might be able to write more performant and nicer code.

Indeed. But there are real people who want to make games or whatever using SFML, who maybe don't have much money, and so buying new hardware also isn't an option.

Yes, unfortunately we can't limit innovation to support someone's old hardware. I mean we're working for free and try to listen as much to the community as possible, so if there's anything specific that wouldn't work for someone, we'll try to find a satisfying solution for both sides.
If you think that's not enough, then I might point you to the commercial sector, where everything is done based on profit. Have you seen AMD, Nvidia or Intel releasing new drivers for dead old hardware?

I know, but also remember that there are companies and individuals who donate hundreds, if not thousands of Euros every year to allow the purchase of hardware, etc, which also allows the project to continue...

Again, not really a concern regarding SFML's development. If we would calculate all the time Laurent and all other developers of SFML spent on developing and supporting this project and multiply it with a "normal" senior developer salary, the cost on hardware would rather quickly shrink in comparison.

Just out of curiosity, if you're allowed/willing to tell us. Which company do you work for? In what kind of kiosks does SFML get used?
I mean in the end, one could always discuss/think about something like a partnership - libraries that are backed by companies often gain in popularity and over all code quality. Not that this is in any way my decision to make, just thought I throw it out there.

[slotdev]

Just out of curiosity, if you're allowed/willing to tell us. Which company do you work for? In what kind of kiosks does SFML get used?
I mean in the end, one could always discuss/think about something like a partnership - libraries that are backed by companies often gain in popularity and over all code quality. Not that this is in any way my decision to make, just thought I throw it out there.

I'm the CTO of Betdigital in the UK. We're a small team - 5 coders (inc myself) and 4 artists. We develop casino style games for gaming terminals and online casinos, etc. Google us

We would almost certainly support SFML financially on a more permanant basis. Laurent and I have kind of discussed this in the past, and it's something I have on my list to sort out this year, especially since we are moving towards mobile games more and more. With the port to Android and iOS, it makes SFML even more attractive for commercial use, and so we have an obligation to support it as best we can.

[migizi]

I think that commercial support would greatly help, even if it isn't on the scale of Valve and SDL. Competition is healthy and SDL and SFML do similar things but with different goals. I was using GLFW before I came to SFML but I made the switch because SFML will save me some time on my current project.

I don't know how popular https://www.bountysource.com/ is but it could benefit SFML if people are willing to put bounties on bugs and features. Might get us to version 3.0 a little sooner

[eXpl0it3r]

I don't know how popular https://www.bountysource.com/ is but it could benefit SFML if people are willing to put bounties on bugs and features. Might get us to version 3.0 a little sooner

As seen here we don't have the money to do that.

[migizi]

As seen here we don't have the money to do that.

I didn't mean SFML do it directly. I'm mean people outside the dev team put out bounties, just like the commercial support option. We obviously can't enforce any of that but maybe by mentioning it in the forum it will be brought to the attention of people who are looking for certain fixes or features.

[slotdev]

I think this thread is going a bit OT (probably my fault in a lot of ways) but its a good debate to have.

If the SFML community can get its heads together and decide what it wants, with some solid reasons *why* it wants it and what it needs (both in time and money) to achieve the goals, then I can certainly look to get some funding in place.

..and no, buying everyone a new tablet isn't an option. Buying core developers one, however, certainly is.

[migizi]

I'm wondering if it wouldn't be helpful to find another way to gather all the feature requests into an area people can vote on. Like GOG.com does with their community. It would still be up to the developers but I think that would help point the library in a direction that benefits the most people.

[Nexus]

I personally prefer the current way of publicly discussing features and bringing rational arguments for or against it -- number of people (or clicks, even worse) is not the best indicator of the importance of a feature. Furthermore, voting systems tend to be biased (either by rewarding high ranked entries and punishing low ranked ones, or by leading to political rather than rational campaigns, or by not accounting for the fact that number of votes and number of actual people interested need not be equal).

[binary1248]

For those who are interested, Epic recently made public their UE4 Roadmap and enabled voting to gauge community interest in certain features. According to them, voting alone doesn't directly influence what gets higher priority but it does factor into their planning updates.

While I do agree with Nexus that voting for features shouldn't be the dominant metric, it would provide feedback where it is needed. Right now, we only have this thread to gauge what people want to see in SFML 3, but there is no way to tell what the people who didn't post here might want or be interested in. They might support some of the points already mentioned here but just didn't voice it for fear of making a redundant post (it is coming to the point where most of the new posts mention things that were already mentioned before). Forums aren't a good way to tally the support for certain things anyway, unless a poll is opened. But with this many things to vote on, a poll will also become overly complex.

And about the second point: Voting always tries to be representative. Just like elections in real life, not everybody goes and votes. It takes way more effort than voting for something online, and most of the time your vote doesn't seem to make a difference to your daily life anyway . This would not be the case if we went ahead and tried something for SFML. Surely not everybody using SFML will vote, but the same applies: we can only hope it will be representative. If you think you are part of a minority group, then the best thing to do to show your interests is go and vote .

Disclaimer: The fact that I encourage voting has nothing to do with me being Swiss.

[migizi]

If you've seen GOG.com and their community voting each idea has a vote counter and then comments. I don't know if there are any easy to deploy options for this but it may be an option. It gives people the ability to easily search and add features and discuss them.

With that option each feature would have it's own discussion so that items are not lost in the shuffle.

But in the end it's about creating a useful tool within the constraints of the development teams time and effort. Even GOG has features that have been sitting at number one for a long time but they haven't had the time, power (man or influence), or some other reason to add them. I'm sure we all understand that we are using a library created by people volunteering their time and effort.

I'll admit when I looked at this thread I only looked at the first couple of a pages before replying. It's become rather larger and hard to get started on if you jump into the mix now.

[Jebbs]

I'm not sure how beneficial this would be, but after reading some of the suggestions here, and reading many of the ones found in the regular Feature Request area, I was thinking that it might be useful to have some sort of structured way of suggesting features. People seem to just keep shouting out "feature xyz" and that's about it. That's cool and all, but it sometimes leaves the devs thinking, "what the heck is xyz?" or maybe, "who would need such a feature?" We all like to see complete and minimal code examples, why not complete and minimal feature requests? Something like:

Name of the feature.

What it is(if it might not be self explanatory by the name).

Why you think it should be added and/or a use case scenario.

Having all this information will probably be beneficial for a lot of reasons. Just my two cents.

[Nexus]

I totally agree with you, Jebbs. We're currently developing some general guidelines for contribution. This concerns not only the feature request, but the whole process: suggest, discuss, submit pull request, edit, etc.