We don't need to worry about other texture formats, since every single version of the SM64 Editor has only ever used RGBA16 textures. There are 4 0xFC commands that we need to know:įC 12 7E 24 FF FF F9 FC = Solid RGBA texture (No fog)įC 12 18 24 FF 33 FF FF = Alpha RGBA texture (No fog)įC 12 7F FF FF FF F8 38 = Solid RGBA texture (With fog)įC FF FF FF FF FC F2 38 = Alpha RGBA texture (With fog) If the wrong 0xFC command is being used, then we need to replace it with a correct one. To fix this issue, we need to go through all the Fast3D display lists of every single level and determine if the 0xFC is fine to use or not. For levels without fog, all of all the geometry will just flash between different solid colors. This one command was only meant to work with solid RGBA textures in levels that have fog. The problem with earlier versions of the SM64 Editor is that it only used a single 0xFC command for all of the display lists: FC 12 7F FF FF FF F8 38. Basically, using a wrong combine value will cause the level to not look the way you want. Like it's name suggests, the color combiner will take in inputs from many different sources and combine them into a single color that affects how the polygons in a model will look. This is the command that will configure the RDP's color combiner. In the display lists that draw the level's triangles, you might see a 0xFC command near the top. Improper use of Fast3D's SetCombine (0xFC) command Note: Banks can be used multiple times, so you will have to remember which addresses you've already adjusted. If you want to make your own tool that will implement this fix, then you can follow these steps:ġ.) Look through all of the levels scripts to find 0x17/0x18/0x1A commandsĢ.) Test if either the ROM start address or ROM end address is odd.ģa.) If both the start & end addresses are odd, then move the entire bank over by 1 byte.ģb.) If only the end address is odd, then just increment the end address by 1.ģc.) If only the start address is odd, then move the entire bank by 1 byte and also increment the end address by 1. Thankfully, some people have made tools to do this automatically like queueRAM's sm64compress tool. To fix this issue, we will have to look through the entire ROM file and adjust every 0x17/0x18/0x1A level script commands that have odd ROM address values. Segments 0x12 and 0圎 will load just fine, since the ROM address values are even. The segments 0x07, 0xB, and 0x09 will fail to load on console, since the ROM address values are odd. This means that if the start/end ROM addresses within the 0x17/0x18/0x1A commands were odd, then copying data from ROM to RAM would fail. The N64 requires a 2-byte alignment for ROM addresses, and an 8-byte alignment for RAM addresses when copying data. The problem with early extender tools, like VL-Tone's original SM64 ROM extender, is that the addresses where the decompressed data was stored was in a bad alignment. Since ROM hackers don't really need to worry about file sizes (up to 64MB), we use ROM extenders to decompress the data into another place in the ROM file and convert all of the 0x18 level commands into 0x17 commands.
The MIO0 compression was necessary to make SM64 fit within an 8MB cartridge. Level script command 0x17 is used from copying uncompressed data from the ROM into RAM, and the commands 0x18 & 0x1A are used to read compressed MIO0 data from the ROM and then decompress the data into RAM. In SM64, the game will load up scripts & models using level script commands for each level.