Part 8: A Day-Long Detour
Sometimes when you’re developing something, you get completely sidetracked on something else that you never expected. While I was working on upgrading the transfer process to be a whole box of Pokémon (more on that later), I became very aware that it was quite hard to tell what Pokémon were being sent through the system. In all of the methods created by GameFreak, the Pokémon being transferred are shown to the user before anything is actually sent. This is especially important when the Pokémon are being removed from the original game, and cannot be sent back. Clearly, I needed to implement something to do the same.
Originally I looked into adding all of the PC sprites from generation 3. Each sprite is 32x32 pixels, has two frames of animation, and all 251 Pokémon collectively share three pallet spaces. However, after crunching the numbers, I found that the sprites would take up far too much space.
Some of the sprites!
Clearly, that was not going to work. I decided to look backwards a generation instead. Generation one and two didn’t have visual PC interfaces, instead opting for a list of Pokémon names. They did have sprites in the menus though! 11 different sprites were featured in Generation 1, and it was increased to 39 in Generation 2. These sprites also had two frames of animation, but were 16x16 and only consisted of four colors. These sprites would take up a fraction of the size, especially since multiple Pokémon were represented by each sprite.
Since each sprite is so small, I decided to go ahead and implement the animation as well. This… is where things got complicated. Not really for a good reason, but one of those “I want to see if I can pull it off” reasons.
The Game Boy Advance pallet has spots for 16 different colors. Each one of these can be set independently from another, and pallets can be modified on the fly. Since I was working with two frames of animation and four colors, that meant that I had 16 different total combinations for what two colors each pixel would be in both frames of animation. I decided that I wanted to store only one of each sprite, and have the animation be set by changing the pallet alone. I knew I could do this by hand, but I used this as an excuse to mess around in Python instead.
This is what I came up with. The Python Imaging Library makes it super simple to modify and create photos, especially when you’re dealing with a low pixel count. Ultimately, I ended up determining what each pixel color was in each frame and performing bitwise operations on them. This kept things simple and clean when it came to adding in my pallet. I ended up exporting the new image with a pallet of four shades of black, red, green, and blue- just to have a visual:
It’s a bit hard to look at, but on a few of them you can make out the two different sprite states. Ultimately, this ended up working perfectly for my sprites, as I could animate them with a single line of code, instead of changing each sprite individually!
It’s parts of the process like this that remind me why I love working on projects. You never quite know what rabbit holes you’ll go down to get things working!
The final result!