Go back to using .pal files for Pokémon and trainers

[Rangi42]

Currently we use rgbgfx to extract the middle two colors from four-color indexed PNGs just for the Pokémon and trainer sprites. The advantage is being able to see just how they'll look in-game. The disadvantage is that some graphics editors can't save as indexed palettes, and even fewer can view and edit the palette directly. It's hard to confirm that there are exactly four palette entries and in the right order. (Some sprites need their darker-color hue to be first, like Swimmer♂.)

Most graphics don't make sense to store their own palettes in the first place, e.g. all tilesets use the same palette set, all overworld sprites do the same, multi-palette graphics need to preserve their palettes' order and distinguish between identical hues in different palettes, and so on. So I think it would simplify things if all graphics used .pal files to specify their colors.

[Rangi42]

This is just a suggestion; I'd like to know what other pokecrystal users think.

[i0brendan0]

I absolutely agree to go back to pal files. Often, certain sprites don’t actually use all 4 colors. They might not have a single color on their back sprite or something. I know from experience that someone was trying to create a backsprite but the colors would break because it was only 3/4 colors.

[mid-kid]

This wouldn't solve anything. Even if you grayscale everything, image editors saving the image as full-color would cause rgbgfx to index the image improperly if it's lacking a shade of gray. Furthermore, rgbgfx should already be generating palettes from full-color (non-indexed) images, and assuming the backsprite uses the same colors, it should go right 90% of the time. The convenience of the current method with the proper tools far outweighs the occasional indexing issue.

Editing gameboy graphics is an unintuitive process by nature due to the way they're indexed and paletted, and this doesn't properly map to "modern" tools (PNG, image editors, etc). While removing one abstraction here forces users to engage with the mechanics of one part of this process, it completely fails to address the other, and puts everyone who does understand this a step back in terms of usability. I can't think of anything short of instructing users to use specific or specialized tools to solve this problem.

[Rangi42]

Even if you grayscale everything, image editors saving the image as full-color would cause rgbgfx to index the image improperly if it's lacking a shade of gray.

I don't think this is the case. Indexing is a non-issue for grayscale images; from rgbgfx(1):

If [the file does not have an embedded palette], and the image only contains shades of gray, rgbgfx maps them to the indices appropriate for each shade. Any undetermined indices are set to respective default shades of gray. For example: if the bit depth is 2 and the image contains light gray and black, they become the second and fourth colors, and the first and third colors get set to default white and dark gray.

For example, gfx/font/overworld.2bpp only uses two hues (#000 and #AAA) but it's converted correctly, and it still is when it's saved as a 24-bit RGB image instead of 4-bit grayscale.

[aaaaaa123456789]

Alternative: get the RGBDS people to add a "use these colors as palette" switch, and detect .pal files and pass the corresponding colors to RGBGFX if there is one.

[Rangi42]

On the one hand, that would let the sprites look colorful without needing to store a correctly indexed palette. On the other hand, changing the palette would then require editing the .pal and also recoloring the .png. IMO even that would be more convenient than editing the palettes right now, since you have to trust that it's saved as four-color indexed with black and white still in the right order.

[ISSOtm]

Since the console's color curve is not correctly understood yet, the route I'm following in the homebrew I'm currently working on is to set input PNGs to indexed and ensure their colors are in the correct order; then the game uses a separate palette file (in text format, xxd -r -p'd back to binary format).

The main advantage of this are that the artists can edit the colors separately.

Alternative: get the RGBDS people to add a "use these colors as palette" switch, and detect .pal files and pass the corresponding colors to RGBGFX if there is one.

Sure, we're aware of it. Why don't you become one of "the RGBDS people", and implement it yourself? :)

[aaaaaa123456789]

Sure, we're aware of it. Why don't you become one of "the RGBDS people", and implement it yourself? :)

I'm already behind on my projects without taking on more of them; I don't want to commit to something I may not have the time to do. And besides, as of last Wednesday morning I don't have a working computer anymore...

[Rangi42]

The problem as I see it is that indexed palettes are invisible in most graphics editors, and even just saving them correctly requires particular programs or a whole suite like GIMP. So a solution that doesn't care what format the PNG is in, only what the actual colors are (i.e. what shades of gray, with a .pal file for the real colors) would solve save/edit issues.

[Rangi42]

People seem to like seeing the colors in the PNGs, and palfix.py at least makes it easier to correct the palette (4 colors, white-light-dark-black in order). So this is unnecessary.

[ISSOtm]

Alternative: get the RGBDS people to add a "use these colors as palette" switch, and detect .pal files and pass the corresponding colors to RGBGFX if there is one.

Currently in progress, with an thing to be able to load CLI args from files in the pipeline :)