A couple suggestions

[GraphicsWhale]

I've used SFML for a while now (used GLFW or SDL before, couldn't get SFML to compile.. then I finally updated my compiler) and I feel like, while it's a great library as a whole, there are a few things that I dislike about it. Decided just to put them in one post.

1. Modern OpenGL. I know this was something that has been suggested before (and likely several times), but this is very important IMO. EDIT: Looking through the rest of the forums, it looks like this request is a lot more common than I thought. Based off of that, I'm guessing this probably wont happen at all, or at least not before OpenGL 112.8 comes out...

2. Put the graphics into it's own class, no drawing directly to sf::RenderWindow. That's just a very weird way to draw things.

3. What's up with the whole sf::Sound|sf::Music thing? I know the difference, but the names suggest how it's used, instead of actual underlying differences. Why not sf::BufferedAudio|sf::UnbufferedAudio, or even sf::Audio|sf::AudioStream, just something meaningful. If possible, something like sf::Audio audio(sf::Audio::Stream); would also work.

4. Texture loading (or any asset loading, for that matter) should be in a separate module. Most applications need some library to load their assets (PNGs, WAVs, etc), but not all of them want a fancy, possibly even bloated, wrapper.

5. This is more of an insignificant opinion than anything else, but I'd like to see the window resizeable option during window creation a part of the video mode, not the style. Like this: sf::Window window(sf::VideoMode(800, 600, true), "", sf::Style::Default);. It just seems more natural to put the option for a resizable window alongside the initial window size rather than in the window style.

Can't remember any other things I didn't like. Guess that's a good thing, though.

[eXpl0it3r]

Thanks for the input, it can always be interesting to hear what other people think.

1. Modern OpenGL. I know this was something that has been suggested before (and likely several times), but this is very important IMO.

What exactly do you mean by this? You can use modern OpenGL along side of SFML. What exactly do you gain by having SFML using modern OpenGL internally?

2. Put the graphics into it's own class, no drawing directly to sf::RenderWindow. That's just a very weird way to draw things.

I don't understand what you mean with "put the graphics into its own class". What graphics and what class?
Why is drawing to a window weird?

3. What's up with the whole sf::Sound|sf::Music thing? I know the difference, but the names suggest how it's used, instead of actual underlying differences. Why not sf::BufferedAudio|sf::UnbufferedAudio, or even sf::Audio|sf::AudioStream, just something meaningful. If possible, something like sf::Audio audio(sf::Audio::Stream); would also work.

I guess there will always be different names to pick from and some like to put more emphasis on one aspect and some more on the other. The current names also indicate the most common use.

4. Texture loading (or any asset loading, for that matter) should be in a separate module. Most applications need some library to load their assets (PNGs, WAVs, etc), but not all of them want a fancy, possibly even bloated, wrapper.

There have been discussions about making the resource loading more stream lined, however I don't see how the current implementation is "fancy" or "bloated". If you have it loaded through a different lib, you just pass the data directly yourself.

5. This is more of an insignificant opinion than anything else, but I'd like to see the window resizeable option during window creation a part of the video mode, not the style. Like this: sf::Window window(sf::VideoMode(800, 600, true), "", sf::Style::Default);. It just seems more natural to put the option for a resizable window alongside the initial window size rather than in the window style.

It might be more natural for you, but in the end it is a window style on many OS and not really connected to the video mode.

[GraphicsWhale]

What exactly do you mean by this? You can use modern OpenGL along side of SFML. What exactly do you gain by having SFML using modern OpenGL internally?

I don't really use SFML graphics libraries (though, easy font drawing is useful sometimes), but one significant reason is because it uses deprecated functionality. Sure, I could always do it myself (and I do, most of the time), but nonetheless the purpose of SFML's graphics module is to make simple 2D graphics easier. I don't understand why there can't be a middle ground of easy 2D graphics and non-deprecated functionality.

I don't understand what you mean with "put the graphics into its own class". What graphics and what class?
Why is drawing to a window weird?

Moving the drawing functions from sf::RenderWindow to another class. sf::RenderWindow in it's current state violates the one-purpose rule. Putting it into a class called sf::Graphics  and have a sf::RenderWindow::getGraphics function would be one solution. Especially when you need to call a function to draw something, I'd much rather pass it an object that is specifically for drawing graphics than an object that handles the entire window and draws the graphics.

If anything, what about multi-person projects? It's kinda difficult to ensure someone doesn't mess everything up by relying on having access to modifying the window where they're only supposed to draw graphics. At the moment, there's no way to not pass the window where only drawing to it is appropriate.

I guess there will always be different names to pick from and some like to put more emphasis on one aspect and some more on the other. The current names also indicate the most common use.

I don't believe that's a good enough reason. There are plenty of incompetent programmers out there who are going to do stupid things with SFML that you didn't even think of. Naming two classes based off of their most common usages, rather than what they actually are, is just asking for trouble. Even if their projects don't effect you, if the API is misused in such a way, people will believe that it's "slow to load" or "uses too much RAM". Don't underestimate stupidity.

