The pixel screen currently defines the colors as 256*R//8-1, 256*G//8-1 and 256*B//4-1. This does not allow for maximum brightness as each component can only reach one less than its respective divisor.
The correct calculations are 255*R//7, 255*G//7 and 255*B//3. It doesn't make for very bit-friendly math sadly, but it would look a lot better (at least, as long as we're restricted to only having 8-bit RRRGGGBB available - 16 bit color or custom palettes would make it far less relevant, though still slightly problematic if it's using 256*R//32-1 as you'd still not quite hit full brightness... 247 is a lot closer than 223 though!)
#[ALPHA] Pixel screen better color representation
earnest thorn
lilac ore
FWIW, you can get it done with bit-friendly math just by repeating the smaller bit patterns until they fill (or exceed) the bigger bit width.
i.e.
B8 = B2 * 0b01010101
G8 = (G3 * 0b01001001) >> 1
R8 = (R3 * 0b01001001) >> 1
which is equivalent to
B8 = (B2 << 6) | (B2 << 4) | (B2 << 2) | B2
G8 = (G3 << 5) | (G3 << 2) | (G3 >> 1)
R8 = (R3 << 5) | (R3 << 2) | (R3 >> 1)
-# I'm just starting with blue as it has the more obvious calculation due to it fitting exactly
earnest thorn
oh nice that even gets the rounding right on for 72/73 and 218/219 (my //7 truncates) 😄
lilac ore
you could easily fix your rounding by adding 3 before dividing by 7, though
(not that it would be easy to distinguish the color difference in the least significant bit anyways)
odd crow
Honestly, it would be nice to just have 24-bit color back.
earnest thorn
yeah i would think that's more of a "stuff's changing a lot right now" issue... the RAM/ROM interfaces have been undergoing a fair bit of work lately and if that was planned (or at least thought about) back when pixel display was added it may have just been a "we don't know what multi-byte access will look like yet so let's not make a mess until we need to)... y'know or not haha maybe I'm just reading too much into it 😄
hollow scaffold
would be more convenient since we make a 16-bit computer with no byte addressing capability. I know 16-bit isn't as easy to work with as 24-bit in a way, but how often are you doing color calculations vs a predefined palette?
lilac ore
Not sure where a palette (CLUT) comes in here. The byte contains intensities for all 3 color channels directly, just lower resolution than 24 bit. You can directly map a 24 bit color to this kind of 8 bit color (especially when you have control over bit wires like in TC) without doing anything difficult. It'll just look like some kind of "posterization" effect was added to the image. Or you could describe it as "banding" if you have lots of color gradients.
Or in other words, if you want a different bit depth for displays that would warrant a separate feature request (if there isn't one already)