So I was messing around with GSAVE, and I noticed how, the 32 bit mode output isn't compatible with any of the graphics commands. (At first I thought that was normal, since GCOLOR and the like always references 8 bit values. Which, I now know meant 8 bit values for each color and alpha
After a little more messing around though, I found that dividing the GSAVE result, then bitshifting to the left (I think) will give you the same number that GSPOIT would give you. Which got me to check a binary conversion sight to see what the GSAVE decimal number would give you and. It ended up having the same binary result as the GSPOIT number.
I'd already found my answer for what I trying to figure out by that point, but. I, always chase programming rabbit holes cause i'm dumb, so I had to figure out why it does that, what the correlation was and.
I googled how negative numbers and binary works, and the first result mentioned using the left most bit as a negative number flag and.
Yeah, is that it? I guess you wouldn't notice it with most smaller numbers.
asasidenote
I wondered if you could use that divide and bitshift method to convert GSAVE values into G command readable values.
For a sec I thought that could cause an error, since the rightmost bit would be destroyed but.
After some more experimenting and reading GCOLOR's description, I guess the actual colors that get displayed are in increments? And as far as I can tell it's impossible to get a number from GSPOIT that would have the right bit set anyhow.
This is called two's complement. The high bit is not strictly a flag, because then all zeroes with the high bit set would be negative zero (which IS defined for floats but doesn't make sense anyway.) Think of it like this: the actual binary number is in the low 31 bits. If the top bit is set, then 231 is subtracted from the value in the low 31 bits, to get your actual number. This eliminates negative zero and gives you one more step of precision in the negatives. This is also why all bits on is -1 and not -(231-1).
Replying to:
snail_This is called two's complement. The high bit is not strictly a flag, because then all zeroes with the high bit set would be negative zero (which IS defined for floats but doesn't make sense anyway.) Think of it like this: the actual binary number is in the low 31 bits. If the top bit is set, then 231 is subtracted from the value in the low 31 bits, to get your actual number. This eliminates negative zero and gives you one more step of precision in the negatives. This is also why all bits on is -1 and not -(231-1).
Ooh, I see I see, interesting!
Is it me, or is the top 8 (i think) bits completely arbitrary?
When I looked into it, those bits are usually used to represent the Alpha value, but as far as I've seen through messing around, they're either all on or all off.
Replying to:
Gaelstrom_ValenceIs it me, or is the top 8 (i think) bits completely arbitrary?
When I looked into it, those bits are usually used to represent the Alpha value, but as far as I've seen through messing around, they're either all on or all off.
GRP pixel colors in SB3 are actually 16-bit, like PTC palette colors. It's an illusion. There's only 1 bit for "alpha" (opaque flag) and 5 bits per color channel. The 32-bit RGB notation is just a convenience because it is used for SPCOLOR filtering (including alpha.)
Yeah this becomes obvious when you set down some pure white pixels (255, 255, 255) and they come back through gspoit as (248, 248, 248). The color range is truncated from 32 to 16 bit.
(Each color channel is actually 5 bit and goes from 0-31. Conversion to 8-bit is just a multiplication by 8. Max value 31 times 8 is 248.)
