Update all Gen2 sprites for better accuracy and consistency

[Delgan]

It was meant to be just a small refresh, but I fell down the rabbit hole once again...

I had noticed small problems with some Gen2 sprites: inconsistent sizes, vertical misalignment, horizontal misalignment, glitched sprites, etc. I first wanted to replace them with Bulbapedia's, but those had similar problems. Instead, I re-generated the sprites from the pokegold and pokecrystal sources using rgbds + bpp2png.

The sprites with white background are mostly unchanged (just different RGB555 -> RGB888 color conversion and sBIT PNG field removal).

The transparent sprites had different sizes, so I normalized them to 56x56, which is also the size used by Bulbapedia. Base front sprites are actually 40x40, 48x48, or 56x56, which caused the placement inconsistencies: people manually centered the smaller sprites within a 56x56 canvas, without any agreed-upon standard.

Fortunately, the original games contain an existing spacing algorithm. This image defines where 40x40 and 48x48 sprites should be placed within a 56x56 canvas.

I suggest following this convention. It is non-arbitrary, uses the game itself as the authoritative reference, and matches the vertical sprite positions in the Pokédex. Therefore, it is as faithful and "official" as normalized Gen2 sprites can be.

Since the base sprites lack transparent background, I extracted the transparency masks from the Bulbapedia sprites, verifying and correcting them when necessary.

I also found several inaccuracies in the animated sprites. For example, this Bulbapedia sprite lacks a frame, has incorrect frame durations, contains altered frames with missing pixels, and mixes colors produced by different RGB555 -> RGB888 conversions. So, I re-generated the animations using a hand-made script simulating anim.asm and anim_idle.asm from the pokecrystal sources.

I'm not sharing the script because it looks awful, but I may eventually turn it into a Python package supporting this and some other generations.

One last note regarding the white-background sprites: I think they could be removed to simplify the API. I know this was discussed before, and @Naramsim suggested keeping them because they are original: #30 (comment). I agree that this is a good reason (although technically the RGB555 -> RGB888 conversion is transformative). Still, I suspect transparent sprites are what developers actually care about. The current coverage perhaps reflects this: we lack opaque variants for Crystal animations (I can add them) and "Red & Green" entirely. Since adding a white background to a transparent sprite is trivial anyway, focusing on normalized transparent sprites might make things simpler for both users and maintainers. But I don't have a strong opinion on this; that's just my $0.02 after working on it and having shower thoughts. :)

[Naramsim]

hi! Thanks a lot for the hard work! A question, I see the sprites in the animated folder are now having the .png extension. It's because they are effectively PNGs? It's better to have them as PNG files or GIFs? Just thinking that maybe many people hardcoded the extension in their application and this would break them. But I'm fine if PNGs better reflect the images

[Delgan]

Just thinking that maybe many people hardcoded the extension in their application and this would break them.

Good point. Sorry, I forgot about that pesky real world...

It's because they are effectively PNGs? It's better to have them as PNG files or GIFs?

I saved them as PNGs simply out of habit and for consistency, but it isn't required. GIFs are limited to 256 colors per frame, but GSC sprites use a 4-colors palette anyway, so that isn't a problem. The only minor difference is timing precision: APNG can closely represent the Game Boy's 59.73 Hz, while GIF delays are limited to 10 ms increments. However, neither precisely matches the in-game rendering due to impredictible engine overhead anyway.

I reverted the concerned commits and pushed the updated GIFs (also applied gifsicle -O3 --careful).