Use explicit RGBGFX palette input for Pokemon and trainer sprites?

[Rangi42]

This is an alternative approach to #1079.

We currently rely on the Pokemon and trainer sprite PNGs to be encoded as indexed color, with a four-color palette in the correct order. This is an invisible property of the PNG that's easy to get wrong, and people don't always know to use palfix.py or have trouble using it.

RGBGFX supports explicit palette input, so instead of -c embedded, we would pass it -c "#ffffff,#abcdef,#123456,#000000" to use those four colors in that order.

This would not have to bloat the Makefile. Instead, each Pokemon's front.png+back.png and each trainer's sprite.png would have a corresponding .flags file, containing the "-c "..."" colors. Then the Makefile would be updated to use at-files:

gfx/pokemon/%/back.2bpp: gfx/pokemon/%/back.png gfx/pokemon/%/palette.flags
	$(RGBGFX) -Z @$(word 2,$^) -o $@ $<
gfx/pokemon/%/front.2bpp: gfx/pokemon/%/front.png gfx/pokemon/%/palette.flags
	$(RGBGFX) @$(word 2,$^) -o $@ $<

gfx/trainers/%.2bpp: gfx/trainers/%.png gfx/trainers/%.flags
	$(RGBGFX) -Z @$(word 2,$^) -o $@ $<

This would mean that when you create or edit a Pokemon or trainer sprite, whichever colors you use, you have to update the .flags file to use them too.

This avoids the problem #1079 had of not getting to see your colors used in the PNG. It also avoids the problem of having to update normal.pal colors in 5-bit RGB values, even though you almost certainly edit graphics with 8-bit RGB. (Dividing by 8 is less trivial than you'd think!) Finally, it avoids needing to care how your PNGs are encoded.

[Rangi42]

Superseded by #1137.