easier color effect usage

edward789121

set color effect to [#ff0088] ::looks

Last edited by edward789121 (April 4, 2016 20:24:14)

MathlyCat

I don't understand the suggestion?
Please explain in your post instead of your title.

TheLogFather

Actually, yes, I think it could be helpful to have a type of colour-based effect that makes a bit more intuitive sense to most people than the current hue-shifting colour effect – I suspect many Scratchers simply don't understand what that really does…

I was thinking it could perhaps be something a bit like this:

set tint color to [#ff8844] :: looks // has to be new distinct block, since different to others
set [tint v] effect to (50)% // 'tint' will be a new item in dropdown menu for effects blocks
change [tint v] effect by (10)

What it actually does is to make all colours in the sprite move towards the specified tint colour by the given amount. So 100% would make all parts of the sprite end up at the specified tint colour, 50% would be halfway between the sprite's normal colours and the specified tint colour.

An interesting question is the order in which this and the original colour effect should be applied…

If the original colour effect is done after the tint then it means the tint colour gets ‘shifted’ in its hue (so if you set tint to 50%, with a red tint colour, and the colour effect is also set to 100, then it'll be like tinting 50% towards cyan instead).

Perhaps the more interesting thing is to do the tint *after* the colour effect. That would mean a colour effect of 100 will turn red into cyan (and yellow into blue, green into magenta, cyan into red, etc.) and then tint the whole result towards the tint colour. I think that might be more intuitive than the other way above.

The other interesting thing about a tint like this is that it becomes possible to change the lightness of a costume by tinting towards black or white. Does that mean there would no longer really be any point of the brightness effect…!?

Last edited by TheLogFather (April 4, 2016 21:55:46)

edward789121

MathlyCat wrote:
I don't understand the suggestion?
Please explain in your post instead of your title.

set color effect to [#ff0088] ::looks

i mean such as, what color is 16? or 47? i figured what i you don't have to know by just clicking on the part with color and clicking on something with the color you want?

go to front of crowd ::looks
say [ha!] for (2) secs

edward789121

TheLogFather wrote:
Actually, yes, I think it could be helpful to have a type of colour-based effect that makes a bit more intuitive sense to most people than the current hue-shifting colour effect – I suspect many Scratchers simply don't understand what that really does…

I was thinking it could perhaps be something a bit like this:
set tint color to [#ff8844] :: looks // has to be new distinct block, since different to others
set [tint v] effect to (50)% // 'tint' will be a new item in dropdown menu for effects blocks
change [tint v] effect by (10)
What it actually does is to make all colours in the sprite move towards the specified tint colour by the given amount. So 100% would make all parts of the sprite end up at the specified tint colour, 50% would be halfway between the sprite's normal colours and the specified tint colour.

An interesting question is the order in which this and the original colour effect should be applied…

If the original colour effect is done after the tint then it means the tint colour gets ‘shifted’ in its hue (so if you set tint to 50%, with a red tint colour, and the colour effect is also set to 100, then it'll be like tinting 50% towards cyan instead).

Perhaps the more interesting thing is to do the tint *after* the colour effect. That would mean a colour effect of 100 will turn red into cyan (and yellow into blue, green into magenta, cyan into red, etc.) and then tint the whole result towards the tint colour. I think that might be more intuitive than the other way above.

The other interesting thing about a tint like this is that it becomes possible to change the lightness of a costume by tinting towards black or white. Does that mean there would no longer really be any point of the brightness effect…!?

yeah, that would be nice. (especially how you could just do

set tint color to [#ff0088] ::looks
set [tint v] effect to (100) //)

Last edited by edward789121 (April 4, 2016 22:05:01)

edward789121

TheLogFather wrote:
The other interesting thing about a tint like this is that it becomes possible to change the lightness of a costume by tinting towards black or white. Does that mean there would no longer really be any point of the brightness effect…!?

Sheep_maker

edward789121 wrote:
MathlyCat wrote:
I don't understand the suggestion?
Please explain in your post instead of your title.
set color effect to [#ff0088] ::looks
i mean such as, what color is 16? or 47? i figured what i you don't have to know by just clicking on the part with color and clicking on something with the color you want?

Color 16
Color 47
They still look like black because the shade of blue is too faint to notice.

I mean, of course, assuming that you were to do this:

set color effect to ((16)+())::looks
set pen color to ((47)+())
<touching color ((69)+())?>

TheLogFather

edward789121 wrote:
i mean such as, what color is 16? or 47?

Yeah, that's exactly the problem with the current colour effect.
(@Sheep_maker: Note that edward789121 is asking about these numbers in reference to the colour effect block, NOT as RGB colours as you've implied…)

The vast majority of Scratchers simply don't know enough about the way the hue colour cycle works to understand straight away what a particular value colour effect, such as 16 or 47, is doing to a costume.

The “set pen color” block (NOT the one with the colour-picker, but I mean the one you can type a number into) is also guilty of this to a lesser degree – but at least the numbers in there give fixed colours: zero means red, 33 means yellow, 67 means green, 100 means cyan, 133 means blue, 167 means magenta, and back to 200 means red.

That's a hue cycle (but who knows why they decided to make the range go from zero to 200 [at which point it wraps around] rather than the way standard hue is normally expressed, which is as an angle from zero to 360 [at which point it wraps around]).

But the “set color effect” block is a hue SHIFT – it shifts the hues of all parts of the sprite by the specified amount (where a shift of 200 wraps around, so does nothing again).

That means a colour effect of 33 will (roughly) shift red to yellow, yellow to green, green to cyan, cyan to blue, blue to magenta, and magenta to red.
A colour effect of 67 will (roughly) shift red to green, yellow to cyan, green to blue, cyan to magenta, blue to red, and magenta to yellow.
Etc., etc…
(@edward789121: hopefully that will help explain a bit about what the numbers mean for the colour effect…?)

But setting a tint colour doesn't require any such knowledge. All you have to do is *pick* a colour (since it's a square colour-picker), and set the tint percentage. The sprite's colours then get ‘tinted’ towards the tint colour you chose, by the percentage you specifed.

Seems like a way more intuitive kind of effect to me…

Last edited by TheLogFather (April 4, 2016 22:57:48)

Inreal49

cool

edward789121

TheLogFather wrote:
edward789121 wrote:
i mean such as, what color is 16? or 47?
Yeah, that's exactly the problem with the current colour effect.
(@Sheep_maker: Note that edward789121 is asking about these numbers in reference to the colour effect block, NOT as RGB colours as you've implied…)

The vast majority of Scratchers simply don't know enough about the way the hue colour cycle works to understand straight away what a particular value colour effect, such as 16 or 47, is doing to a costume.

The “set pen color” block (NOT the one with the colour-picker, but I mean the one you can type a number into) is also guilty of this to a lesser degree – but at least the numbers in there give fixed colours: zero means red, 33 means yellow, 67 means green, 100 means cyan, 133 means blue, 167 means magenta, and back to 200 means red.

That's a hue cycle (but who knows why they decided to make the range go from zero to 200 [at which point it wraps around] rather than the way standard hue is normally expressed, which is as an angle from zero to 360 [at which point it wraps around]).

But the “set color effect” block is a hue SHIFT – it shifts the hues of all parts of the sprite by the specified amount (where a shift of 200 wraps around, so does nothing again).

That means a colour effect of 33 will (roughly) shift red to yellow, yellow to green, green to cyan, cyan to blue, blue to magenta, and magenta to red.
A colour effect of 67 will (roughly) shift red to green, yellow to cyan, green to blue, cyan to magenta, blue to red, and magenta to yellow.
Etc., etc…
(@edward789121: hopefully that will help explain a bit about what the numbers mean for the colour effect…?)

But setting a tint colour doesn't require any such knowledge. All you have to do is *pick* a colour (since it's a square colour-picker), and set the tint percentage. The sprite's colours then get ‘tinted’ towards the tint colour you chose, by the percentage you specifed.

Seems like a way more intuitive kind of effect to me…

point towards [MathlyCat v]
say [ha!] again ::looks

Last edited by edward789121 (April 5, 2016 11:59:20)

edward789121

TheLogFather wrote:
The “set pen color” block (NOT the one with the colour-picker, but I mean the one you can type a number into) is also guilty of this to a lesser degree – but at least the numbers in there give fixed colours: zero means red, 33 means yellow, 67 means green, 100 means cyan, 133 means blue, 167 means magenta, and back to 200 means red.

though the hue of color effect is 0 to 100, with is especially confusing.

edward789121

TheLogFather wrote:

set [tint v] effect to (50)% 
change [tint v] effect by (10)

id think of it as

set tint value to () % ::looks
tint () % of the way ::looks

since, the tint effect has barely anything to do with other effects, and it could also cause some glitches.

Last edited by edward789121 (April 5, 2016 12:28:35)

TheLogFather

edward789121 wrote:
TheLogFather wrote:
The “set pen color” block (NOT the one with the colour-picker, but I mean the one you can type a number into) is also guilty of this to a lesser degree – but at least the numbers in there give fixed colours: zero means red, 33 means yellow, 67 means green, 100 means cyan, 133 means blue, 167 means magenta, and back to 200 means red.
though the hue of color effect is 0 to 100, with is especially confusing.

No, the colour effect goes in a cycle from zero to 200. If you set colour effect to 200 then it does nothing. If you set colour effect to 50, that is NOT the same as colour effect of 150; a colour effect of 150 will shift the hues much further than colour effect of 50, and it is the same as a colour effect of -50.

edward789121 wrote:
id think of it as
set tint value to () % ::looks
tint () % of the way ::looks
since, the tint effect has barely anything to do with other effects, and it could also cause some glitches.

Really…? Hmmm, seems to me that ‘tint’ is fine as a form of effect; it just needs an extra ‘parameter’, which is the colour to use for the tint.

I'm not sure what your blocks above do, though… Are they replacements for “set tint effect to” and “change tint effect by” respectively? The blocks you've given above seem to both have the same meaning when I read them: I interpret both as meaning the same as my “set tint effect to ( )%”. I presume neither of above are setting the actual tint colour, right? (i.e. neither of them are meant to replace "set tint color to [picker]“?)

And why would it ”cause glitches"?

Last edited by TheLogFather (April 5, 2016 17:32:38)

edward789121

thelogfather wrote:
it just needs an extra ‘parameter’, which is the colour to use for the tint.

yeah, that's exactly why.

when you said that ::hat
say (well that would even be the cause of the glitch ::control)
a [reporter  v] [control block!  v] ::control

Last edited by edward789121 (April 8, 2016 17:08:39)

edward789121

TheLogFather wrote:
And why would it “cause glitches”?

cause scratch could accidentally think it was a normal graphic effect.

TheLogFather wrote:
edward789121 wrote:
TheLogFather wrote:
I'm not sure what your blocks above do, though… Are they replacements for “set tint effect to” and “change tint effect by”?
mm hm

Last edited by edward789121 (April 5, 2016 17:49:19)

TheLogFather

edward789121 wrote:
TheLogFather wrote:
And why would it “cause glitches”?
cause scratch could accidentally think it was a normal graphic effect.

It is a normal graphic effect – the tint gets applied by the appropriate amount according to whatever is the currently chosen (or default) tint colour for that sprite/clone. I don't see any problems with Scratch getting confused in any way…?

Last edited by TheLogFather (April 5, 2016 18:01:33)

edward789121

TheLogFather wrote:
It is a normal graphic effect – the tint gets applied by the appropriate amount according to whatever is the currently chosen (or default) tint colour for that sprite/clone. I don't see any problems with Scratch getting confused in any way…?

i thought that it needs an extra parameter.

Last edited by edward789121 (April 5, 2016 18:24:39)

liam48D

edward789121 wrote:
TheLogFather wrote:
It is a normal graphic effect – the tint gets applied by the appropriate amount according to whatever is the currently chosen (or default) tint colour for that sprite/clone. I don't see any problems with Scratch getting confused in any way…?

i thought that it needs an extra parameter.

Yep! The code for the tint effect will just check the sprite internal variable for the tint color, which is set by the set-color block.

DaSpudLord

I support TheLogFather's idea as long as we keep the current color effect.

edward789121

TheLogFather wrote:
neither of them are meant to replace "set tint color to [picker]"?)

thats because the

set tint color to [#ff0088] ::looks //is completely fine

Discuss Scratch