What is the expected result?
According to this documentation (https://www.opengl.org/wiki/GLAPI/glBlendEquationSeparate), the reverse subtraction is the source being subtracted from the destination rather than the destination being subtract from the source.
Can you not form this in an sf::BlendMode (http://www.sfml-dev.org/documentation/2.3.1/structsf_1_1BlendMode.php)?
The light emitted from the blue rectangle is white negativeWhat blue rectangle?
I am rendering the lights individually on a global RenderTexture that I then draw on the window. It's not possible to invert the two textures.Invert them? I was suggesting swapping them.
The expected result is this one:What is the destination and what is the source?
result = destination - source
If you know a way to do this without using the gl reverse subtract function reaching the result given in the screenshot i am curious because we didn't find anything that worked.Do what without using it? To reach the result, could do with knowing what we're using to create it. Could help if you provided the layers you are trying to blend, and in what order.
What blue rectangle?It doesn't see well because the window is dark, but at the origin of the dark cone, in the screenshot, there is a blue square representing the player's position.
What is the destination and what is the source?In this case, the result is what you see on the screen (the black cone, after multiplying it to the user's world),
Not sure why min and max are required.I don't know why they would be, but i don't see a reason not to include them. They've been made available by OpenGL so why not ? And if one day someone actually finds a use to them, he'll be happy that they are available and don't find themseves in my position.
What we are trying to achieve is a light that, instead of adding its component to the world, substracts them.
I don't know why they would be, but i don't see a reason not to include them. They've been made available by OpenGL so why not ? And if one day someone actually finds a use to them, he'll be happy that they are available and don't find themseves in my position.From previous discussions on this forum that I've seen, this seems to me to be a certain reason for rejection. Including stuff because you can in hope that someone might want it someday does not seem to be the philosophy behind SFML, which makes sense.
From previous discussions on this forum that I've seen, this seems to me to be a certain reason for rejection. Including stuff because you can in hope that someone might want it someday does not seem to be the philosophy behind SFML, which makes sense.
However I still don't understand what these "negative" lights mean; what effects do you achieve with them?
Could it be that this concept of "negative light" is a wrong solution to a more fundamental problem (lighting algorithm)?
Regarding the other OpenGL blend modes, there is an obvious reason to not add them "just because they exist": SFML is a simple library, not a 1:1 wrapper on top of OpenGL.
your proposal...which gives a good approximation but not exactly the result we wantedIt's true that it wasn't perfect as it's based on multiplication rather than linear subtraction. I find it ironic, though, that you found it unacceptable as multiplication is more commonly done via multiplication, and I'm not sure why you need exact numbers. Since it's lighting, the negative light's 'power' could be 'turned up' to accommodate.
it is available on OpenGL, and SFML doesn't allow us to use theme. Why?SFML's graphics module doesn't provide abstract access to everything that OpenGL does but SFML itself does allow access to OpenGL, if you're willing to use OpenGL.
I'd actually consider Min/Max to be more important than Reverse Substract. :)Why?
Correct me if I'm wrong, but this just extending an enum (from the user's point of view) and that doesn't make SFML harder to use
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.
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.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.
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 interfaceOf 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).
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. ;)
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.
In case it was not clear: I'm ok for adding reverse subtract, my objections are only about 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 was trying to find an example of usage, and you're right, multiplication is a better solution.