[CLOSED] Add sf::BlendMode::ReverseSubtract

[Laurent]

More options means the functionality is less straight-forward to use. It is more complex for someone without knowledge on blending modes, to figure out what he needs if all possible options are exposed to him, rather than just the most useful ones.

Also on the topic of negative light, I think that being able to create, for example, black plasma blast style effects, or even just a black fire/lantern is not only cool graphically but can add to games.

As already said, this kind of effects are usually done with multiplicative blending, to modulate the amount of final light rather than subtracting a fixed quantity.

[shadowmouse]

More options means the functionality is less straight-forward to use. It is more complex for someone without knowledge on blending modes, to figure out what he needs if all possible options are exposed to him, rather than just the most useful ones.

Surely this is what tutorials and documentation are for? You can highlight which ones are the most commonly used ones and which ones are more advanced as well as what each one does. Surely you don't expect that people work out what to write purely by guessing what it will be called and then using the auto-complete/intellisense functions of an IDE.

[Krozark]

More options means the functionality is less straight-forward to use. It is more complex for someone without knowledge on blending modes, to figure out what he needs if all possible options are exposed to him, rather than just the most useful ones.

Surely this is what tutorials and documentation are for? You can highlight which ones are the most commonly used ones and which ones are more advanced as well as what each one does. Surely you don't expect that people work out what to write purely by guessing what it will be called and then using the auto-complete/intellisense functions of an IDE.

+1 : totally agree.

Moreover, if a user start to use BlendMode, we can say that it's not a novice anymore. I'm sure that he will know how to search thought the documentation (which is very complete) to find the needed informations.

[eXpl0it3r]

I personally think it won't make things a lot more complex. As Krozark already said once you're start using blend modes, you're not a novice anymore who just looks at the auto-completion of the IDE and tries to find out what it does by trial and error.
So the current implementation is only artificially limiting the ones who actually want to use the blend modes more complex. And I think we're lucky that this has been brought up for discussion, because I can easily imagine that there have been others who wanted that feature before and just patched SFML locally and never reported it.

Would be nice to hear some opinions from other team members.

[Tank]

My opinion is probably clear, but here it is: I see no conflicting complexity by adding more options. Blending is already part of the library, and not including special modes is 1) trying to predict how people use blending and 2) expecting that all SFML users only use the simple things, thus leaving the experienced people behind.

As we really want experienced people to be able to enjoy SFML and not be forced to use raw OpenGL everywhere (or even choose another library), I highly suggest to add the missing modes.

[Krozark]

I'm glad this conversation is fruitful.

I'll open an issue on the SFML github, then make a  pull request with the appropriate modifications.

[Tank]

Thanks!

[Nexus]

Keep in mind that the original discussion about adding blend modes explicitly omitted those options because they are not so common, and the API would be simpler to use without them. Users agreed at that time with the API. So, the omission was not an overlook, but by design.

If the assumptions have truly changed in the meantime and we have good use cases (rather than "just provide it because OpenGL does"), I'm okay with adding the options. It would be cool if you could quickly summarize what effect you're trying to achieve that can't be achieved otherwise (e.g. with multiplicative blending).

[Laurent]

I especially like this (quoted from the author of the feature) from the original discussion:

If anything, min and max could be dropped as they serve little purpose from a graphical perspective and they also operate differently than the other equations (that is, they ignore the blending factors).

As library authors, we must predict what users will need, to provide the cleanest interface. It has never been the philosophy of SFML to add something without knowing if it will actually be useful. If we added a feature without knowing its effects and how users will use it, then we poorly did our job. And no, no matter how good your documentation is, a cluttered API is a cluttered API.

[Tank]

As library authors, we must predict what users will need, to provide the cleanest interface

Of course, but we should also find a good compromise between API "clutter" and functionality. In this case, we decided to drop reverse subtract because in our eyes, there was no use to it. But obviously we did not know better, because there is a use to it (see this thread).

To support it, we need to add one enum value. And the same perhaps happens with min and max now.

I totally agree that keeping the API clean and simple is the ultimate goal. But sacrificing potential functionality and users just to avoid adding three enum values, sorry, that's too much in my opinion. And don't forget that one also learns about new things when striving through the API docs to find something that might fit their needs.

Speaking of myself, I would be totally annoyed if I had to stick to raw OpenGL every time I needed something that wasn't proven to be a well-known use-case.

And no, no matter how good your documentation is, a cluttered API is a cluttered API.

I just want to emphasize this: We are talking about some enum values.

So, the omission was not an overlook, but by design.

That's correct, and I guess nobody is questioning the author of the changes.

It would be cool if you could quickly summarize what effect you're trying to achieve that can't be achieved otherwise (e.g. with multiplicative blending).

Krozark gave an example in the first post already.

[Laurent]

I just want to emphasize this: We are talking about some enum values.

Yeah, it was a more generic answer to someone who basically said "any added complexity is not a problem, there's the doc".

Krozark gave an example in the first post already.

In case it was not clear: I'm ok for adding reverse subtract, my objections are only about min and max.

[Krozark]

In case it was not clear: I'm ok for adding reverse subtract, my objections are only about min and max.

Ok, I don't have any example for Min, here is for Max:

Let's take the case of a game were your hero have only light as weapons (in fact, this is the plot of the game that DaiMysha is working on).
Imagine some monster that can be see only by specifics light color (let's take the example of a pure Red).
Now put you hero in a dark dungeon plain of this kind of monster. He turn on his torch light in Blue, and nothing appear. Change it's light color to Red, and .... plenty of monster appear where nothing was visible with the blue light.

I hope you understand the example.

Concerning the implementation, I think there is a lot of solutions, but this is one using BlendMode.
Just make a Min between you light map (texture with only the light), and draw the monster texture (of Red color) with a Min on the top of it.
Now, I don't know if it's the best example to illustrate the Min functionalities.

I am really mixed about these features (Min/Max), and personally I think I would never use them.
I join point of view of Laurent.

[Hapax]

Krozark, your min/max example is a little complicated/mixed. It looks like you switch from describing min and max.
Still, the example itself (red things not showing under blue light but showing under red light) seems to be the kind of thing you would do with multiplication.

I 'vote' for adding ReverseSubtract and leaving off Min and Max.

[Krozark]

Still, the example itself (red things not showing under blue light but showing under red light) seems to be the kind of thing you would do with multiplication.

I was trying to find an example of usage, and you're right, multiplication is a better solution.

My opinion (in case of ambiguity): Add ReverseSubtract only

[zsbzsb]

I agree, reverse subtract is good without adding min/max.