SFML 3 - What is your vision?

[Nexus]

sf::ThreadLocal => no need if sf::Threads become a std::thread ? (not sure what it does)

Not std::thread, but the thread_local keyword

sf::InputStream => std::istream (literally the same)

If it were literally the same, SFML had used std::istream in the first place, as it's no C++11 feature. Read the documentation to see what it does.

Also, some implementations, while they exist in the standard library, are rather low-level and not always well-supported by all compilers (e.g. it took quite long until high_resolution_clock was adopted by MSVC). This is also a point to consider when changing the implementation.

[Balnian]

sf::ThreadLocal => no need if sf::Threads become a std::thread ? (not sure what it does)

Not std::thread, but the thread_local keyword

Not sure to understand...are you talking about http://en.cppreference.com/w/cpp/language/storage_duration

sf::InputStream => std::istream (literally the same)

If it were literally the same, SFML had used std::istream in the first place, as it's no C++11 feature. Read the documentation to see what it does.

I should not have said (literally the same) on this one, but the fact is that you are using it as the base class for all your input with a focus on file input

Abstract class for custom file input streams.

This class allows users to define their own file input sources from which SFML can load resources.

By replacing this with std::istream we would have access to all of the standard library type that inherit from std::istream and the future type coming (C++17, C++20,...) like in C++20 there's the standard networking library that should be ready and if it magicaly have a std::isocketstream we could have without change support for loading assets from a network... (this is a crude and simple exemple, but serve it purpose).
My stand is it would be better to use as much standard library as possible, because it's standard behavior across all platform, there's more chance end user will be able to use new language feature without major change to SFML or a ton of wrapper and  finally because if we use the standard library people will have less stuff to learn to start using SFML, because they should understand the base of the Standard Library, and while learning to use SFML they will learn stuff they will be able to reuse outside of SFML.
And for the low level stuff.... well welcom to C++  and let's just make even more awesome tutorial for SFML 3 that will make it easy to learn that stuff and combined with the current style of the Documentation (with exemples) (seriously SFML Tutorials and Documentation Rocks!!!).

Also, some implementations, while they exist in the standard library, are rather low-level and not always well-supported by all compilers (e.g. it took quite long until high_resolution_clock was adopted by MSVC). This is also a point to consider when changing the implementation.

I'm not following you on this one.... there was multiple intervention on this forum thread about SFML 3 using C++11, and all my implementation replacement use at most C++11 and on top of that all major compiler vendor (GCC, Clang, MSVC) now have stable support up to C++14 language features http://en.cppreference.com/w/cpp/compiler_support we're nearly in 2017.... C++17 is nearly here... C++11 use should not even be in debat right now

[Laurent]

I agree to replace as much as possible with standard stuff.

Using std::istream and std::ostream is something that I really want to do ; it may be harder for people to create specific implementations based on them, but chances are that these implementations already exist (because they are standard), and if needed we could even provide simple wrappers, like boost does.

However...

like in C++20 there's the standard networking library that should be ready and if it magicaly have a std::isocketstream we could have without change support for loading assets from a network... (this is a crude and simple exemple, but serve it purpose).

Keep in mind that most SFML resources need a seekable stream, that network streams will most likely not be. Things won't be as magical as it seems.

Regarding broken standard stuff, I don't think we should provide a totally new API just to replace it. If a workaround is really needed, we could provide our own (optional) implementation of the broken class(es)/function(s), so that we can remove it when it is no longer needed.

[Balnian]

Laurent when will the SFML 3 repository/branch/project be created? Because right now it's only talk and since the standard commitee started having new release every 3 years we should stop waiting decide the max language feature you want to use (C++11,C++14,C++17,C++20?) and start from here.

like in C++20 there's the standard networking library that should be ready and if it magicaly have a std::isocketstream we could have without change support for loading assets from a network... (this is a crude and simple exemple, but serve it purpose).

Keep in mind that most SFML resources need a seekable stream, that network streams will most likely not be. Things won't be as magical as it seems.

