In the last video about MissingNo., I left
off with a note mentioning how I would like to fix the sprites for all of the glitch Pokémon. In this video, I will do just that, to the
best of my ability. Afterword, I'll show off a whole bunch of
theoretical glitch Pokémon that don't and can't exist in the original game, but could
be observed with some small hacks. Let's get into it. So in order to fix these glitched Pokémon
sprites, we first have to identify what is wrong with them in the first place. It turns out there can be multiple interpretations
of how these sprites can be fixed, so I'll run through a few. Remember, a Pokémon's sprite is defined by
a pointer to some compressed graphics data, and the size of a bounding box around the
non-whitespace part of the graphic. And remember that the dimensions of this bounding
box are defined in two separate locations (which are supposed to be identical) but can
be different in the case of glitch Pokémon. The first error is that the pointer to the
graphics data isn't actually pointing to graphics data, but to some unrelated location in the
game's ROM. Unfortunately there aren't any secret hidden
graphics of unused Pokémon in the ROM, so these pointers really have no where to point
to. These pointers are kind of what define the
character of each glitch Pokémon. Some of them look like TV static, some are
really stripey, and so on. I don't really want to mess with this, so
we'll let this pointer stay the way it is for each glitch Pokémon. The second error is that the size of the bounding
box is applied incorrectly when the width or height is zero or exceeds seven. In the case of the dimensions that help the
graphics data decompress in the first place, if the resulting bounding box encloses more
than 49 total tiles, some of them are overwritten because the memory buffer that holds this
data was only made large enough to hold this many tiles. In order to fix this, I will expand these
buffers to be large enough to hold even the largest bounding boxes. At the decompression step, a width or height
of zero is interpretted as a width or height of 256 pixels, so I will even support this
humorously large sprite if it comes up. In the case of the dimensions that help place
blank tiles around the sprite, if the width or height was zero or greater than seven,
the algorithm would fail and a broken stairstep-shaped sprite would be created instead. In order to fix this, I will use a different
algorithm that creates the correct rectangle shape no matter how large the bounding box
is. Again, a height of zero is interpretted as
256 pixels, but a width of zero in this step actually results in a sprite with a width
of 256 tiles, or 2048 pixels. There's never actually enough graphics data
to fill in this huge area, but I'll use this size anyway. The third error is that the two dimensions
of the bounding box can be different in the two different steps just previously mentioned. Fixing this issue is more subjective than
the other two. I could always pick the larger of the two
bounding boxes, but this can create a sprite with a bunch of empty space in it if the amount
of decompressed graphics is small. And I could always pick the smaller of the
two bounding boxes, but this can leave out parts of a sprite if the amount of decompressed
graphics is large. So I think I'll just show both options, and
let you decide which one looks better! I'm not going to walk through each and every
glitch Pokémon, but I will talk about a few of the interesting ones. First off, MissingNo. of course. When decompressing its graphics, the size
of MissingNo.'s sprite is defined to be 13x13 tiles. But since the original buffers only hold 7x7
sprites, or 49 tiles, some of the first buffer's data gets overwritten by the second buffer. First let's expand these buffers so all 169
tiles exist and don't get overwritten. This will end up changing MissingNo.'s appearance
quite a bit. Then, I'm actually going to switch the order
of operations here and zipper the two bitplanes together right now to form a 4-color image,
instead of doing it at the end. Since this is all theoretical work, we aren't
limited to the game's memory or anything, so we can afford to use memory space less
efficiently. Besides, I think doing it this was makes more
sense visually. Okay, so these are the 169 8x8 tiles that
make up MissingNo. Just for reference, here is what the original
MissingNo. looks like, and all of the theoretical tiles
it could have used. These highlighted tiles are the ones that
actually show up in the sprite in-game. You can see that it doesn't use every single
tile available--most of them never get used, and some of them get overwritten with each
other when the sprite gets crammed into the 7x7 tile box. But I'm going to go ahead and 'fix' this sprite
by making it actually 13x13 tiles, which looks like this. This sprite uses all of the available graphics
data exactly once, so I would consider this to be the purest form of MissingNo.'s visual
form. And then for good measure, this is what MissingNo.
would look like if it were 8x8 tiles, which is the size of its original bounding box. Both of these sprites can be considered correct
though, since most glitch Pokémon have two defined dimensions. Here's one of my favorite sprites, glitch
Pokémon with Pokédex number 234, those with IDs 194, 200, 211, 217, and 234. This is what this one looks like in the original
game. But here is what it would look like if it
could take up its full size of 6x10 tiles. It's bounding box is only 6x1 though, so if
you apply the bounding box to the sprite, you only see this little sliver of it. Again, the sprite looks a little different,
and this is because the two halves of the sprite never clash with one another during
the decompression process. If you want to learn more about that, there
will be another follow up video released soon after this one that will go into much more
detail on this algorithm. Let's look at one more in depth. This is the glitch Pokémon with Pokédex
number 255, which has the internal ID of 245. In the previous video, I showed this Pokémon
looking like this instead. This Pokémon has a bounding box of size 0x0,
and its graphical dimension is 5x0. In the original game, trying to display the
front sprite of this Pokémon crashes the game, so in order to get this image, I disabled
part of the algorithm so it wouldn't crash. But in doing this, it made the final result
not as accurate. Simulating the same algorithm with the same
buffer size but with an expanded overall memory size generates this sprite on the left instead,
since, again, the two halves of the sprite clash with each other, and one completely
erases the other. That's why this sprite only has two colors
instead of four, since one of the bitplanes became completely empty. Now, let's look at what this sprite would
look like without any memory buffer overlapping. The graphical dimesion of this glitch Pokémon
is 5x0 tiles, but like mentioned before, a width of zero is treated as a width of 256
pixels, or 32 tiles. So the pure form of Pokémon #255 looks like
this. And if you want to apply the bounding box--this
is where it gets real fun. The bounding box is defined to be 0x0 tiles,
but this is actually treated as 256 tiles by 256 pixels, or 32x256. This massive area gets filled with the same
tiles as before in column order like usual. Of course, only 5 columns get filled before
we run out of graphics, but technically this is the entire sprite. I'll let the rest of the glitch Pokémon scroll
by on your screen right now so you can take a look at them all. I'm not showing the non-glitch Pokémon since
they only have one pure, intended form. Nothing ever malfunctions in the sprite drawing
algorithm, so there's nothing really of interest there. Just like before, any highlighted in red are
sprites with graphics data pulled from anywhere but ROM, so these have the potential to look
different each time they are loaded. In fact, since the dimension byte used for
decompression is bundled with the sprite data, it also has the ability to be different each
time the sprite is loaded, which means the true size of the sprite isn't the same every
time. I've hilighted these dimension values in red
as well. For generating the sprites in this list, I
used a snapshot of memory from a point in the game when you are checking a Pokémon's
stats in its status screen, and the decompression buffer and Hall of Fame data is completely
empty. Many of these glitch Pokémon share the same
Pokédex number, so they will end up sharing the same sprite graphics. They will end up sharing the same sprite dimensions
for decompression, but not necessarily the same for the blank area around the sprite,
which means the same tiles could be arranged in a different order. Now, what if I told you there are even more
glitch Pokémon than these? You can't really encounter them in the game
without super intensive glitches or abritrary code execution, but they had to potential
to show up by chance, just like all of these sprites here. A Pokémon's ID is a single byte, which can
range from 0 to 255. Normally this ranges from 1 to 190--anything
higher than 190 belongs to glitch Pokémon. Zero also wasn't normally used, as well as
various other IDs within this range that belong to MissingNo.. But each Pokémon also has their Pokédex
number, which is also a single byte ranging from 0 to 255. The intended range for these values was 1
to 151, but some glitch Pokémon use zero or go above 151. However, some Pokédex numbers outside of
the range are just never used. For example, Pokédex number 152 is never
used, not even by any glitch Pokémon. But, we can hack in Pokémon that has this
Pokédex number and see what it looks like. This glitch Pokémon doesn't have an ID number,
so it doesn't even have a name. But, since it has a Pokédex number, it has
everything that is determined by a Pokémon's dex number. This includes things like base stats, types,
catch rate, initial moveset, and front and back sprites. Here is a list of all the glitch Pokémon
you'd get if you could set the Pokédex number to anything you want. There's nothing particularly interesting out
here, but it is cool to know that the glitch Pokémon that exist in the game are just a
small sample of the out of bounds entries of this table. There is a link in the description to a zip
file that contains all of the sprites you see here, as well as the ones earlier in the
video, if you want to see them all at once. Unlike the group of glitch Pokémon showed
earlier, these are almost all unique, since it is very unlikely, though not impossible,
for the pointer to the sprite's graphics data to be a repeat of another. All of these glitch Pokémon have unique Pokédex
numbers afterall. You can really tell especially with the much
larger sprites that long horizontal stripes, and scratchy vertical strips seems to be a
theme here. Again, this is just due to how exactly the
sprite data is decompressed and decoded, which I will go more in depth about in the next
video. That's all from me for this video though,
please enjoy the rest of the hidden glitch Pokémon scroll down your screen for the rest
of the video. Thanks for watching!
