Methodology

Return to the Matoran Adventures homepage

What we mean by "partial source"

The closest thing I've found to a pattern in what files are missing from the source dump is that they'd all be pretty large in filesize. So, for example, we have the sprite data for smaller enemies, but not for many of the larger ones. The most unfortunate victim is main.c, which contained the bulk of the program text in the game. On the bright side, we have c header files for all the source files we're missing, which can give us some insight into what they might have contained.

A crash course in GBA graphics

In a nutshell, graphics can be separated into two categories: backgrounds and sprites. Both are made up of tiles 8 pixels wide by 8 pixels tall. For sprites, these tiles are arranged into a rectangular shape one after another in the order they're defined, going left to right, top to bottom. Sprites' colors are determined by a separately defined 16-color palette. For background graphics, the tiles are arranged according to a map, and colors are determined by a separately defined (16 or 256 color) palette.

In other words, to reconstruct a sprite, you need three components: a tile set, information about the shape of the bounding rectangle, and a color palette. To reconstruct a background image, you need a different three components: a tile set, a map, and a color palette.

Ripping data from source files

Luckily, most source files were converted from one image and contain everything needed to reassemble it. For example, muakabreath.c contains MuakaBreathSizeShape, MuakaBreathSprite, and MuakaBreathPalette. So long as you know how to put the three together, you can be reasonably certain that you've recreated the original file. For the most part, you can automate putting the pieces together, too: the short name (in this case "MuakaBreath") is consistent for the same image, and the suffixes ("SizeShape", "Sprite", "Palette") mean the same thing across files.

Ripping data from the ROM

The ROM file (or "binary file" or "executable", I'm probably going to be inconsistent) doesn't have a directory structure, file names, or really any indication where data begins or ends. This makes it tricky to locate and rip an image from the ROM if we don't already have its c source file. Thankfully, the source files we do have can help! Here's how:

• The source dump contains a Makefile, a Makedepend, and a working build of the game, simple.bin. Going off of their dates last modified, it seems fair to assume that the three are related (that is, simple.bin was built by following the steps in the Makefile).
• The Makefile gives us an ordered list of the c files included in simple.bin. By inspection, the data from these source files seems to be in the same order in the binary.
• All of the files generated by converting an image (sprites, backgrounds, levels, collision data, etc.) are listed one after the other in the Makefile. This is very convenient, because it means we don't have to worry about every constant defined in some function somewhere.
• The header files associated with converted images are also automatically generated, and can be trusted (with a handful of exceptions) to declare all the data in "their" c file in order and give the size of each constant.

Put together, we know the exact size and order of all the image data we're looking for. The last step is to find where the first file's data is in simple.bin, which is easy enough to do manually with a hex editor, and you have enough to map out the location of everything else! From there, assembling component data into images is basically the same process as for source files.

All of the image data in simple.bin is exactly the same in the final ROM, with one exception. All of the data for images in both the source and the ROM is also the same.

Naming conventions

On this site, files are arranged by source name, then by short name (as defined above). If the short name is the same as the source name, it may be omitted. Files that have been ripped from the ROM have asterisks after their names, both to mark them and to indicate there's an outside chance the name's wrong. (I feel confident in my method, but that doesn't mean I'm right!)