Fix Endianness issues with sprite decoding

Sprite decoding was broken on Big Endian CPUs (such as AMD or the Nintendo 64 MIPS CPU), while working
on Little Endian CPUs (Intel): the color palettes came out wrong because they were stored as little endian.

Now we byte swap the 16-bit colors when reading them from the rom/cartridge if running on a big endian CPU, which
solves the issue (while still remaining compatible with Little Endian CPUs)
This commit is contained in:
risingPhil 2024-08-09 12:50:05 +02:00
parent bd95cc3ef8
commit bb3d88172d
2 changed files with 3 additions and 8 deletions

View File

@ -271,8 +271,6 @@ void Gen1GameReader::readColorPalette(uint8_t paletteId, uint16_t* outColorPalet
{
uint16_t* cur = outColorPalette;
const uint16_t* end = cur + 4;
uint8_t byte1;
uint8_t byte2;
// based on https://datacrystal.romhacking.net/wiki/Pok%C3%A9mon_Red_and_Blue/ROM_map
// and https://bulbapedia.bulbagarden.net/wiki/List_of_color_palettes_by_index_number_(Generation_I)
@ -280,10 +278,7 @@ void Gen1GameReader::readColorPalette(uint8_t paletteId, uint16_t* outColorPalet
romReader_.seek(romOffset + (paletteId * 8));
while(cur < end)
{
romReader_.readByte(byte1);
romReader_.readByte(byte2);
// stored in little endian -> least significant bits of the 16 bit value are stored first
(*cur) = (((uint16_t)byte2 << 8) | byte1);
romReader_.readUint16((*cur), Endianness::LITTLE);
++cur;
}

View File

@ -358,9 +358,9 @@ bool Gen2GameReader::readColorPaletteForPokemon(uint8_t index, bool shiny, uint1
(*curColor) = 0x7FFF;
++curColor;
// only the second and third color are actually stored in gen 2
romReader_.read((uint8_t *)curColor, 2);
romReader_.readUint16(*curColor, Endianness::LITTLE);
++curColor;
romReader_.read((uint8_t *)curColor, 2);
romReader_.readUint16(*curColor, Endianness::LITTLE);
++curColor;
// last color is always black
(*curColor) = 0;