Suggestions

[eXpl0it3r]

Do you have an SFML development topic that you think should be discussed?
Feel free to leave a suggestion below!

But first, make sure to read and understand the following points:

• Features requests belong into the feature requests forum!
  
• This is a list of discussion topics, not what will be included in/applied to SFML 3.
• Avoid any kind of discussion in this thread.
• Make sure the topic wasn't already discussed.
• Make sure the topic wasn't already suggested.

Discussed Topics
General

• C++ standards
  

System

• Standard equivalents for sf::Time/sf::Clock
  
• Standard equivalents for sf::Mutex/sf::Lock/sf::Thread
  
• sf::NonCopyable and =delete
  
• Replacing/refactoring of streaming classes

Window

• Clipboard support
  

Graphics

• sf::Font: Abstraction and Bitmap Fonts
  
• How should SFML handle non-legacy shaders?
  

Suggested Topics
General

• Unified way to handle cross-platform code
• Different platforms (Windows Phone, Xbox, PS4, Web)
• Unit testing
• Error handling

System

• General loading/saving facilities

Window

• Better/modular backend/context handling
• Separate the contexts out from the Window
• Support multi-monitor setups
• Allow style/state changes without recreating window
• Improve keyboard handling
• Improve the joystick handling
• Full/better support for High-DPI displays and DPI awareness

Graphics

• Aggregation instead of inheritance-based design
• Investigate support for complex text layouts
• Make CircleShape, RectangleShape, and ConvexShape only be shapes, not drawables

Audio

• Single sound class with different resource backends (buffered or streamed)
• sf::AudioContext

Network

• Make the network module more attractive before std::asio or similar comes out (see also SFNUL)
• Make sf::Packet more flexible/generic
• Sending enumerations in sf::Packet
• IPv6
• HTTPS

[DeathRay2K]

How about the status of Android and iOS as supported platforms? Ideally making them first-class platforms alongside Windows, Mac, and Linux. In any case, clarifying SFML's support of them, as the website and documentation is very poor in this regard.

[eXpl0it3r]

As long as we have nobody to actually develop of iOS, we can not make them fully supported platforms, because we would not be able to fix any issue at all.

[sjaustirni]

Maybe this is a bit wild one, but what about a native vector graphics support (maybe using OpenVG)?
It has already been asked about here and here.

I for sure would be interested in this feature, but I have never actually got around to creating an extension for vector graphics support for SFML. Someone did though.

[korczurekk]

IMHO vector graphics aren't widely used feature and SFML is meant to be quite minimalist. It's just a bit too specific feature for Simple and Fast Multimedia Library. Another problem is that we'd either have to use external library to handle this (those are huge, written C or both) or write pretty big portion of code.

[sjaustirni]

Vector graphics is godsend when you're dealing with multiple screen resolutions. That's why the web is moving away from raster where it can, especially when dealing with complicated GUIs.

But you are right that it will probably never be the most popular feature and it comes at price of dealing with additional dependencies.

That's why I said it was just a shot in the wild

[Balnian]

Maybe we could discuss SFML philosophy for multi platform project. Do we want to provide API for write once for all platforms or do we want to provide an API that can use multiple configuration depending on the platform a good exemple would be do we add vector graphic support? This help having all the same assets per platform/resolution (this is a write once for all platform) or do we want everyone to handle themself multiple image resolutions, audio codec ... (Android and IOS have each prefered resolution / codec)
I haven't fully sized the implication of this, it just poped in my head a minute ago, but right now it's a valid discussion point in my head 

[Balnian]

Another point we could discuss is: Do we want SFML to be friendly with threads? And if yes, to what extend (Vulkan for multithreaded render call?, Only some class being thread safe?, Some methods only being thread safe?)?
Modern applications are using more and more threads either to compute more things faster or to make do of weaker core/clock speed (like phone) .
Again, this just poped in my head while i sended my last post so i haven't been thinking about it for long (like max 5 min.) But i think this could be something we can discuss

[Balnian]

Me again, with an upcoming standard C++ 2d library, when it come out, where will SFML stand? Do we still do our own rendering or do we do a wrapper over the std 2d lib?

[sjaustirni]

WTH? upcoming c++ 2D library?
Last time I checked, it wasn't even an actual proposal, just a blog post of some guy, trying to make it to the proposal stage. The whole idea was so ridiculous I told myself that that it was surely not going to make it. Are we talking about the same thing?

Just to clarify, I don't mind that guy, nor the implementation. I don't like the idea. Graphics should not be standardized, should not be a part of standard library, not of a general language like C++. There are simply so many systems to support that are so different that a graphics standardization is completely useless here.

[binary1248]

SG13

P0267R0

[sjaustirni]

Oh, so it made it to being a proposal. Thank you for the info, binary1248.

[oomek]

I would like to discuss adding the support for anisotropic filtering, but I have no permissions to open a thread on the SFML Developement subforum and this thread is not for discussing the features from what I read.

[eXpl0it3r]

This subforum also isn't for feature requests. Check the Feature requests subforum.