Colors made using the clr_rgba extension primitive use a float range of 0-1 for alpha, with 1 being fully opaque (including using the clr_channel primitive) , while colors made a list in a color input use an integer range of 0-255 for alpha, with 255 being fully opaque. This is kinda weird behaviour, and it doesn’t make sense to have one versus the other. However, I am fully aware there might be projects that use this behaviour and would break if it were to change. Does anyone know why this decision was made?
Before first class colours, the RGB was stored as 0-255 and the A from 0-1, only being sometimes used in extension primitives. When they were formally introduced, they changed it to 0-255 for ALL in RGBA.
You shouldn’t use clr_rgba anymore, and I think it should be kept that way for backward compatibility. Instead, pass-in a 3-4 item list in the first input slot of colour [#911a01] ::pen reporter to create a colour from RGB(A).
Wasnt aware it was deprecated - I’m going to implement this change in my projects!
No, the pixels of costume block has always returned 0-255 for alpha, and internally the alpha has always, and still is, stored as 0-1. It’s just user facing it’s 0-255.
I’m sorry.
What would be the benefits of storing alpha as a float and converting it to an integer instead of the other way around? It just seems confusing to me
to simplify the conversion to a string I guess
the Color class was originally built for morphic and wasn’t meant for usage in blocks except for set pen color to [ ] or set background color to [ ] until recently I presume
It’s stored as a float because that’s pretty much how alpha is done in programming. My guess for converting it to 255 for the user is to make it consistent with the other values, and make it easier for students to understand (they won’t see the float).
i would have guessed alpha was stored as an 8-bit integer, same as the other channels…