search

grunt-lucas / porytiles

Overworld tileset compiler for Pokémon Generation 3 decompilation projects
MIT License
30 stars 3 forks source link

Decompile-primary creates images with the wrong palette #45

Closed SPMoo66 closed 4 months ago

SPMoo66 commented 4 months ago

Using decompile-primary to decompile the primary general tileset of pokeemerald generates top/middle/bottom images, but all seem to be created with the wrong palettes.

This is the main green color of the grass tile from the bottom.png that is generated- image

This should be the color that matches color 13 in palette 2, but it does not match, as shown here in porymap's palette editor- image

This isn't the only color that doesn't match. I found that at least colors 9, 11, 12, and 14 from palette 2 also did not match, but did not test all. I believe this issue may be causing tilesets to not compile correctly when custom tiles are used in combination with decompiled tiles. For example: Input vs. Output in porymap image image

Environment:

grunt-lucas commented 4 months ago

The reason for this is because when you decompile a tileset, Porytiles is reading the colors from the compiled .gbapal palettes, which have been truncated to BGR15 format. So you are losing 3 bits of precision. When Porytiles expands a BGR15 to an RGB32, it simply 0s out the additional bits.

Porymap is reading the pre-compiled PAL files, which contain RGB32 colors with those extra bits set. Those bits are shaved off by gbagfx when the pre-compiled JASC PAL files are compiled into .gbapal files.

In your example, Porymap is showing 115 197 164, and Porytiles is showing the decompiled version of that color as 112 192 160. This is expected, because (115 >> 3) << 3 == 112, (197 >> 3) << 3 == 192, (164 >> 3) << 3 == 160. It's pretty clear if you look at the bit patterns:

115 ==
0111 0011 <-- if we shave these last 3 bits, we get

0111 0000 ==
112

You can do a similar exercise for the bit patterns of 197 and 164, and you'll see that the results match up with Porytiles's output.

It's also worth noting that in-game, the color difference due to that extra precision is eliminated, since the RGB32 colors Porymap shows you get converted to BGR15 by the compilation process. Porytiles has a couple compilation warnings that will tell you when you are using two RGB32 colors that appear distinct, but that collapse to the same BGR15 in-game: https://github.com/grunt-lucas/porytiles/wiki/Warnings-and-Errors#-wcolor-precision-loss

grunt-lucas commented 4 months ago

@SPMoo66 That being said, I'd like to know more about the weird color artifacting you are seeing, specifically in those snow tiles you linked. That may be a genuine issue, it's not related to the first issue you described. If you could get me some more data on what you did there, and open a new issue for that, I'd love to investigate. Thanks!

SPMoo66 commented 4 months ago

Now that you explain it, it does make more sense to me. Porymap was showing the color difference, but now that I check in game again the colors appear to match properly. Even with the warnings enabled it didn't quite connect with me that that was the thing happening.

As for the artifacting I'll try to gather some more information and follow up with an issue.

And thanks for creating this tool. It's already save me a lot of time trying to figure out palette sharing between tiles and condensing everything down in the tileset.

grunt-lucas commented 4 months ago

@SPMoo66 I'm so glad it's helping you! Thanks for being an active user and providing feedback. It very much helps me when making improvements :)