Switch to building binary pic files from pngs

[entrpntr]

As of 8a924f1, there are 1058 pics committed by my count. Up to this point, I have just been adding .1bpp/.2bpp/.lz extracted from the baseroms, and only creating pngs as a bonus. I have yet to bother attempting using pngs as the source for creating these files (as well as .gbcpal/.dimensions files, for pokemon and trainers).

Eventually, we'll want to do this. Places that will need to be updated to match how things are done in pokecrystal:

• Update Makefile with all necessary targets (see here for what it currently looks like in pokecrystal; also add a tidy target and update the clean target)
• Fix any pngs that don't happen to produce correct uncompressed binary files (i.e. anything not a .lz file)
• Update data/pokemon/palettes.asm and data/trainers/palettes.asm to INCBIN .gbcpal files, rather than INCLUDE the current .pal files
• Update all the files in data/pokemon/base_stats.asm to INCBIN a front.dimensions file rather than dn two nybbles with the frontpic dimensions
• Suffix existing .lz files with their md5 hashes (to signal whether the generated .lz file matches the binary in the baserom)
• Add lzcomp.c, md5.c, palette.c, and png_dimensions.c to the tools directory to support the above changes (currently assuming pokemon_animation.c and pokemon_animation_graphics.c are only relevant to Crystal)
• Update .gitignore to ignore all .1bpp/.2bpp/.lz files, and remove any remaining redundant files from the repo

There are a few mutually exclusive parts to this, so all of these need not be done in one step.

Edit (3-Jun-2020): I had some work started on this branch for the new lzcomp, which matched every PNG that existed at the time, except for Alakazam's backsprite in Silver. Will revisit soon.

[Rangi42]

lzcomp still can't replicate Alakazam's Silver back sprite. I'd be fine with making it an exceptional file, gfx/pokemon/alakazam/back_silver.2bpp.lz.bin, leaving the back.png unused (just like how dark_cave_metatiles.bin exists but is unused since cave_metatiles.bin applies for both). Then a comment could explain the lack of matching (noting that it decompresses to exactly the same data as Gold's backsprite but with an extra $80 byte at the end). (Giving it a .bin extension to avoid special cases like not gitignoring or make cleaning that one .lz file.)

[aaaaaa123456789]

What's the output of lzcomp -d for that sprite?

[Rangi42]

[Rangi42]

• Check whether the ds $40 after the Gold title trail GFX can be part of the image (empty tiles)
• Replace gfx.py with the pokecrystal one (no hard-coded rules for charizard1, etc)

[entrpntr]

I can remove the gfx.py hardcoded rules and just keep them locally. There were some initial fixes that should probably be kept though: Python 3 compatibility, graceful handling of the 577 byte Alakazam Silver backsprite, and possibly a couple others.

There was also the 'animate' argument that I commented out (since Gold/Silver don't have the animated frontpics), but I don't remember if I ever checked to see if that was a necessary change.

[Rangi42]

gfx.py doesn't need to handle Silver's Alakazam because lzcomp doesn't either (it can't match the compression). It would be included as a raw back_silver.2bpp.lz.bin file, so back.png would only get encoded+compressed for gold.

[entrpntr]

Ah, yeah, I meant a fix in the lz -> 2bpp -> png direction (I couldn't directly create the Silver png from its lz without a change in the gfx.py code). Far from necessary to include handling for that edge case though.

That said, I guess I'm not sure how gfx.py actually gets used for pokecrystal anymore; I thought various C code replaced its main uses? I assume there's some use for hacks that I may be missing.

[Rangi42]

The build process doesn't use gfx.py; it's kept as a convenient tool for if you want to manually convert/deconvert PNGs.

[Rangi42]

Issue #47 tracks the remaining few binary gfx files.