Use grayscale PNGs plus normal.pal files for Pokemon and trainer sprites

[Rangi42]

We used to have .pal files for Pokemon and trainer sprites. Then we switched to using rgbgfx, and extracting the indexed palettes from the PNGs themselves. (But still using shiny.pal for the shiny Pokemon palettes.)

I'd prefer to go back to that system. The benefits:

• No more generating and INCBINning normal.gbcpal versus INCLUDEing shiny.pal.
• No more questions about how to fix palette errors that end up recommending tools/palfix.py.
• Tool scripts can read/edit .pal files easily as plain text, e.g. to look for normal+shiny palettes that are too similar, or apply filters to the RGB values, etc.

The main downside would be not having visibly colored sprite PNGs. But I don't think that's really necessary: all the graphics except sprites are necessarily grayscale and it works out, plus, shiny colors already can't be viewed that way. We could extend or replace tools/bpp2png, which can already combine a .2bpp and a .gbcpal to create a colored PNG, and instead take a grayscale PNG plus a plain text .pal and likewise create a colored PNG. (We should also have a tool to view any .pal file directly as a bunch of color swatches.)

[Rangi42]

@Idain points out that a tools/makepal.py script would be useful to generate .pal files from people's pre-existing custom indexed-color PNGs or .gbcpal files.

[Idain]

Yeah. That way, custom projects who want to update their code to modern pokecrystal standars won't have to create new normal.pal files manually.

[mid-kid]

Out of concern for consistency with other decompilation and hacking projects, as well as the years of precedent in pokecrystal spriting, I'd really avoid doing this. Only the middle of your points has any sort of weight in terms of usability, and I really don't think the cost outweighs the benefit there.

For point 1, you can always generate a normal.pal in order to have consistency of INCLUDE, or follow the gen3 and gen4 decomp's examples of storing the shiny colors in the backsprite (although I'm skeptical of ordering issues with that one, might want to check up on the situation with gen3).

For point 3, PNG is so trivial a format, especially when it comes to the palette data, that I don't consider it a benefit at all.

In all, I think the current situation is better, even if it means people need an extra tool to fix palette indexes. Most people will be drawing their sprites in color, and I personally do this even if the palette in the PNG ends up not being used, though that's easier to rationalize as I know what's going on.