To be honest, I don’t know if it supports palettes (early on, I was assuming it did; but, I never found a way to make that work).
With the disclaimer that the following is just my observations (but it does seem to work OK in practice), below is my current mental model on how sprites/bitmaps work:
I think the PicoSystem is using a color model similar to “True Color” but with only 12 bits of color data (4 bits each for red, green, and blue) plus 4 bits of transparency data to total out at 16 bits. I’m basing the bit count on the format of the _default_sprite_sheet:
My thinking here is that it’s 8 entries across with each entry having 16 bits of data and that seems to line up reasonably well with the 8x8 sprites in the source image from the 32blit project
The ordering is a bit different than I would have expected, I was assuming it would be RGBA; but, it appears to be GBAR based on the comments in blend.cpp.
Walking across the first line of data to the first non-zero pixel, 0xd5f7, when I open the source image in GIMP, I get the values:
- Red: 38.8
- Green: 78.0
- Blue: 30.2
When I multiply those against 15 and convert to integer, I end up with:
- Red: 6
- Green: 12
- Blue: 5
Which feels very close to the values in the library source:
- Red: 7
- Green: 13 (
0xD) - Blue: 5
(I don’t have a good working theory on the variance on red and green; but, the difference there doesn’t stand out to me on screen, so I haven’t worried about it so far).
Additionally, the 0x0 versus 0xF in the third nibble line up nicely with where the source image is intended to be fully transparent versus fully opaque.