Messages

1

Feature requests / Re: Support scalar color operator overloads

« on: August 19, 2016, 02:00:04 am »

Lol, I guess I'm the crazy one. I just polled 5 of my programmer friends of various levels of graphics experience, and they had the same hangups as you guys.

I think doing math like this has several common uses cases (even for newbs) if the alpha is masked out on these operators (see the other thread for that list if you are interested).

I don't think affecting alpha and colors at the same time is useful, even if it is "intuitive". If you can come up with use cases, I'm still interested, in case I get the urge to write my own float color class as an extension.

I think affecting alpha only has a very obvious set of use cases, but I personally would be more surprised by that (and so far my polls show that to be a unique interpretation).

I agree, too ambiguous to add, even if I personally would expect the class to do this due to use-case enablement. I really don’t want it to be a POLA argument, but it’s hard to recommend a change that causes support requests, even if it makes common use cases marginally more convenient.

Cool, thanks for the consideration!

(I won't call this dead til you guys do, but I think the responses I've gotten so far on the surprise factor are pretty conclusive in my opinion)

2

Feature requests / Re: Support scalar color operator overloads

« on: August 18, 2016, 06:04:19 pm »

On the other thread, people have already commented that the multiply not affecting the alpha value would be confusing.

I personally think it would be confusing only for people who were familiar with shaders. If you want to affect all components, you can always step back to the more verbose Color * Color multiplication.

Thoughts?

3

Feature requests / Support scalar color operator overloads

« on: August 18, 2016, 06:01:14 pm »

Posting in response to this feature request issue:

https://github.com/SFML/SFML/issues/1128

To kick off the thread again, here's my first post from there ->

For simplicity and brevity in working with colors, it may be useful to support scalar math operators.

Color darkGreen = Color::Green - 127;
Color darkGray = Color::Black + 63;
Color darkerColor = someComputedColor * 63;

The equivalents are already possible now, but are more verbose:

Color darkGreen = Color::Green - Color(127, 127, 127, 0);
Color darkGray = Color::Black + Color(63, 63, 63, 0);
Color darkerColor = someComputedColor * Color(63, 63, 63, 255);

Problems I see:

• Accidental implicit conversions. I think this is already taken care of by providing operator uint32_t as a named member function instead of an overloaded operator. It is also taken care of by making the Color(uint32_t) constructor explicit.
• The operator * might be confusing, since it scales down, not up. The existing operator * already does this, and anyone who is "multiplying" colors already has to understand this difference as it stands today. I'd change my mind if operator / was introduced, but I think that's a very confusing construct to begin with for someone who isn't super familiar with color math, so I think it should not go into the library anyway.
• There might be anxiety on the user's side on whether the alpha channel is touched or not. This could be cleared up by documentation of the scalar operators. I think preserving the alpha channel in these operators is the more common case, and is the least surprising.

If there was interest, I'm perfectly happy and able to put in a pull request implementing these features. I'd prefer to ask for comments and/or a rejection before I spend time on it.