Messages

91

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 09:54:40 pm »

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. 

92

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 09:43:14 pm »

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.

93

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 09:03:16 pm »

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.

94

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 08:50:07 pm »

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.

95

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 08:12:06 pm »

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. 

96

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 08:07:53 pm »

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.

97

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 07:47:31 pm »

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.

98

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 07:43:46 pm »

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" 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.

99

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 07:20:43 pm »

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.

100

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 06:46:38 pm »

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?

101

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 06:45:52 pm »

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.

 

102

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 06:06:52 pm »

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.

103

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 06:01:56 pm »

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?)

104

Feature requests / Re: A couple suggestions

« on: August 23, 2015, 03:37:10 pm »

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.

105

General / Re: Memory management

« on: August 23, 2015, 02:46:33 pm »

Is your error compile-time or run-time? Are you trying to erase any elements while iterating?

Run-time. I read about trying to erase elements while iterating gives an error. But all I do is clear the vector. 

I edited my post to include more info, didn't think you'd respond so fast.

Please read this:
http://stackoverflow.com/questions/6438086/iterator-invalidation-rules

Iterators are "fragile" enough that they can be invalided by simply erasing an object. Why would you think clearing the entire vector wouldn't effect them?

EDIT: I see you have the same issue with response time as I did. Anyways:

1. You don't need to check before hand.
2. Is that the loop where you're getting the error?