8-bit sprite and palette support with drawPixel

[JooJooBee666]

I was trying to figure out what the deal is with the 8-bit sprites and palettes. The demo does not show a palette being set, unlike for the 1 bit and 4-bit sprites. I tried anyhow, but it seems that setting was ignored. My images were drawn, but NOT with the palette I assigned to the sprite. The TFT_eSPI library appears to just simply convert the image colors to the closest match. This was confirmed.

After review of the source, I determined that this was indeed what was happening and apparently by design. Here's the part I'm referring to:

void TFT_eSprite::drawPixel(int32_t x, int32_t y, uint32_t color)
...
  else if (_bpp == 8)
  {
    _img8[x+y*_iwidth] = (uint8_t)((color & 0xE000)>>8 | (color & 0x0700)>>6 | (color & 0x0018)>>3);
  }
  else if (_bpp == 4)
  {
    uint8_t c = color & 0x0F;
    int index = (x+y*_iwidth)>>1;;
    if ((x & 0x01) == 0) {
      _img4[index] = (uint8_t)((c << 4) | (_img4[index] & 0x0F));
    }
    else {
      _img4[index] =  (uint8_t)(c | (_img4[index] & 0xF0));
    }
  }

We can clearly see that this is just automatically converting this to the closest 256 color. Oddly, the 4 bit and 1bit DrawPixel don't even seem to reference the local _colorMap array in this function either. Either way, after a bit more digging in to the palettess, I see that they max out at 16 and if you define more than 16, it simply just chops off the rest.

Can we add support for 8 bit palettes and also support the palettes from the drawPixel function and others? This would allow us to save half the RAM but also get great looking images. On these smaller LCDs, 256 color images that are properly crafted and dithered look just as good as any 16bit color image. The RAM savings alone would be really beneficial.

I tried a few additional edits to the Sprite class to add 256 palette support and also use this in the drawPixel class but I ultimately failed, most likely due to not fully understanding what the whole sprite class is doing and how that translates to the actual screen.

Additional Details: TFT_eSPI version 2.5.43 The rest does not matter, the issue is device/screen agnostic.