ok lol
Well, never mind gamuts, we only get eight bits per color, so each is limited to 255 for maximum intensity. But let's say I'm adding (255, 100, 0) and (255, 0, 100), are the colors limited independently, so the result is (255, 100, 100), or do I preserve ratios, so the result is (255, 50, 50)?
Uh, I have actually no idea what this is, we should probably move the discussion of making the blocks to Advanced Topics? And also add an explanation for what you are even saying. I do not want conversations that should be in Advanced Topics be in other categories.
Although I am not either of them, I will do my best to help explain some of this.
Have you heard of the term "8-bit game"?
First, some other context: A bit is a single character that's either a 1 or a 0. Think of it like an on/off switch. If you only had one bit to work with, there would only be two possible combinations, right? On and off.
But when you add more bits, you can make more combinations. With 2 bits, you can have on/on, off/on, on/off, off/off, ... right?
A byte is a collection of however many bits. The amount of combinations for the byte is two to the power of its amount of bits. The maximum amount of values for an 8-bit byte to have is 255.
Now, remember how number values are handled in colors. The red, green, blue, and alpha values are all 8-bit bytes.
To simulate the mixing of light-based colors, add up the red of color 1 to the red of color 2, the green of color 1 to the ... etc, etc. and make a new color with those values.
(While I was typing this, I remembered: @rdococ, you can set an R/G/B/A value larger than 255 in a costume and it will automatically shorten it for you.)
Thank you, I already understand bits and sometimes use them In scratch games! You have explained perfectly
You can't have it both ways! :~) And I don't think you're entitled to tell other people not to discuss something that's clearly on-topic.
Minor quibble: There are 256 values, from 0 to 255 inclusive.
Ah, right.
@rdococ , just wanted to ask, would this YouTube video be right? (sort of)
You need to press the up button actually
i'm just confused---whats the diff between a color and a first class color
okay then i'll wait for him to answer then
A data type is first class in a programming language if it can be
- the value of a variable
- a member of a data aggregate (a list, in Snap!)
- an input to a procedure
- the value reported by a procedure
So for example in Scratch, lists aren't first class, because you can't make a list of lists, or write a custom block that reports a list, etc. But in Snap! you can do those things, so lists are first class in Snap!.
First classness is a property of a data type, not of a specific value. So don't think some colors are first class and others aren't.
The new Colors and Crayons library (coming soon) makes colors first class: you can make a list of colors, etc. The application everyone is clamoring for is a MIX block that takes two colors as inputs and reports the color you get by mixing them.
When exactly will the new code for Colors and Crayons be deployed?
Why do you expect them to know exactly when it will release?
When I finish writing it! :~P
The immediate issue I'm working on is getting the top half and the bottom half to look the same:
As you can see, it's not terrible, but it needs work, especially in the browns and the purples.
The top half is the Colors scale; the bottom half is the colors I get by asking for the closest Color-scale color to a given color, when I use the Color-scale colors as inputs (so the output should be the same).
I mean, an estimate of the time it will take.
@bh , Isn't that a result of
Doesn't that mean you are using an approximation to make the bottom half, Of course it wouldn't be the exact same as the top half.
Can I have the latest build of the new colors and crayons library?
The link is the same as before:
https://snap.berkeley.edu/snap/snap.html#present:Username=bh&ProjectName=fix%20colors
Here's how the bottom half is made:
The first SET PEN block sets the color to (exactly) one of the color numbers. CURRENT PEN COLOR reports that color (first class data, remember), still exactly right. Then I use COLOR NUMBER FROM COLOR to try to find the closest color number to the color. Since the input color /is/ one of the color numbers, I would expect to get exactly the right color number. And then I use that to set the pen color again.
Nevertheless, I don't insist that the COLOR NUMBER FROM COLOR be exactly right, but it should be close enough so that a user won't notice unless they're paying close attention to the color.
One could argue that I really don't need to accept any color at all and find the closest color number. But other FROM COLOR options clearly work, e.g., RGB FROM COLOR, HSL FROM COLOR, etc. Color numbers, being a one-dimensional space, don't include every possible RGB color, though.
Interesting...
How many of the color numbers would you need to make it close enogh to