-
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.
-
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. ;)
-
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) .
-
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.
-
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*. :)
-
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. :)
-
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);
-
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. :)
-
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?
-
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?
-
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.
-
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.
-
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.
-
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.
-
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?)
-
Naming them AudioStream and SampledAudio or something similar
I don't think "Sampled" means what you think it means. All digital audio is made up of samples. The point is that one is streamed, and one is buffered. Hence why I proposed the names BufferedAudio and UnbufferedAudio. Though, I suppose the names BufferedAudio and StreamedAudio sound better now that I think about it.
-
I agree with the use of StreamedAudio and BufferedAudio. Just a thought but might they be included before SFML 3 with typedefs for Sound and Music so as not to break existing code and a note in the docs to say Sound and Music are depreciated?
-
Is it really a concern? The differentiation between "sound effects" and "music" is not only fairly common, but corresponds exactly to the way the classes are used. I don't see a need to change anything here. Apart from the fact that "StreamedAudio/BufferedAudio" are quite clumsy for something so basic.
Anybody learning about sf::Sound and sf::Music must read the tutorial anyway, and their semantics are explained in a few sentences. After that, what they mean is clear for eternity, and people can use simple terms. You don't punish the thousands of people who are okay with "music" and "sound" by making their code less readable.
-
Anybody learning about sf::Sound and sf::Music must read the tutorial anyway, and their semantics are explained in a few sentences. After that, what they mean is clear for eternity, and people can use simple terms. You don't punish the thousands of people who are okay with "music" and "sound" by making their code less readable.
That's a good point, which by the way is basically what I was thinking about the seperation of window and graphics, why punish the many when you already have sf::RenderTarget sf::RenderTexture which solve the problems of the few?
-
I know the suggestion of replacing Sound/Music has already been.. "dissolved" (not sure what word to use) in this thread, but I still think it's a good idea.
Is it really a concern? The differentiation between "sound effects" and "music" is not only fairly common, but corresponds exactly to the way the classes are used.
Not all sounds may benefit from buffering and not all music will benefit from streaming. Most of the time they are, but most isn't always. It can be quite ugly when you need to use a Sound for something that's not a sound effect, or Music for something that isn't Music.
Effectively, the difference is rather "Should I cache this, or stream it?", not "Is this music, or a sound effect?", so I consider the names semi-misleading.
Is it really a concern? The differentiation between "sound effects" and "music" is not only fairly common, but corresponds exactly to the way the classes are used.
A large sound effect that is only played once benefits from being a Music, but it's not music. A short tune that is constantly re-used benefits from being an Sound, but it's not a sound-effect.
I don't see a need to change anything here. Apart from the fact that "StreamedAudio/BufferedAudio" are quite clumsy for something so basic.
What you see as "clumsy" I see as self-explanatory class names.
Anybody learning about sf::Sound and sf::Music must read the tutorial anyway, and their semantics are explained in 2 sentences.
What about the people who think they're too good for documentation? Even if they don't want to learn, it's not always a bad idea to give some sort of hint of the differences in the name.
After that, what they mean is clear for eternity, and people can use simple terms.
Why not simple and self-explanatory names?
You don't punish the thousands of people who are okay with "music" and "sound" by making their code less readable.
???
-
Anybody learning about sf::Sound and sf::Music must read the tutorial anyway, and their semantics are explained in a few sentences. After that, what they mean is clear for eternity, and people can use simple terms. You don't punish the thousands of people who are okay with "music" and "sound" by making their code less readable.
That's a good point, which by the way is basically what I was thinking about the seperation of window and graphics, why punish the many when you already have sf::RenderTarget sf::RenderTexture which solve the problems of the few?
What's so "punishing" about decoupling a class that serves two purposes into two different classes?
-
Because you're replacing a simple self explanatory window.draw() with the creation and use of a graphics constant, which is extra work for no gain for most people. Also, on the point about abstraction, as SFML abstracts the OS stuff and the OpenGL stuff, it doesn't matter whether SFML's internal call OS or OpenGL, but instead to focus on, is a window something that can be drawn to, or should it just contain something that can be drawn to?
-
GraphicsWhale: you shouldn't underestimate how much simple terms can affect the efforts needed when writing, reading and maintaining code. Basic classes like sf::Sound and sf::Music are always looked up before usage, they don't behave like function names where the name already tells everything about the semantics. So, "self-explanatory" is not as much a gain as it seems to be.
A very good case to demonstrate what I mean is the Android API. They have some terms that are deliberately simple, yet not self-explanatory. "Intent" (http://developer.android.com/reference/android/content/Intent.html) is such an example -- an intent is an operation, usually a message dispatched to activities. Nobody has an idea what "intent" means before reading the documentation. Yet, it is a well-chosen name, because it creates a concise domain-specific vocabulary. When people talk about intents, every Android developer knows what they mean, much more than "operation/message between activities".
Imagine they had called it "ActivityMessage". It would not only be more wordy to talk about, but it would make all the related features overly clumsy. "IntentFilter" would be "ActivityMessageFilter", already long methods like "startIntentSenderForResult" would become "startActivityMessageSenderForResult". Additionally, it's more difficult to differentiate it from the existing "Activity" and "Message" classes as well as all the methods containing either in their names. When reading code, you need considerably more time to parse and semantically interpret what's written, when terms are longer and more similar to each other.
-
Because you're replacing a simple self explanatory window.draw() with the creation and use of a graphics constant, which is extra work for no gain for most people.
The suggestion was to implement something like this:
sf::Graphics& graphics = window.getGraphics();
graphics.draw(shape);
In opposed to just calling the window (which is just plain wrong). There are no constants.
Also, on the point about abstraction, as SFML abstracts the OS stuff and the OpenGL stuff, it doesn't matter whether SFML's internal call OS or OpenGL stuff
You don't need to decouple everything down when it can work without it, but it creates a simpler, more modular design. Especially when you're mixing a class from one module (Window) with a class from another module (RenderTarget) through inheritance to create some mutant multi-purpose object, that is, RenderWindow.
it doesn't matter whether SFML's internal call OS or OpenGL, but instead to focus on, is a window something that can be drawn to, or should it just contain something that can be drawn to?
But why draw to an object that's suppose to be managing the window, in oppose to a class that's managing the graphics? I mean, technically RenderWindow is both a window and a graphics class, but that's not necessarily a good thing.
-
But why draw to an object that's suppose to be managing the window, in oppose to a class that's managing the graphics? I mean, technically RenderWindow is both a window and a graphics class, but that's not necessarily a good thing.
I can't really explain what I'm saying any more other than just saying, because the window is where the things you draw are shown, therefore, you are drawing to the window/
-
you shouldn't underestimate how much simple terms can affect the efforts needed when writing, reading and maintaining code.
Not all code is going to have the best names. Lack of punctuation, spaces (there's underscores, but nobody uses those for class names), only being able to fit into so many characters, and each name has to be unique.
But it's also important to not make assumptions about the class's usage, only what the class is, and it has to be minimalistic and clear. There are scenarios where it isn't possible, but it has to be really justified to not use a proper name. Using "File" to represent a file in the filesystem is ok, but using "SaveGame" to represent the same thing just because you believe that's what people will use it for is not ok.
Maybe you have a different way of thinking, but I don't agree with it.
Basic classes like sf::Sound and sf::Music are always looked up before usage, they don't behave like function names where the name already tells everything about the semantics.
You are assuming the programmer is going to immediately jump to the documentation when they see the two classes. Likely, they'll just pick one class, figure out how to use it, then stick with it. They both appear to do the same thing, so why would they care otherwise? The classes give so little detail in their names about the difference that even a seasoned programmer might just stick with, say, Sound, because they might be led to believe that this mystical "Music" doesn't actually have to do with playing audio.
So, "self-explanatory" is not as much a gain as it seems to be.
Theses, .. "inconveniences"(?) you speak of in my suggested naming scheme are likely more negligible than the benefits of changing it. This is especially true if in the future, if a large overhaul were to occur anyways.
A very good case to demonstrate what I mean is the Android API. They have some terms that are deliberately simple, yet not self-explanatory. "Intent" (http://developer.android.com/reference/android/content/Intent.html) is such an example -- an intent is an operation, usually a message dispatched to activities. Nobody has an idea what "intent" means before reading the documentation. Yet, it is a well-chosen name, because it creates a concise domain-specific vocabulary. When people talk about intents, every Android developer knows what they mean, much more than "operation/message between activities".
Imagine they had called it "ActivityMessage". It would not only be more wordy to talk about, but it would make all the related features overly clumsy. "IntentFilter" would be "ActivityMessageFilter", already long methods like "startIntentSenderForResult" would become "startActivityMessageSenderForResult". Additionally, it's more difficult to differentiate it from the existing "Activity" and "Message" classes as well as all the methods containing either in their names. When reading code, you need considerably more time to parse and semantically interpret what's written, when terms are longer and more similar to each other.
And that's why I don't complain that sf::Event isn't named sf::WindowEvent. There is such a thing as a too detailed name, to the point where it become inconvenient. Especially if it's used often. I don't blame whoever wrote that API. But I find it hard to believe that the audio classes have to be named so often that adding a few additional characters would hurt anything.
-
I can't really explain what I'm saying any more other than just saying, because the window is where the things you draw are shown, therefore, you are drawing to the window/
Let's explain it differently.
Instead of:
sf::Window
sf::RenderTarget
sf::RenderWindow
sf::Texture
sf::RenderTexture
There would be:
sf::Window
sf::Texture
sf::Graphics
Doesn't it look cleaner, more modular and easier to maintain this way?
-
But why draw to an object that's suppose to be managing the window, in oppose to a class that's managing the graphics? I mean, technically RenderWindow is both a window and a graphics class, but that's not necessarily a good thing.
I can't really explain what I'm saying any more other than just saying, because the window is where the things you draw are shown, therefore, you are drawing to the window/
and I suppose because we're simply, interacting with the user, that we should just throw everything into one class, graphics, input, audio, window management, because that'd make more sense, right?
The window is a wrapper for the native window API. The graphics is a wrapper for the hardware-accelerated graphics API. It should be kept separate. And if anything, decoupling is a good thing because it's simply good OOP practice to do. It's makes code easier to understand and more maintainable.
-
Doesn't it look cleaner, more modular and easier to maintain this way?
I suppose it does, I'm just not sure if it would make things easier for the user. I was thinking about things where you have to know about the window in order to do the graphics, such as snapping things to one side of the window, where if you only have access to an sf::Graphics, and the Window has been resized, would sf::Graphics know that the Window had been resized, or would the user have to do it themselves? What about if the window loses focus and you want to draw to it when this happens, if something either only has access to the Window, or only has access to the Graphics, you can't do this. I guess I'm just resistant to change unless I'm absolutely sure there won't be any negative effects, but unless I come up with a concrete thing that definitely will causes a problem, I'll leave it.
-
It can be quite ugly when you need to use a Sound for something that's not a sound effect
A short tune that is constantly re-used benefits from being an Sound, but it's not a sound-effect.
But it's still sound, right?
-
snapping things to one side of the window
It makes sense for the graphics to access the framebuffer size, so this is a non-issue.
where if you only have access to an sf::Graphics, and the Window has been resized, would sf::Graphics know that the Window had been resized
You can't even do that with a RenderTarget. Actually, you can't even do that with the window! Resizing generates an event (ok, technically events go through the window, but there's no function to call). If your program has a proper structure, your rendering code will be notified about the resize.
What about if the window loses focus and you want to draw to it when this happens, if something either only has access to the Window, or only has access to the Graphics, you can't do this.
If your rendering code looks something like this:
void render(sf::RenderWindow& window)
{
if (window.hasFocus())
{
[i]...[/i]
}
}
Then you're probably doing something wrong.
I guess I'm just resistant to change unless I'm absolutely sure there won't be any negative effects, but unless I come up with a concrete thing that definitely will causes a problem, I'll leave it.
You shouldn't need a "concrete thing that definitely will causes a problem" to deal with a change for the better.
I mean, there's nothing inherently wrong with using the native API with OpenGL directly, but that doesn't mean that it isn't better to use a wrapper like SFML. Same thing with program structure (in this case, the problem isn't as severe, but it's pretty bad IMO), it might work for you right now, but it's still should be changed.
-
It can be quite ugly when you need to use a Sound for something that's not a sound effect
A short tune that is constantly re-used benefits from being an Sound, but it's not a sound-effect.
But it's still sound, right?
The problem is entirely just the semantics. Just because there isn't an inherit issue with playback (but there can be, if you're misled to use the wrong class..), does not mean that the names shouldn't be changed. After all, your entire counter-argument was precisely about semantics as well. :)
-
The issue you have, then, is only with sf::Music.
An sf::Sound represents a sound in memory, as an sf::Image represents an image in memory, and an sf::Font represent a font in memory etc..
Whether this sound is and effect or music doesn't matter since they're all sound and this naming is precisely what it is.
sf::Music, however, is named after the more commonly used reason to used streamed audio, especially in games. It could be named sf::ExternalSound, which would still be semantically correct (and I wouldn't dislike that as much as sf::UnbufferedAudio), but it's uncommon to use it for anything other than music and it's easy to understand that sf::Music streams audio from somewhere, if you need to use it.
You mostly only really see the type at declarations anyway so as long as your variable name is descriptive, its type shouldn't matter that much.
-
The issue you have, then, is only with sf::Music.
While sf::Music is the primary offender, sf::Sound still feels like it conveys a small amount of "this is for sound effects only" in it's name. That's why I'd prefer Audio in oppose to Sound, if the naming were to be changed (same amount of letters anyways). But as I said, it is mostly sf::Music.
Whether this sound is and effect or music doesn't matter since they're all sound and this naming is precisely what it is.
If the naming didn't matter, I would've suggested it, you would've said that you have no strong feelings one way or the other and that it's not worth anyone's time and we should all just move on from it. Clearly there are opinions about which names are superior.
sf::Music, however, is named after the more commonly used reason to used streamed audio, especially in games.
Exactly why I contest it's name. I'd much prefer it being named based off of what it does, and why it's different from it's alternatives, not it's most common usage.
It could be named sf::ExternalSound, which would still be semantically correct (and I wouldn't dislike that as much as sf::UnbufferedAudio)
Better, but the word "External" instead of "Streamed" or "Unbuffered" kinda negates any benefits. I suppose it might make the programmer have a moment of confusion wondering what an "external sound" is, look at the documentation, and finally figure it all out, but that's counter-intuitive. Plus.. it's.. kinda ugly.
it's easy to understand that sf::Music streams audio from somewhere, if you need to use it.
I wouldn't consider it easy if you have to look at the documentation.
You mostly only really see the type at declarations anyway so as long as your variable name is descriptive, its type shouldn't matter that much.
So we can go ahead and change the name of every class in SFML to be named after a fruit and it wont matter? Got it.
-
GraphicsWhale: I understand your arguments, but I'm not sure you understand the scope of mine. For example, you have entirely ignored the Android API example and how choosing simple terms affects usage massively.
Just imagine we'd rename "Sound" to "BufferedAudio" and "Music" to "StreamedAudio" (as well as remaining "Sound" occurrences to "Audio" for consistency). The resulting class names in the Audio module will be a confusing mess:
BufferedAudio
StreamedAudio
AudioBuffer
AudioStream
AudioSource
AudioRecorder
AudioBufferRecorder
...and these are just class names. Any methods that exist now or in the future and that refer to classes will become more confusing, too.
The fact that "Music" may not be 100% precise is something you notice once, but from then on you know it. Complicating identifiers on the other hand is something that makes every developer's life more difficult. I'm having a rather pragmatic view here.
I'd really recommend you have a deeper look at the Android API (the link in my previous post) and imagine how things would look if a self-descriptive name instead of "Intent" was chosen. It will help you understand precisely what I mean :)
-
Why not:
1. Use Sound instead of Audio.
2. Conversely to #1, change everything else from Audio to Sound.
3. Instead of BufferedAudio|StreamedAudio use something like Audio|StreamedAudio (might not be that effective, but worth mentioning).
If anything, simply changing sf::Music to sf::StreamedSound would make it a lot better than the naming scheme currently is.
-
So we can go ahead and change the name of every class in SFML to be named after a fruit and it wont matter? Got it.
No. Not what I said at all. I even emphasized "that" to make my point more clear. It's easy to see "Music" as meaning a streamed sound. "Tomato" doesn't really give you any reasonable link to sound at all.
sf::Sound still feels like it conveys a small amount of "this is for sound effects only" in it's name.
I can't see how you came to this conclusion. It seems to be that whenever you hear "sound", you also hear the word "effect" and that doesn't make any sense.
If the naming didn't matter, I would've suggested it, you would've said that you have no strong feelings one way or the other and that it's not worth anyone's time and we should all just move on from it. Clearly there are opinions about which names are superior.
Would I? You seem to be misunderstanding what I'm writing. I have not stated whether I think Sound or Audio is better. I merely stated that its current name is accurate.
the word "External" instead of "Streamed" or "Unbuffered" kinda negates any benefits.
Which benefits? It shows that it has a different purpose to an "internal" sound and it's accurate. It's held outside of RAM.
Unbuffered, by the way, is technically inaccurate. Streamed sound is buffered.
I wouldn't consider it easy if you have to look at the documentation.
You shouldn't be using it if you haven't looked at the documentation.
-
No. Not what I said at all. I even emphasized "that" to make my point more clear. It's easy to see "Music" as meaning a streamed sound. "Tomato" doesn't really give you any reasonable link to sound at all.
Are you saying your tomatoes don't sing to you..?
I can't see how you came to this conclusion. It seems to be that whenever you hear "sound", you also hear the word "effect" and that doesn't make any sense.
Most game libraries have "Sounds" much alike that in SFML. They are fairly heavy-weight, but are useful for small things, such as sound effects.
Things not used often or are too large to load are streamed. For example, in LOVE2D all music is streamed unless the parameter "static" is also passed.
Not completely related, but in Slick2D, Music has nothing to do with streaming, but instead the channel it's on (might be details I'm missing though, I haven't used this library in some time).
But generally, "sound"s are associated with RAM-cached audio sources. And such audio sources are used very often in games (most sounds you hear in games are considered sound effects anyways, not music).
Would I? You seem to be misunderstanding what I'm writing. I have not stated whether I think Sound or Audio is better. I merely stated that its current name is accurate.
1. Yes you would. In fact, you already have simply by contesting my opinion with your opinion.
2. You've stated your preference of the current system already.
3. The whole point of my argument, is that the name is not entirely accurate. So one of us is wrong. But don't automatically assume that it's me.
Which benefits? It shows that it has a different purpose to an "internal" sound and it's accurate. It's held outside of RAM.
Because it has no context to what it refers to by "external". External to what? The object? The class? The module? The library? The RAM? The computer? The earth? The solar system? The milky way?
Unbuffered, by the way, is technically inaccurate. Streamed sound is buffered.
And technically all of your objects are buffered with the cache. So I better go back and change BufferedAudio|UnbufferedAudio to BufferedBufferedAudio|BufferedUnbufferedAudio.
You shouldn't be using it if you haven't looked at the documentation.
Tell that to the people who don't read the documentation. I'm sure they'd be utmost excited to here about the existence of technical manuals that they intentionally chose not to read to begin with.
-
I may have overstated my point in the past couple of posts.
I am not saying the API should be friendly to people who have no clue what they're doing. But such ambiguity between class names will likely cause people to not use the API correctly rather than bothering to look at the documentation (don't make yourself believe everyone actually looks in every little corner of the documents, all someone needs to see is "sf::Sound" or "sf::Music" written somewhere and they'll begin to learn only that class and ignore the other). At least they could stop and think "What's the difference between buffered and unbuffered sound/audio?" and possibly want to actually look at the documentation.
-
Most game libraries have "Sounds" much alike that in SFML. They are fairly heavy-weight, but are useful for small things, such as sound effects.
Things not used often or are too large to load are streamed. For example, in LOVE2D all music is streamed unless the parameter "static" is also passed.
Not completely related, but in Slick2D, Music has nothing to do with streaming, but instead the channel it's on (might be details I'm missing though, I haven't used this library in some time).
But generally, "sound"s are associated with RAM-cached audio sources. And such audio sources are used very often in games (most sounds you hear in games are considered sound effects anyways, not music).
Other libraries doing something doesn't mean that it's the right way to do something.
You did, here, seem to make a distinct between sounds being in RAM and music being the streamed audio. I think those distinction may be why those names were chosen for SFML.
It shows that it has a different purpose to an "internal" sound and it's accurate. It's held outside of RAM.
Because it has no context to what it refers to by "external". External to what? The object? The class? The module? The library? The RAM? The computer? The earth? The solar system? The milky way?
It doesn't have to necessarily specify exactly what it's doing. "BufferedAudio" doesn't say where it's being buffered. Your reply was odd :P
My point was that it's accurate and differentiates from the 'other' type by describing why it's different.
Would I?
Yes you would.
You seem to be misunderstanding what I'm writing.
I better go back and change BufferedAudio|UnbufferedAudio to BufferedBufferedAudio|BufferedUnbufferedAudio.
No, because BufferedUnbufferedAudio isn't unbuffered.
You shouldn't be using it if you haven't looked at the documentation.
Tell that to the people who don't read the documentation. I'm sure they'd be utmost excited to here about the existence of technical manuals that they intentionally chose not to read to begin with.
I know. They'll come to the forum and ask why it isn't working and then they'll be (hopefully politely) directed to the documentation.
Are you saying your tomatoes don't sing to you..?
I'm not going to admit that in public!
-
If your rendering code looks something like this:
void render(sf::RenderWindow& window)
{
if (window.hasFocus())
{
[i]...[/i]
}
}
Then you're probably doing something wrong.
ok, noob to SFML here (been doing sfml for about 4 weeks)
why is that code wrong ?
according to this
http://www.sfml-dev.org/tutorials/2.3/window-inputs.php
sf::Keyboard::isKeyPressed(...)
"This function directly reads the keyboard state, ignoring the focus state of your window. This means that isKeyPressed may return true even if your window is inactive."
so from that documentation that's exactly what I've been doing in my code (checking if window has focus)
-
why is that code wrong ?
Because your game should be continuously updating regardless as long as it's running. Maybe pause it when minimize, but that's a change to your game's "state", not branch in the rendering code.
sf::Keyboard::isKeyPressed(...)
"This function directly reads the keyboard state, ignoring the focus state of your window. This means that isKeyPressed may return true even if your window is inactive."
so from that documentation that's exactly what I've been doing in my code (checking if window has focus)
I never said to ignore keyboard input, I just said that there doesn't need to be a branch in your rendering code, therefore only passing a graphics object instead of the whole window is a non-issue.
-
jamesL: The code is not wrong from a functionality standpoint, but the design is questionable. The rendering code shouldn't care about windowing stuff. If there's a reason to not render, the application shouldn't call the render function in the first place.
As such, I agree that there isn't an inherent reason to mix graphics and windowing in the same class. Investigating the proposed approaches for SFML 3 can definitely be interesting.
-
Other libraries doing something doesn't mean that it's the right way to do something.
You did, here, seem to make a distinct between sounds being in RAM and music being the streamed audio. I think those distinction may be why those names were chosen for SFML.
My point was the the notion of "Music" being something that streams it's audio is unique (AFAIK) to SFML. Maybe, just maybe, there's a reason why this naming scheme was not used in other libraries
It doesn't have to necessarily specify exactly what it's doing. "BufferedAudio" doesn't say where it's being buffered. Your reply was odd :P
My point was that it's accurate and differentiates from the 'other' type by describing why it's different.
When you have a class that has a function to load a file, and a function to use it, the word "buffered" is pretty meaningful. Sure, it might not say to which point is it being buffered (the whole file, a small section, maybe even per-sample?), but most of the time it's referring to the whole file. "External" is not a good way to refer to something in the filesystem, so it's a lot less meaningful.
No, because BufferedUnbufferedAudio isn't unbuffered.
Does BufferedBufferedAudio|BufferedAudio tickle your fancy?
If the "permanent storage" (SSD or HDD) has cache, it would also be buffered there, too. Dang. Ok, what about BufferedBufferedBufferedAudio|BufferedBufferedAudio?
I know. They'll come to the forum and ask why it isn't working and then they'll be (hopefully politely) directed to the documentation.
Not sure why'd you want that.
-
They'll come to the forum and ask why it isn't working and then they'll be (hopefully politely) directed to the documentation.
Not sure why'd you want that.
Want? No. The preference is that people read the documentation first. At minimum: try, google, read documentation, search forum, read documentation again, post on forum.
Does BufferedBufferedAudio|BufferedAudio tickle your fancy?
What? No. Why mention that they're buffered if they're both buffered? In this instance, they would both just be called Audio.
"External" is not a good way to refer to something in the filesystem
That's your opinion, of course, and I didn't say it was good. It just doesn't seem any worse than what you're suggesting. If this is your problem with "ExternalSound", I assume you liked the idea of "SoundOnFile"?
My point was the the notion of "Music" being something that streams it's audio is unique (AFAIK) to SFML. Maybe, just maybe, there's a reason why this naming scheme was not used in other libraries
I didn't say that music was only streamed. Music is sound so it can also be stored in memory without any inaccuracies. The idea of streamed sound being called Music is that the most common sound to stream is music. May I ask which sound you are streaming that isn't music that you find too confusing to label as music?
For example, in LOVE2D all music is streamed unless the parameter "static" is also passed.
This does seem to suggest that other libraries seem to default to music being a streamed sound.
My overall point then, really, is:
sf::Sound isn't incorrect in any way, although sf::Audio would work just as well. There is no reason to swap them though, since they amount to the same thing and would just break code for no reason.
sf::Music is a wrapper for a streamed sound and is named for its most common usage. It would be technically inaccurately named if you use it for anything other than what you define as music. I, personally, don't agree that it's the most apt name (this is my opinion; I don't know why you thought I thought otherwise) but is not difficult to 'overcome' and I am perfectly okay with it staying as "Music" but I might not vote for it if there's a better choice.
-
May I ask which sound you are streaming that isn't music that you find too confusing to label as music?
Long ambient background sound loops wouldn't be classified as music, but most likely would be streamed. Not sure how common these are but I've used them extensively in the past.
-
Long ambient background sound loops wouldn't be classified as music
Some may consider them to the music of nature (or of whatever the ambience might be) ;D
The part you quoted was less about things that aren't music and more about things that are too confusing.
-
Some may consider them to the music of nature.
We're programmers, we shouldn't be that poetic! ;)
I still find it odd that the class is named for a specific use case (music) rather than what it actually is (audio stream). I don't really feel all that strongly either way, but it seems at odds with the rest of the library.
-
I don't think this conversation will ever lead anywhere productive at this point. Can't tell if we're either not understanding each other or we just have different opinions, but I'm lost. But I will say this:
I really don't care that much about the naming of the class Sound. It's mostly Music. According to Google (because we all know Google is the one and only true God, the kingdom of the internet, that we'd all be lost without), the definition of music (there's two definitions, but this is the one referring to the audio music) is:
vocal or instrumental sounds (or both) combined in such a way as to produce beauty of form, harmony, and expression of emotion.
I consider this definition an accurate representation of what most people think of when they hear the word "music". With that said, the reason why I point that out is because music has a pretty concrete meaning of a certain type of sound.
Music in SFML, on the other hand, is simply anything that streams directly from the file.
There's a lot more to streaming audio directly from a file than music. Therefore, I think it's in the best interest to have it changed to a more "useful" name.
-
Music in SFML, on the other hand, is simply anything that streams directly from the file.
You can make other wrappers that use an sf::SoundStream (http://www.sfml-dev.org/documentation/2.3.1/classsf_1_1SoundStream.php) for your purposes.
There's a lot more to streaming audio directly from a file than music. Therefore, I think it's in the best interest to have it changed to a more "useful" name.
I find only five letters to be extremely useful.
I still find it odd that the class is named for a specific use case [...] rather than what it actually is
Not that odd, really.
sf::Texture is named for its specific use case (and its location) when it's really just an image.
sf::Sprite is named for its specific use case when it's really just a rectangle, or a vertex array.
We're programmers, we shouldn't be that poetic! ;)
There's poetry in everything, including programs! :)
-
sf::Texture is named for its specific use case (and its location) when it's really just an image.
sf::Sprite is named for its specific use case when it's really just a rectangle, or a vertex array.
I'm not sure these examples correlate with mine. Both of these terms are industry standard for a particular concept, if you will, whereas 'Music' just implies that the class is to be used with one specific type / style of audio (texture doesn't imply certain types of images, for example - or perhaps it does and I just interpret that word differently to everyone else :)).
I should add that I think that very few people have ever been all that fussed by this (at least none that I'm aware of, besides this topic). It's perhaps an oddity at worst, and certainly not a dealbreaker by any means.
-
I don't think this conversation will ever lead anywhere productive at this point. Can't tell if we're either not understanding each other or we just have different opinions
Differing opinions, definitely. I don't really see how it's anything other than that?
Also, if we're going to start whipping out dictionary definitions in a feeble attempt at proving our opinions are correct, I advocate that these names shall be changed:
sf::Texture is NOT
"the feel, appearance, or consistency of a surface or a substance."
sf::Lock is NOT
"a mechanism for keeping a door, window, lid, or container fastened, typically operated by a key."
Amongst others. Also, ConvexShape isn't always convex. Also Microsoft is neither micro, nor soft. Wait... My chrome I'm using isn't chrome?!?!
A name is a name, just that. I actually agree that sound/music aren't really the best names for these things, but I haven't seen a single suggestion here (or anywhere else) which is any better. In particular your buffered/unbuffered suggestions are just as misleading as Hapax pointed out ( I won't comment on the barrage of pedantry which followed...)
Also, RE the various comments about documentation. If programming was so easy that someone could just pick it up without reading up, We'd all have a lot more industry competition. If you jump into something without knowing what you're doing then you should fully expect to have issues (not saying this is a bad way to do things, in fact, I frequently jump into things without even attempting to learn them, but then I only hold myself responsible when things go wrong)
-
sf::Texture is NOT
"the feel, appearance, or consistency of a surface or a substance."
sf::Texture is named for its specific use case (and its location) when it's really just an image.
An SFML texture corresponds with an OpenGL texture, so it's not out of place. As for why they're called textures in the first place, I don't know.
sf::Sprite is named for its specific use case when it's really just a rectangle, or a vertex array.
A "sprite" is something that exists in lots of libraries/engines. It's a standard name.
sf::Lock is NOT
"a mechanism for keeping a door, window, lid, or container fastened, typically operated by a key."
Request it to be changed to sf::MutexLock, then.
-
As somebody new to SFML, the difference between Sound and Music was perfectly clear for me even without documentation.
By the way: QSound (http://doc.qt.io/qt-4.8/qsound.html), QSoundEffect (http://doc.qt.io/qt-5/qsoundeffect.html)
Just sayin'
-
..................
can't take a joke or understand sarcasm
-
As somebody new to SFML, the difference between Sound and Music was perfectly clear for me even without documentation.
Average rate that people immediately know the difference: 100%
Sample size: 1
By the way: QSound (http://doc.qt.io/qt-4.8/qsound.html), QSoundEffect (http://doc.qt.io/qt-5/qsoundeffect.html)
Can you explain your point, instead of giving me links to qt documentation? I can't tell what kind of message you're trying to convey here.
-
..................
can't take a joke or understand sarcasm
I... I legitimately have absolutely no clue what you are talking about.
-
What about the people who think they're too good for documentation? Even if they don't want to learn, it's not always a bad idea to give some sort of hint of the differences in the name.
I agree that names should try to indicate what classes/functions represent. Sure.
I'm not so sure that changing these names buys us much when it comes to clarity.
But what I really want to comment on is your statement above about people who can't be bothered to read docs. Well, in my opinion, such people are just beyond reach/hope and not worth spending time on or worry about.
If you can't be bothered to read the documentation you'll have problems with any library - regardless of naming. And in any case, you probably should not be programming professionally.
Using this as an argument really doesn't convince me in any way. It's just saying that SFML should cater to idiots and I don't agree with that.
-
What about the people who think they're too good for documentation? Even if they don't want to learn, it's not always a bad idea to give some sort of hint of the differences in the name.
I agree that names should try to indicate what classes/functions represent. Sure.
I'm not so sure that changing these names buys us much when it comes to clarity.
But what I really want to comment on is your statement above about people who can't be bothered to read docs. Well, in my opinion, such people are just beyond reach/hope and not worth spending time on or worry about.
If you can't be bothered to read the documentation you'll have problems with any library - regardless of naming. And in any case, you probably should not be programming professionally.
Using this as an argument really doesn't convince me in any way. It's just saying that SFML should cater to idiots and I don't agree with that.
Hey, if it's good enough for an idiot, it's probably excellent for anyone who actually knows what they're doing.
Also, I wouldn't consider most of the usage of SFML to fall under the category of "programming professionally". These "easy" wrappers for window management (and other utilities) might be capable of being used professionally, but most of the time they're used for making bad pong clones. SFML especially (since these types of people also seem to flock to C++).
Not trying to insult SFML, or say that this is true to anyone on the forum, but there's a lot of beginners who like to use this library.
EDIT: Just for clarification, I am not saying I want SFML to cater to idiots. I honestly couldn't care less about making life easier for those who refuse to read the docs. However, I also don't want the names to be misleading (which is what I believe the class Music does).
-
In hope that this is still a discussion and not an argument...
An SFML texture corresponds with an OpenGL texture, so it's not out of place.
I have no problem with it being called Texture but since you think things should be named more specifically for their usage, this should at least be sf::OpenGlTexture, right?
As for why they're called textures in the first place, I don't know.
I do :P
They're mapped to polygons to represent a surface.
sf::Sprite is named for its specific use case when it's really just a rectangle, or a vertex array.
A "sprite" is something that exists in lots of libraries/engines. It's a standard name.
I have no problem with sprite. I think you again misunderstood what I was saying.
Microsoft is neither micro, nor soft.
It's micro-computer software...
barrage of pedantry
;D
you probably should not be programming professionally.
Don't worry; I won't ;)
If you can't be bothered to read the documentation you'll have problems with any library - regardless of naming.
Exactly.
Both of these terms are industry standard for a particular concept, if you will, whereas 'Music' just implies that the class is to be used with one specific type / style of audio (texture doesn't imply certain types of images, for example - or perhaps it does and I just interpret that word differently to everyone else :)).
I think they're very similar. Texture implies that it's to be used with one specific type of image, for example.
most of the time they're used for making bad pong clones.
Thanks (https://github.com/Hapaxia/MyPracticeBeginnerGames) :'(
-
In hope that this is still a discussion and not an argument...
I don't consider this an argument. Maybe a debate. But that isn't exactly a bad thing.
for their usage, this should at least be sf::OpenGlTexture, right?
As I said, I'm not for unreasonably "correct" names.
I have no problem with sprite. I think you again misunderstood what I was saying.
You were trying to make a point by giving a slightly extreme example, yes?
Thanks (https://github.com/Hapaxia/MyPracticeBeginnerGames) :'(
The source does not compile (dependencies on missing headers). Could only "play" via looking at the code and imaging what could've been. 2/10 :'(
-
I think we've got all the mileage we can get over potential name changes for audio classes; I'm sure the SFML team have enough pro and con arguments to make a final decision and close the matter.
It's good that many people are taking such a keen interest in the development of the library itself, and it's clear that there's a lot of passion for it. :)
-
I'm not for unreasonably "correct" names.
This is what I would consider sf::StreamedAudio to be when used for music.
Thanks (https://github.com/Hapaxia/MyPracticeBeginnerGames) :'(
The source does not compile (dependencies on missing headers). Could only "play" via looking at the code and imaging what could've been. 2/10 :'(
I don't think you should vote for something you haven't tried ;D
Missing headers? These?
https://github.com/Hapaxia/Dev
https://github.com/Hapaxia/Plinth
https://github.com/Hapaxia/Kairos
I think we've got all the mileage we can get over potential name changes for audio classes
I beg to differ:
sf::SampledSound, sf::Sample, sf::Soundtrack, sf::SoundEffect, sf::AmbientSound, sf::Ambience, sf::Ambulance
-
I beg to differ:
sf::SampledSound, sf::Sample, sf::Soundtrack, sf::SoundEffect, sf::AmbientSound, sf::Ambience, sf::Ambulance
To be perfectly honest, if you came up with a name for every single possible usage, I wouldn't even be upset. I'd be a bit like: "do I want a sound track? sf::SoundTrack.. what about sad music? sf::SadMusic, maybe even throw a bit of sf::JustinBieber in the hell level". ;D
-
How's this?
namespace sf
{
using StreamedAudio = Music;
using SoundTrack = Music;
using SadMusic = Music;
//using JustinBieber = Music; // this would be just plain wrong
}
-
maybe even throw a bit of sf::JustinBieber in the hell level]maybe even throw a bit of sf::JustinBieber in the hell level
Hehe. :P
The discussion about sf::Sound/sf::Music is quite interesting. I'd like to propose to merge sf::Sound and sf::Music into one class, e.g. sf::Audio. GraphicsWale mentioned the LÖVE2D example, and I think they are going into the right direction.
Take a look at the APIs of sf::Sound and sf::Music, and you'll see that they are very similar to each other. But more importantly, they do the same thing: Loading and playing audio samples. If those samples are streamed or buffered is at most an implementation detail and class property.
However, thinking more about it, and also in relation to the sf::Window/sf::Graphics thing (which I completely like, because it would probably also mean that context creation is explicit rather than implicit, unlike currently), the case for sf::Audio could be incredibly easy to understand and use:
sf::SoundStream music_source("music.ogg");
sf::SoundBuffer sound_source("effect.ogg");
sf::Audio background_music(music_source);
sf::Audio effect(sound_source);
For sf::Sound/sf::SoundBuffer, it already works exactly like in the code above. For sf::Music, it could work similar. This does greatly split areas of responsibility and thus enhance modularity: sf::Audio shouldn't be bothered with the source. It's just the class that takes samples from an arbitrary input and processes them for playback.
We'd be left with one class that plays any audio, and two classes for possible sound sources. As both are sources, different names than "SoundBuffer" and "SoundStream" (e.g. AudioBuffer, AudioStream, StreamedSource, BufferedSource, BufferedAudio, StreamedAudio) might be chosen.
-
Tank, that sounds like an interesting approach; I'm glad we're back to a useful discussion again after that page-long naming debate ;) It would also get rid of the inconsistent sf::Music design which is currently both resource and resource user in one class.
However, it's probably not as easy as it first sounds. Unlike sf::Texture, sf::Font, sf::SoundBuffer and sf::Shader, the sf::SoundStream class (proposed by you, not the current one) is not a real resource, because it carries state about audio playback. That is, you have an implicit (thus subtle) circular coupling between a sf::Audio instance and the sf::SoundStream it is using.
In particular, you cannot reuse a sf::SoundStream instance for multiple sf::Audios, which negates a main advantage of splitting the classes. In addition, you cannot const-qualify sound streams.
What might be possible is that a sf::SoundStream is merely an abstract description of a sound source (file, memory, ...), and for each sf::Audio instance that uses it, it internally creates an actual stream carrying the state of the sound. On the other hand, I wonder whether this is useful in practice, as streams are primarily used for music, and usually, only one music theme is played at a time.
-
because it carries state about audio playback
I thought about this, but I think that wouldn't be the case. Wouldn't the state be in sf::Audio? The SoundStream would just be told to deliver X samples from position Y.
I haven't thought very deeply in terms of implementation, so this might have flaws. Just giving out ideas right now.
-
Would it not be possible to just add on sf::Audio as a wrapper for sf::Sound or sf::Music? That way, it could abstract away the concept of the different types but would still allow direct usage of sf::Sound and sf::Music, which wouldn't break any current code. It could then be implemented before v3.
-
For me, that sounds like an unnecessary hack. ;)
-
The SoundStream would just be told to deliver X samples from position Y.
It already exists: sf::InputSoundFile.
However, if a single stream / sound file is shared among multiple musics, it will have to seek a lot, which can be very slow (or even impossible) depending on the underlying stream. Currently, only sequential reading is used by sf::Music. It would also have to be thread safe, but that's a different story :)
-
However, if a single stream / sound file is shared among multiple musics, it will have to seek a lot, which can be very slow (or even impossible) depending on the underlying stream.
Maybe have a max amount of "clients" for the stream, depending on the platform's limitations (or some fixed number)? Probably not the best solution, but an idea.
Speed shouldn't be a concern. There's nothing stopping anyone from creating a million sf::Musics and streaming them all to the same file with the current system. Just like how you should warn against creating loading a really large file into an sf::SoundBuffer, you could simply warn against having too many sound instances trying to stream from the filesystem.
-
However, if a single stream / sound file is shared among multiple musics, it will have to seek a lot
There's nothing stopping anyone from creating a million sf::Musics and streaming them all to the same file with the current system
Nothing more to add. :)
It already exists: sf::InputSoundFile.
Yeah, I was aware of that, but I don't know how good it'd fit into my proposal, so I came up with something generic instead.
-
There's nothing stopping anyone from creating a million sf::Musics and streaming them all to the same file with the current system
But with the current implementation, each music will create its own instance of the stream and read it sequentially.
-
There's nothing stopping anyone from creating a million sf::Musics and streaming them all to the same file with the current system.
I'm not sure if the file access is thread-safe.
And I'm pretty sure that memory and sf::InputStream access is not -- simply because the user doesn't explicitly declare shared resources, and the implementation can't know.
A sequentially reading implementation sounds good to me. As Laurent says, seeking is expensive or impossible (for custom input streams)... If the same resource is played multiple times concurrently, SFML may allocate some overlapping samples, but that's not a concern in my opinion, especially since it happens really rarely for big files. As I mentioned earlier, one possibility would be an abstract stream with multiple clients, one per sf::Audio instance using it.
-
I think we're at a point where an issue regarding the audio bits on the tracker would be a good idea with a link back to this thread, otherwise the discussion and ideas will vanish in the depth in a few weeks/months.
-
I think it's at a point where it'd be nice to see sample implementations. If I just wouldn't lack the time. :(