[SM] How are Samus (and indeed, all enemy sprites') palettes stored?

[Munchy]

Hiya,

Super Munchtroid related question: ideally, I'd like to read the palettes for samus (and/or enemies) directly from the ROM rather than asking the user to import them.  I'm trying to work out from the addresses hard-coded in JSM (the Java Super Metroid "sprite viewer" someone wrote a while back) exactly where the relevant palettes are stored.  In a nutshell, I'm not seeing a direct translation of a TPL in the ROM and I'm struggling to find anything in HexD that matches up.

e.g. here's a default power-armour samus palette TPL

Code Select Expand


00000000: 54 50 4C 00 00 00 70 40 40 00 E8 E8 00 28 00 28    TPL...p@@.hh.(.(
00000010: 00 F8 70 40 68 40 F8 E0 A8 90 B0 90 70 90 70 D8    .xp@h@x`(.0.p.pX
00000020: 28 00 A8 A8 00 58 58 00 90 90 00 20 40 20 A0 18    (.((.XX.....@...
00000030: 00 68 00 00                                                            .h..


and here are the palette references in JSM:

Code Select Expand


// Samus
    SAMUS_POWERSUIT(0x9B9400, true, false, 32),
    SAMUS_POWERSUIT_SCREWATTACK(0x9B9CA0, true, false, 160),
    SAMUS_VARIASUIT(0x9B9520, true, false, 32),
    SAMUS_VARIASUIT_SCREWATTACK(0x9B9EA0, true, false, 160),
    SAMUS_GRAVITYSUIT(0x9B9800, true, false, 32),
    SAMUS_GRAVITYSUIT_SCREWATTACK(0x9BA0A0, true, false, 160),

    // Misc.
    TITLE_STUFF(0x8CE1E9, true, false, 32),
    INTRO1(0x8CE4C9, true, false, 32),
    INTRO2(0x8CE3E9, true, false, 256),
    INTRO3(0x8CE569, true, false, 32),
    PAUSE_SCREEN(0xB6F000, true, false, 512),
    TITLE_METROID(0x8BA2B9, true, false, 128),

    BEAM(0x90C3E1, true, false, 32),
    SPORE_SPAWN_DAMAGE_GRADIENTS(0xA5E359, true, false, 32),
    SPORE_SPAWN_FOREGROUND_GRADIENTS(0xA5E4F9, true, false, 32),
    SPORE_SPAWN_BACKGROUND_GRADIENTS(0xA5E5D9, true, false, 32),
    GOLD_TORIZO(0xAA8787, true, false, 32),
    PALETTE_BLEND(0x89AA02, true, false, 32),

    NINTENDO_LOGO(0x8CE2E9, true, false, 32),

    CREDITS(0x8CE9E9, true, false, 0xFE),
    RATE_FOR_ITEM_COLLECTION(0x8CE8A9, true, false, 0xFE),

    SAMUS_ENDING1(0x8CE9A9, true, false, 32),
    SAMUS_ENDING2(0x9A8140, true, false, 32),
    SAMUS_ENDING3(0x8CE829, true, false, 32),


i've looked at address 0x9B9400 (the power suit address above) and it's either formatted totally differently from a TPL file or some kind of reference to the data I need (obviously it won't have the "54 50 4C" at the start of it haha!).  I'm struggling to get my head around what it's pointing to; I'm guessing it'll be a table offset but I can't find the reference in JSM.

any clues/explanations please?

[Crashtour99]

Yeah, the way the SNES does palettes is totally different from what you'll see in an editor like TLP.
In the SNES, a full palette line is 32 bytes ($1F) long, with each pair of bytes defining a color.
I can't remember just how the colors are defined by the bits in the byte pairs. 
IIRC though the highest bit is ignored, and the other bits are divided into 3 5-bit groups that give a value for the Red, Green, and Blue.
xrrr rrgg gggb bbbb  <--- something like that.
For the vast majority of sprites in SM, the palette line will start off with the values $00 $38 to define the first transparent color.
So if you're following a pointer looking for a palette and you see that, it's probably what you're looking for.
There should be information on how the SNES encodes palettes on the net, so a google search should yield results easily enough.

[Munchy]

Yeah, the way the SNES does palettes is totally different from what you'll see in an editor like TLP.
In the SNES, a full palette line is 32 bytes ($1F) long, with each pair of bytes defining a color.
I can't remember just how the colors are defined by the bits in the byte pairs. 
IIRC though the highest bit is ignored, and the other bits are divided into 3 5-bit groups that give a value for the Red, Green, and Blue.
xrrr rrgg gggb bbbb  <--- something like that.
For the vast majority of sprites in SM, the palette line will start off with the values $00 $38 to define the first transparent color.
So if you're following a pointer looking for a palette and you see that, it's probably what you're looking for.
There should be information on how the SNES encodes palettes on the net, so a google search should yield results easily enough.

@Crashtour99  thank you as always! You are a gentleman and a scholar  :grin: and of course, God bless the SNES for having a bizarre palette setup  :lol:

looks like I'm on the money with those references in JSM, they do indeed point to 00 38 as you mentioned

and, according to a CGRam tutorial I've just read, each palette color is 1 word: 0BBBBBGG GGGRRRRR
https://megacatstudios.com/blogs/press/super-nintendo-graphic-guide (for anyone interested, search for
"Color Graphics RAM")

[Munchy]

yep, simples, you just shift whichever palette forward by 3 places and you have the same output as in TLP! :) piece of cake!

[Munchy]

That does beg the question: if each colour can be 0-31 and that can be shifted 3 places to get a colour in 255, what does something like SMILE do with dark colours? Because when you shift them back into the ROM, you're gonna lose the bottom 3 bits  :pwuh:

I must be missing something or else SMILE is making BIG assumptions about palettes when you export tpls (which I somewhat doubt). It seems kinda weird to me however: why wouldn't the results simply convert over percentages? That'd give you a much more reliable approximation between 31 and 255.

I'm gonna do some experiments...

[Smiley]

what does something like SMILE do with dark colours?

The same it does when importing any 8-bit color; divides the value by 8 (=shifts three bits) and writes the result. Try looking at exported palettes, you'll notice the RGB color values are always multiples of 8.

[Munchy]

yep, looks that way  :^_^: ergo shift N << 3  and 3 >> N to get the desired shade;  There's a debate one can have about whether it'd be more faithful to work via percentages and rounding but - as far as I can see - the difference would be so small as to be academic.  cheers @SMILEuser96 !