I’m Ruby。 I’m roughly 20 apples tall
ルビーです。背がりんごを20つぐらいです。

I drew my profile pic and banner. The gameplay in the banner is from dragon quest 1 for game boy that I recorded myself.


rgmechex
@rgmechex

I don't think it would come to a surprise to anyone if I told you that the original Pokemon Red and Blue games were full of glitches. But what if I told you that every single time you watch an opponent send out a Pokemon, you were witnessing a small graphical glitch? Yeah I still wouldn't be surprised either.

Gary sending out a Charizard A classic.

Okay its so incredibly minor that you aren't ever going to notice it unless you specifically look for it, but hey, it's there.

First let's look at how the growing and shrinking animation actually works.

Each of the Pokemon sprites on the screen have a dedicated 7x7 tile area, using up 49 tiles total, even if they don't fill the entire area. There are two Pokemon (or trainer sprites--really anything that shows up on the battle screens in these spots), so 7 times 7 tiles times 2 sprites equals 98 tiles total. So tile numbers $00 through $61 are used by the two sprites.

Tilemap of the two sprites, showing that the opponent Pokemon uses tiles $00 through $30 and the player's Pokemon uses tiles $31 through $61 If a Pokemon is small, a lot of these tiles will be blank, but they are technically different tiles. Tile $7F is the blank tile, and it's not present here.

The growing and shrinking animations do not have any special tiles or graphics. They are just smooshed versions of these sets of tiles. Sure, the resulting sprites don't look very good at all, but think of them more like a smear frame--you're never supposed to see them in a still frame anyway.

Gary sending out a Venusaur, and me sending out a Blastoise named Squirtle Yes I hacked our Pokemon so that you could see the animation better.

The full sprite is 7 by 7 tiles, and the animation is 4 frames long. The full 7x7 sprite, a 5x5 version, a 3x3 version, and a single 1 tile version.

The four frames of Venusaur growing after coming out of a Pokeball Only slightly nightmare inducing.

The game just eliminates a pair of rows and columns from the sprite to create the 5x5 and 3x3 versions of it. For the single tile 1x1 version though, it looks a bit off, don't you think? While the 5x5 and 3x3 sprites use the already existing tiles, this single tile doesn't come from the Pokemon sprite. It looks a lot blockier...

In fact, it looks just like the Pokemon's back sprites, which all use 2x2 pixel blocks (so each 8x8 tile only has 4x4 pixel blocks). But where is this tile coming from?

Well this sprite I'm showing is a front sprite--coming from your opponent's side of the screen (the top right area). That single tile is indeed coming from your own front sprite. If this is the start of a battle and your trainer sprite is still visible, then this is a tile from that sprite. If you have a Pokemon out already, it's coming from that instead.

The reason for this is because that one tile from the 1x1 sprite is hardcoded and doesn't use the same algorithm as the other smooshed sprites. And it seems the developers forgot to update it at some point from a different algorithm or tile organization they were using.

Here is the tilemap for each of the frames of each of the animations:

Tilemap of each of the animations of the two sprites; tiles $4D and $4E are highlighted Yes, your Pokemon shifts to the right a bit when you call it back. The offset to draw these sprites is just off by one for some reason.

That single tile is either tile $4D or $4E, and it comes from the top right of the player's Pokemon/trainer back sprite. This tile is used for both the player and your opponent. Blink and you'll miss it, but there is a small graphical glitch every time a Pokemon is sent out or returned. (Except for when your opponent recalls their Pokemon--it just exits stage left like any trainer??)

Now what causes this tile to be $4D versus $4E? Well, first the value starts at $4C. If you look at the tilemap, you'll notice that tile $4C is the bottom center tile of the player's Pokemon sprite, so I think that is what they were ultimately going for. Though there is absolutely no check on whether this is the player's or opponents Pokemon. During the animation algorithm, the game checks if you are in a battle. It does this by checking a byte that is -1 if you are in a battle but have lost, 1 if you are in a wild Pokemon battle, 2 if you are in a trainer battle, and 0 otherwise. (Why this is checked I am not sure, the animation code only runs during a battle anyway.) This value is added to the base $4C. This means the tile is different depending on what kind of battle you are in.

A trainer battle and a wild Pokemon battle, showing different 1x1 sprites for my Nidoking Trainer battle on the top, wild Pokemon battle on the bottom. Yes Squirtle is a Nidoking now.

You'll also notice that the last frame of calling back a Pokemon is completely blank. This is interesting, because in the code, the base value $4C is loaded directly into the tilemap buffer (without the addition of the battle mode), but it immediately gets overwritten as the entire sprite area is cleared (effectively removing this frame altogether).

; $0F:4D2A - Draw 3x3 sprite
LD A, 5        ;\
CALL $3E6D     ;/ Draw the 3x3 sprite
CALL $3DD7     ; Wait 3 frames
CALL $4D3A     ; Clear 7x7 area
LD A, $4C      ;\
LD ($C481), A  ;/ Draw the 1x1 sprite
LD HL, $C405   ;\
LD BC, $0707   ;|
JP $18C4       ;/ Clear 7x7 area

You can find this code in the Gen 1 Pokemon disassembly here. The code for sending out Pokemon can be found here!

As you can see, there is a function to "wait 3 frames" but it is only called between the 7x7 and 5x5 and 3x3 sprites, and not between the 3x3 and 1x1 sprite.


You can support Retro Game Mechanics Explained on Patreon here! Any and all support is greatly appreciated!


You must log in to comment.