There have been discussions about making the resource loading more stream lined, however I don't see how the current implementation is "fancy" or "bloated". If you have it loaded through a different lib, you just pass the data directly yourself.

It's not bloated if you're using the entire API. It's bloated if you need to simply load and decode a texture and not use anything else (such as if you want to only use OpenGL) .

[Laurent]

Thanks for the feedback

1. Modern OpenGL.

It is definitely a priority, especially since we've added support for mobile platforms. But I guess it won't be done before SFML 3.

2. Put the graphics into it's own class, no drawing directly to sf::RenderWindow. That's just a very weird way to draw things.

That's something I've personally always had in mind. Getting a graphics context out of a window or a texture, and simply drawing to it, would simplify many things (mainly in bindings). It is currently not so much an issue, but who knows... Again, not before SFML 3 anyway.

3. What's up with the whole sf::Sound|sf::Music thing?

I agree that classes should not be named according to their common usage. However, in this specific context of audio programming, I think that "sound" and "music" already carry the underlying difference (buffered vs streamed). And I would not be satisfied with other names, but that's just a felling.

4. Texture loading (or any asset loading, for that matter) should be in a separate module.

SFML already uses a simple library for decoding images (stb_image). People who need only that can easily find the right library. SFML is not meant to provide this kind of functionality. If there was a sfml-image library, it would just be a stupid wrapper on top of stb_image.

5. This is more of an insignificant opinion than anything else, but I'd like to see the window resizeable option during window creation a part of the video mode, not the styl

