The stored sprite data simply says "this is a different colour from that." The palette determines the actual colours used.

Okay, you know when you're playing an RPG and you see an enemy that looks the same but is coloured differently? That's because they swapped to a different palette. It's space saving and the like.

There's a whole category in the Documents section devoted to palette hacking. Check there.

Basically heres how it works. If the picture is 2bpp (2 bits for per pixel) it means that there is a total of 4 different colors possible. Look at the bit combinations.

00
01
10
11

The game assigns a color for each one of those combinations by using a palette. The palette usually tells the game what Red Green Blue color value to display. So in this example there could be 4 possible colors. If it was the first combination of bits it would display the color in the first entry of the palette. On a 256bpp image, there is a total of 256 colors that can be diplayed per pixel. That means one byte for every pixel. That byte tells which palette entry to use for the color of that pixel. Snes can use multiple 16 color palettes or one 256 if I'm correct. I know thats how the GBA works. It can have 16 of 16 color palettes or one 256 color palette.

Either way, some of this stuff is explained in documents but a lot of times its confusing. Heck, I probably just got you even more confused. It really all makes sense when you look how efficient it is for a low level processor like video game systems.

By the way, heres a way to do it. Take a screenshot of the game in ZSNES and export the palette using vSnes and then load it into a tile editor that supports palettes. That simple.

That's painful. I used to put up with that myself.

Nowadays I usually just find some sneaky way to dump the palette and import. I usually leave a little bit of extra space in my graphics files for just that...in Tile Molester, I can import a palette in the file itself, so I just take the palette and wedge it in somewhere.

1. Make a savestate of a scene that shows the graphics and the colors you want to use. (In ZSNES, SNES9x, Super Sleuth or SNESGT.)
2. Get vSNES (utilities section of this site), extract it, start it, load the savestate you made.
3. Open the MemViewer and the PalViewer.
4. Select colors in the PalViewer and see what happens. Browse in the VRAM / WRAM / ROM memory to find more graphics.
5. Select the 2-bit mode if necessary. See what changes when you select colors in the "right half" of the palette.

It's the luck of the draw.

Sprites are made up of many tiles. There's no correct order for the tiles to be in. They are put together via a tilemap in the game. But they don't have to be stored in order at all! It IS like a puzzle. You'll have to figure out how they go yourself. It's the game's tilemap that is loaded when it runs that 'puts the puzzle together' on screen. And even then, that map references tiles in VRAM, so that wouldn't help you much looking at the ROM.

Long story short, that's just the way it is. That's how they are stored. It can be different for each game.

The game companies used utilities most likely to store the tiles and sprites and create the maps automatically. It's not like they had to deal with the graphics like this. This is just one of the hardships of hacking. Get used to it, there will be many more!