I suggest having a way to input RGB values into your pen color, either as percentages or from 0 to 255, because this way you can find an exact color. This would also be helpful in the paint editor.

Color channels go from 0 to 255, not 1 to 155. You can already input them like this:

set pen color to (((((256) * (256)) * (r)) + ((256) * (g))) + (b))

or

set pen color to (join [0x] [hexadecimal number])

Be sure to use the set pen color block with the color input, not the number input.

Chibi-Matoran wrote:

set pen color to (join [0x] [hexadecimal number])

.

I think you mean the number input not the color input. The second one is an interesting hack that I haven't seen before. Does Scratch support hexadecimal numbers in other places?

Blaze349 wrote:

Chibi-Matoran wrote:

set pen color to (join [0x] [hexadecimal number])

.

I think you mean the number input not the color input. The second one is an interesting hack that I haven't seen before. Does Scratch support hexadecimal numbers in other places?

They definitely mean the color input.

The difference is that this one, the number input, takes a “hue” (a number in range 0-200, which wraps):

set pen color to (100)

..And this one, the color input, takes a “color” (a number in range 0-4294967295 – hexadecimal FFFFFFFF):

set pen color to [#EE9933]

Both of them accept numbers, but one expects a “hue” number, and one expects a “color” number. When we say “the number input” we mean the one with a literal number slot (i.e. the one that takes a “hue”).

Edit: Also, yeah, Scratch supports hexadecimal numbers just about anywhere you can put a normal number. You know how you can put numbers like 3e5 and 7e2 anywhere*, and they'll always be seen as 300000 and 700? The 0x syntax is the same.

* Except in text input slots, of course. Anywhere they're converted to a number, they'll turn from e.g. 3e2 to 300 or 0x10 to 16 (so you can do “1 * answer” or “0 + answer” to convert the ask-and-wait answer string into a normal number).

_nix wrote:

They definitely mean the color input.

The difference is that this one, the number input, takes a “hue” (a number in range 0-200, which wraps):

set pen color to (100)

..And this one, the color input, takes a “color” (a number in range 0-4294967295 – hexadecimal FFFFFFFF):

set pen color to [#EE9933]

Both of them accept numbers, but one expects a “hue” number, and one expects a “color” number. When we say “the number input” we mean the one with a literal number slot (i.e. the one that takes a “hue”).

Wow. I've been on Scratch for a long time but never realized you could enter numbers into the color picker. I'm going to try it now.

Chibi-Matoran wrote:

Color channels go from 0 to 255, not 1 to 155. You can already input them like this:

set pen color to (((((256) * (256)) * (r)) + ((256) * (g))) + (b))

or

set pen color to (join [0x] [hexadecimal number])

Be sure to use the set pen color block with the color input, not the number input.

No support based on the second workaround here, provided it continues to work.

Anyone using custom colors like this will most likely have a hex color (or be able to find a converter for dec -> hex).

Blaze349 wrote:

Does Scratch support hexadecimal numbers in other places?

[somewhat off-topic, but worth knowing…]
Scratch supports hex *input* for numerical values everywhere. All you have to do is prefix the hex digits with “0x” (or “0X”).

BTW, I *don't* mean that you can type a hex value into a round-ended numerical input slot. What I mean is that you can drop in an expression, such as the “join” one give in the previous post, that is a string of hex digits preceded by the prefix.

TBH, though, I think the most useful place for this is to store data more efficiently in cloud variables, since it means you can work in base 22 rather than base 10. (And when you're doing that, you're not actually using it as a numerical value, but to encode data.)

Yes, hex is base 16 – so why base 22…?

The reason is because cloudvars will allow any *string* that the server considers to be numerical, and it will retain that string exactly as it was given. That means that the *case* is retained, so you can use the alphabetic hex digits a-f and A-F (for example “0xDeadBeef” will retain the capitalisation).

There are also some other strings that are accepted in cloudvars, such as “Infinity”, “-Infinity”, “false”, “true” – all because the cloud server considers them to be numerical, with “true” and “false” corresponding to one and zero respectively.

Here's an example of cloud encoder that uses hex: https://scratch.mit.edu/projects/88755597/
[/somewhat off-topic, but worth knowing…]


Getting back on topic, it might be worth me noting that the “set pen color” block (the one with the square colour-picker) isn't just 24 bit RGB, but actually full 32 bit ARGB – so it *also* supports transparency via the leading ‘A’ (alpha) component.

set pen color to ((((A)*(16777216)) + ((R)*(65536))) + (((G)*(256))+(B)))

Setting A=255 gives fully opaque pen, while A=1 gives (very very nearly) completely transparent.

For historical reasons, Scratch considers an alpha value of zero to also be fully opaque (just like A=255).

Here's a project that demonstrates use of pen transparency (and RGB) to draw moving semi-transparent polygons:

https://scratch.mit.edu/projects/62499800/

Not sure if it's been noted, but I did notice the “0xRRGGBB” method also supports alpha, in the form of “0xAARRGGBB”. Here's a project demonstrating that.

Chibi-Matoran wrote:

Color channels go from 0 to 255, not 1 to 155.

Whoops, gotta fix that.

Tymewalk wrote:

Not sure if it's been noted, but I did notice the “0xRRGGBB” method also supports alpha, in the form of “0xAARRGGBB”. Here's a project demonstrating that.

Yes, the 16777216 TheLogFather posted above is 0x01000000.