Video modes are video modes. They are not just a shortcut for window creation arguments: they can be enumerated, etc. A "resizable" flag would be totally out of topic there.
The "resizable" flag, on the other side, leads to changes in the style of the window (it won't have borders and min/max buttons if not resizable), so it totally fits the style argument.

[Mario]

If anything, what about multi-person projects? It's kinda difficult to ensure someone doesn't mess everything up by relying on having access to modifying the window where they're only supposed to draw graphics. At the moment, there's no way to not pass the window where only drawing to it is appropriate.

Only pass them a sf::RenderTarget* and they won't be able to modify the window (unless they are very nasty and cast it back to a sf::RenderWindow*.

[GraphicsWhale]

It is definitely a priority, especially since we've added support for mobile platforms. But I guess it won't be done before SFML 3.

Given the changes between legacy and modern OpenGL, I understand why it might be delayed until a major overhaul.

Is SFML 3 something that's being planned already, or just a conceptual release version? If you ever do that, along with any significant changes to the graphics system, Vulkan support would be nice (once it comes out).

That's something I've personally always had in mind. Getting a graphics context out of a window or a texture, and simply drawing to it, would simplify many things (mainly in bindings). It is currently not so much an issue, but who knows... Again, not before SFML 3 anyway.

What do you mean?

I agree that classes should not be named according to their common usage. However, in this specific context of audio programming, I think that "sound" and "music" already carry the underlying difference (buffered vs streamed). And I would not be satisfied with other names, but that's just a felling.

That wasn't my line of thinking when I first started messing around with the audio module. I was confused why there would be a class specifically for music. Was SFML self-aware? Could it listen to music? What could it possible be for!? Then I read the documentation and it cleared everything up.

Sound is sound. Mechanical disturbances in the air with a path to the user's ears that can be controlled through a special physical device connected to a computer from which the air disturbances can be controlled through a stream of numerical values. Music is just a "type" of sound. To me at least, the words do not convey any difference in technical meaning.

Maybe I'm looking to much into this...

SFML already uses a simple library for decoding images (stb_image). People who need only that can easily find the right library. SFML is not meant to provide this kind of functionality. If there was a sfml-image library, it would just be a stupid wrapper on top of stb_image.

I did not know about the existence of stb_image. Much better than LodePNG (what I was using before).

Video modes are video modes. They are not just a shortcut for window creation arguments: they can be enumerated, etc. A "resizable" flag would be totally out of topic there.
The "resizable" flag, on the other side, leads to changes in the style of the window (it won't have borders and min/max buttons if not resizable), so it totally fits the style argument.

I suppose the argument that it's less of a "lie" to tell the programmer that it's a style and not a video mode is enough to convince me the API should stay the way it currently is. 

[Laurent]

Is SFML 3 something that's being planned already, or just a conceptual release version?

We already have some ideas for it, but there's no concrete plan yet.

What do you mean?

I mean this:

sf::GraphicsContext& context = window.getContext(); // or texture.getContext()
context.draw(stuff);

[GraphicsWhale]

Just a suggestion (if you ever do implement something like that), but I feel like using Graphics instead of GraphicsContext would be a bit more.. natural. Other than that (regardless of whatever it ends up being named), that seems like it'd be an epic feature to support. Hope it gets implemented sometime before we colonize Mars.

[shadowmouse]

Just to confirm Laurent, were you suggesting that from SFML 3 onwards,

window.draw(sf::Drawable&);

would not work and would have to be replaced with

sf::GraphicsContext& context = window.getContext(); // or texture.getContext()
context.draw(stuff);

or would it just be optional? And how is that better than passing a window as a RenderTarget reference?

[Laurent]

I feel like using Graphics instead of GraphicsContext would be a bit more.. natural

This was just an idea. We'll think about proper names if it's confirmed one day

would it just be optional?

His idea was to clearly separate graphics stuff from window stuff -- which are indeed unrelated. Having each one in its own class would be cleaner, easier to maintain, and easier to use. So it would be a change in the design, not an simple extra option.

And how is that better than passing a window as a RenderTarget reference?

RenderTarget is already an equivalent to the Graphics class, so yes, in this case it is not better, the result will be the same. The main question is: is it better to inherit from this class, and get everything mixed in the final classes, or to be able to construct instances of it from renderable resources?

[shadowmouse]

RenderTarget is already an equivalent to the Graphics class, so yes, in this case it is not better, the result will be the same. The main question is: is it better to inherit from this class, and get everything mixed in the final classes, or to be able to construct instances of it from renderable resources?

If we look at this from the most basic point of view, you can draw on a window. It might well be from an advanced point of view that a window has something that can be drawn to, but from the basic point of view (or the Simple point of view) it seems logical that a window can be a target to render things on, hence it is a RenderTarget and should inherit from it. At least that's what it seems like to me.

[GraphicsWhale]

RenderTarget is already an equivalent to the Graphics class, so yes, in this case it is not better, the result will be the same. The main question is: is it better to inherit from this class, and get everything mixed in the final classes, or to be able to construct instances of it from renderable resources?

If we look at this from the most basic point of view, you can draw on a window. It might well be from an advanced point of view that a window has something that can be drawn to, but from the basic point of view (or the Simple point of view) it seems logical that a window can be a target to render things on, hence it is a RenderTarget and should inherit from it. At least that's what it seems like to me.

The purpose is decoupling.

The window is just the window. It has a size, a position, a title, etc. It's like a "container" for the program to be in. It's a wrapper around the OS's GUI API.

The graphics are the part of the window that contain the visuals for the game. It has nothing to do with the OS's GUI.  It's a wrapper around OpenGL function calls.

Even if "drawing to the window" might sound simpler, it's not a good abstraction between the window and the graphics. The two just aren't related.

[shadowmouse]

I understand that in implementation, they are not related, I was saying that it seems unnecessary to force the split on people to whom it causes no problem, by removing the inheritance of sf::RenderWindow and sf::RenderTarget, seeing as you can already pass around a RenderWindow as a RenderTarget, therefore not allowing people to mess with the window stuff, or you can pass it as a Window, therefore not allowing people to treat it as a RenderTarget.

[therocode]

Just going drop a couple of words in regards to the sf::Audio and sf::Music naming. I totally agree with GraphicsWhale and I find the names very unspecific and confusing. 'Audio' is very broad and includes music, and 'Music' is in some cases also pretty arbitrary, and for someone who hasn't done audio programming at all before, it would not at all be clear why there is such a distinction and what it is for.

Naming them AudioStream and SampledAudio or something similar would make it very clear and would encourage users to understand the basic things you need to consider when doing audio programming and that's a good thing.

[GraphicsWhale]

I understand that in implementation, they are not related, I was saying that it seems unnecessary to force the split on people to whom it causes no problem, by removing the inheritance of sf::RenderWindow and sf::RenderTarget

Depending on how it would be implemented, I have two different arguments about it not actually being a problem:

1. Though it would be much more difficult to implement, if somehow SFML could make it so a common graphics interface class would be capable of being tied to an object, for example, getting a graphics class from a texture, then drawing to the texture with that, then getting the graphics class from the window and drawing the texture to that, this would be a significantly useful feature that cannot, at least cleanly, be implemented in SFML's current state.

2. If the graphics class is essentially a RenderTarget that is associated with the current OpenGL context, while it wont provide any monumental improvements, it would decouple a class that is seemingly concerned with two different tasks: drawing and window management. Doing this wouldn't really a problem, though. It would not only improve the API through decoupling it (making it potentially easier for beginners to learn), but porting code from SFML 2 to a theoretical SFML 3 utilizing this wouldn't be that difficult, because it would only require changing drawing to a graphics class instead of the window class, which can be pulled directly from the window instance.

seeing as you can already pass around a RenderWindow as a RenderTarget, therefore not allowing people to mess with the window stuff, or you can pass it as a Window, therefore not allowing people to treat it as a RenderTarget.

Partially true. But it is still a window, even if casted as a RenderTarget. And this still doesn't fix the decoupling issues. And what if you want to pass the window, but not the graphics? (very rare scenario, but the fix is so simple and beneficial in other scenarios, why not?)