Color Palette Fix for Pokemon GBC Games.

[Joshua2580]

Hi! Stumbled onto this fork when trying to get peanut setup with my ESP32-S3 and attempting to run a ROM hack of Pokemon yellow that converted the game into GBC color palette. When it launched it didn't look right. Tried the same thing with Gold, and Crystal, and there were still issues with the palette. To make sure I wasn't going crazy I tried on the windows .exe you put out and ended up running into the same palette issues there. In debugging I found that the BRG555 to RGB565 conversion was off. In bgr555_to_rgb565_accurate: (c & 0x001F) << 11 places red in the RED position instead of the BLUE position, so adjusting the conversion tweaks the color palette.

static inline uint16_t bgr555_to_rgb565_accurate(uint16_t c)
{

    // Conversion: B->B (bits 10-14 -> 0-4), G->G (expand 5->6 bits), R->R (bits 0-4 -> 11-15)
    uint16_t b = (c & 0x7C00) >> 10;                          // Extract blue (bits 10-14)
    uint16_t g = (c & 0x03E0) >> 5;                           // Extract green (bits 5-9)
    uint16_t r = (c & 0x001F);                                // Extract red (bits 0-4)
    
    uint16_t r565 = r << 11;                                  // Red -> Red position (bits 11-15)
    uint16_t g565 = ((g << 1) | (g >> 4)) << 5;              // Green expansion 5->6 bits, then shift to position (bits 5-10)
    uint16_t b565 = b;                                        // Blue -> Blue position (bits 0-4, no shift needed)
    
    return r565 | g565 | b565;
}

This adjustment fixed the color palette for Static Yellow (Hack), Crystal, and Gold.

In purple is the palette before the conversion change. Orange skies is after.

[Mr-PauI]

Thanks for mentioning what you discovered! I'll review this and correct the function. I have done no testing with rom hacks specifically, but I did test with the SDL demo and can see clearly the color issue. What is a little confusing is that I am not seeing this issue with my esp32-s3fn8 implementation, which is where I do primary development of the project. The function to convert color is only called when a palette entry is updated, so typically the speed of this conversion is not a bottleneck.

[Joshua2580]

Appreciate the response! The rom hack I believe just imports the palette from the gbc special yellow edition, because testing regular Yellow for gbc showed the same palette issues there. I have a waveshare ESP32-S3 with the 1.69" LCD for a small desk ornament project I am working on. I was able to get the esp to host its own webserver to use a wireless controller and implemented a basic tasbot to record my inputs over an hour of playing and just looping that back over. Still testing everything and working on a case design for it, but things are going really well! Appreciate your work on this project to make this little guy possible.

[Mr-PauI]

I'm delighted to hear about it! It was my hope others could benefit from the project. I'm developing the esp32-s3fn8 version on the m5stack Cardputer. This issue you mentioned should be fixed in the latest release.

The red channel was not in the wrong position; the issue was that the green channel expansion was being applied before isolation, which caused green bits to spill into the red channel.

The fix was to extract each channel first, then perform the 5→6-bit green expansion in isolation before placing the channels into RGB565:

static inline uint16_t bgr555_to_rgb565_accurate(uint16_t c)
{
    uint16_t r = c & 0x001F;        // bits 4–0
    uint16_t g = (c >> 5) & 0x001F; // bits 9–5
    uint16_t b = (c >> 10) & 0x001F;// bits 14–10

    g = (g << 1) | (g >> 4);        // 5 → 6-bit expansion

    return (r << 11) | (g << 5) | b;
}

In my SDL build this resolved the color issues matching perfectly with existing screenshots for Oracle of Seasons