A color is made up of four bytes. 32 bits. A long int. In Blitz, all ints are long ints.
The colors are arranged like so:
ARGB
Each letter is one byte.
The significance of the $ is that it means that number is in hexadecimal. Hexadecimal is a base 16 system. Decimal, the normal number system you use is base 10. Base 10 has 10 digits, 0..9. Base 16 has 16 digits. 0..9 then A..F
In hexadecimal:
$09 or just $9 = 9
$0A = 10
$0B = 11
$0F = 15
$10 = 16
$11 = 17
You can see where this is going. $FF in hexadecimal is 255. And 255 is the highest value a byte can have. So, if we use hexadecimal we can write numbers in a shorter manner. And this comes in useful when dealing with bytes. We could re-write our byte structure for our colors like so:
AARRGGBB
Then we could write a hexadecimal number to fit that:
$FFFFFFFF
See how the red mask for bitdepth 3, 24bit format has $FF0000 for red mask? Well $FF0000 is equivalent to $00FF0000 And when you compare THAT to the ARGB structure I listed above, you can see the FF falls right on the red byte. So that is saying that the red byte should be 255.
Now if the red byte is 255 but all the others are 0, then you could caculate what the number is in decimal like so:
AA * 16777216 + RR * 65536 + GG * 256 + BB
So $00FF0000 is 16711680
Now the reason those masks are what they are is because they are telling the program which BITS in the bytes actually make up each color. The AARRGGBB thing only applies in 24 bit and 32 bit color mode. In 16bit color mode, each color bits into TWO bytes, so you have to squeeze the red green abd blue into there. (No alpha)
Each byte is 8 bits, 1 or 0. With two bytes, you have 16 bits. And if we write out the way the 16 bit color is stored you get one of two methods.
I'm not going to bother figuring out if this is correct or not, but if each letter is a bit, then you either have 565 or 555 format for a 16 bit color. That means 5 bits of blue, 6 of green, then 5 of red. I'll just do the 565 since I think I can get that right without deciphering the hex in his code:
BBBBBGGG GGGRRRRR
That's two bytes, and as you can see, the green spans the two bytes because it can't fit into one or the other.
Well that should answer your question.
The colors are arranged like so:
ARGB
Each letter is one byte.
The significance of the $ is that it means that number is in hexadecimal. Hexadecimal is a base 16 system. Decimal, the normal number system you use is base 10. Base 10 has 10 digits, 0..9. Base 16 has 16 digits. 0..9 then A..F
In hexadecimal:
$09 or just $9 = 9
$0A = 10
$0B = 11
$0F = 15
$10 = 16
$11 = 17
You can see where this is going. $FF in hexadecimal is 255. And 255 is the highest value a byte can have. So, if we use hexadecimal we can write numbers in a shorter manner. And this comes in useful when dealing with bytes. We could re-write our byte structure for our colors like so:
AARRGGBB
Then we could write a hexadecimal number to fit that:
$FFFFFFFF
See how the red mask for bitdepth 3, 24bit format has $FF0000 for red mask? Well $FF0000 is equivalent to $00FF0000 And when you compare THAT to the ARGB structure I listed above, you can see the FF falls right on the red byte. So that is saying that the red byte should be 255.
Now if the red byte is 255 but all the others are 0, then you could caculate what the number is in decimal like so:
AA * 16777216 + RR * 65536 + GG * 256 + BB
So $00FF0000 is 16711680
Now the reason those masks are what they are is because they are telling the program which BITS in the bytes actually make up each color. The AARRGGBB thing only applies in 24 bit and 32 bit color mode. In 16bit color mode, each color bits into TWO bytes, so you have to squeeze the red green abd blue into there. (No alpha)
Each byte is 8 bits, 1 or 0. With two bytes, you have 16 bits. And if we write out the way the 16 bit color is stored you get one of two methods.
I'm not going to bother figuring out if this is correct or not, but if each letter is a bit, then you either have 565 or 555 format for a 16 bit color. That means 5 bits of blue, 6 of green, then 5 of red. I'll just do the 565 since I think I can get that right without deciphering the hex in his code:
BBBBBGGG GGGRRRRR
That's two bytes, and as you can see, the green spans the two bytes because it can't fit into one or the other.
Well that should answer your question.