Yeah... but it was just a simple exemple to illustrate  an advantage (and i didn't knew of another feature coming in the futur that might use an std::istream

BTW std::istream is a seekable stream and every child that inherit from it (except if you do a really messed up implementation overloading and even in this case you would still be able too call seekg)

[Mario]

With all the talk about std::stream, don't forget that there also is still the need for being able to access virtualized file systems as well (at least on Android for assets; not sure about iOS).

Also about "let's use standard stuff instead": I fully agree, but you also have to admit that some standard library stuff feels horribly overcomplicated compared to what SFML provides or provided in regards to simplicity, especially for beginners. I think the former sf::Randomizer would be a typical example for me compared to what C++11 provides.

[korczurekk]

Also about "let's use standard stuff instead": I fully agree, but you also have to admit that some standard library stuff feels horribly overcomplicated compared to what SFML provides or provided in regards to simplicity, especially for beginners. I think the former sf::Randomizer would be a typical example for me compared to what C++11 provides.

Well, C++11 stuff is way more flexible than that horrible sf::Randomizer. And TBH it isn't really the case we are talking about, C++'s std::random_device, std::default_random_engine and all those distributions are rather small and designed to do one thing each, sf::Randomizer did everything and provided simple interface. I'd actually like to see it rewritten with C++11, somehow like that:

template <class engine_type>
class Randomizer {
        std::uint_fast32_t m_seed;
        engine_type m_engine;

        Randomizer()
                : m_seed { std::random_device{}() }
                , m_engine { m_seed }
        { }

public:
        void setSeed(std::uint_fast32_t seed) {
                m_engine.seed(seed);
                m_seed = seed;
        }

        std::uint_fast32_t getSeed() {
                return m_seed;
        }

        /* Simple, default function */
        float random(float begin, float end) {
                return std::uniform_real_distribution<float>(begin, end)(m_engine);
        }

        /* More flexible alternative */
        template<typename value_type, template<typename T> class distribution_t>
        value_type random(value_type begin, value_type end) {
                return distribution_t<value_type>(begin, end)(m_engine);
        }

        /* Simplified version of code above – takes class
        instead of template as template parameter */
        template<typename value_type, class distribution_t>
        value_type random(value_type begin, value_type end) {
                return distribution_t(begin, end)(m_engine);
        }

        static Randomizer<engine_type>& getInstance() {
                static Randomizer<engine_type> obj;
                return obj;
        }
};

static Randomizer<std::default_random_engine>& getDefaultRandomizer() {
        return Randomizer<std::default_random_engine>::getInstance();
}

[Tex Killer]

Hey guys, can someone update me on the status of the SoundFile class? Has it been made public yet?

I'm still using the same modified 2013 SFML snapshot to do audio loop points. I think Laurent said once that SoundFile would be made public so that I wouldn't have to modify SFML sources for that.

[Laurent]

Yes, these classes are public now. We even have support for loop points pending (I don't know if it has been merged into master yet).

[Tex Killer]

Yes, these classes are public now. We even have support for loop points pending (I don't know if it has been merged into master yet).

Cool, thank you Laurent! 

[Syndog]

I must say, this thread fascinates me. 

It's quite a success, in the sense that I see wishlists and suggestions aplenty over its 300+ posts written over 3 years, many of which I wholeheartedly endorse.  Kudos to those who contributed their thoughts, and to the creators for asking in the first place.

What concerns me is the wealth of time and energy that was spent dismissing suggestions as impractical or beyond scope.  Granted, some fall into these categories for good reason, but in all of these posts, I don't recall seeing anyone in authority publicly saying, "That's brilliant, let's add it to the list."  Not once.  It leaves me with the impression -- rightly or wrongly -- that the powers-that-be are less interested in hearing the community's vision for SFML 3 than maintaining the status quo.  I find that quite distressing.

I've kept a casual eye on SFML for just over 4 years now, and I honestly find it to be one of the best written open source projects I've ever come across, in or out of game development.  I'd love to build a game framework on top of it.  The only thing holding me back is this perpetual holding pattern it seems to be in, and threads like this make it seem as if those in charge just aren't interested in breaking out of it. 

So, I'd like to give the creators an opportunity to address this by turning the thread's question back on them.  What is YOUR vision for SFML 3?  Did you find any worthwhile ideas in this thread?  If so, what are they?  Have they been added to the roadmap for SFML 3?  IS there a roadmap?

Thanks for your time and effort.

[Hiura]

Glad you like the discussion. :-)

We have some sort of roadmap here: https://en.sfml-dev.org/forums/index.php?topic=21542.msg153137#msg153137 I think you'll find many of the wishes made in this thread on the roadmap. But it's not frozen of course so if you/someone think/s something is missing, let us know.

My personal top 3 priorities for v3 would be: 1) a more modern API & implementation, less platform specific code if a standard version exists; 2) more Input APIs (e.g. Screen, Touch/Pen, ...) -- in other word, a better integration with common input system available with modern OSes; 3) more community PR.

I think this last point would really help make SFML better with faster progress. It's obvious that the core team has many things to do and many other activities besides SFML, so if we could delegate more to the community that'd be awesome.

It leaves me with the impression -- rightly or wrongly -- that the powers-that-be are less interested in hearing the community's vision for SFML 3 than maintaining the status quo.

That's a fair critic and we should definitely improve on that. For the record though, this impression is incorrect: we really value community feedback -- granted that only extremely convincing and well developed arguments will convince us that a new feature indeed fits SFML scope.

[Syndog]

We have some sort of roadmap here: https://en.sfml-dev.org/forums/index.php?topic=21542.msg153137#msg153137 I think you'll find many of the wishes made in this thread on the roadmap.

Thank you for the link!  This is exactly what I was hoping to see, mainly because it contrasts with what this thread exhibits.  I'm still feasting on much of the contents under discussion, and expect to be for some time.  Brain food, as it were.   

. . . 3) more community PR.

I think this last point would really help make SFML better with faster progress. It's obvious that the core team has many things to do and many other activities besides SFML, so if we could delegate more to the community that'd be awesome.

I agree.  Do you have anything specific in mind?  How can I help?

Thank you for sharing your thoughts, Hiura.  I appreciate it.

[Hiura]

It's clear that submitting a PR is a lot of work and therefore requires a lot of free time as well as a deep understanding when it comes to complex bug fix or new feature implementation. So it's not easy for everyone to help with that. However, testing existing PR should be fairly straightforward for anyone. So if you, or anyone else for that matter, want to chip in without spending hours and hours, just pick an open PR and give some feedback on it. It can be as simple as "it does (not) fix the bug on my system" and this would be already highly welcome. :-)

Then, of course, if one want to really invest themselves into SFML, we have a detailed procedure for contribution: https://www.sfml-dev.org/contribute.php

[fastrgv]

Just noticed this great thread...
My personal top priority would be for a future SFML to avoid OpenGLv3.3-deprecated functions so that it is possible to use a core profile "modern" OpenGL of at least version 3.3.
Rod

[Sub]

This is a nice thread.

The only thing I want is better multi-monitor support, as I've run into a few issues with this on both Linux and Windows.   Sounds like this is already on the agenda though.