GuestLog in

This is a combination review and third party instruction manual for the alpha version of the tool "Final Fight 3 SNES Decompressor" made by Proton.

As a shameless Final Fight fanatic I was completely thrilled to see that someone had written a tool specifically for this game. This tool facilitates a single function for a single game, that is, it decompresses graphics data for the USA version of Final Fight 3. For the most part, it does what it advertises, but the functionality is a bit rough around the edges. Also, the lack of any documentation might deter less experienced users from achieving anything with it.

This tool runs from the command line. Some would view this as a negative point, but really the tool is so straightforward in function that it doesn't even need a GUI. The only difficult part is finding correct offsets to use. Thankfully, if you run the program without any parameters, it gives you some very brief instruction text on how it is meant to be used. The tool must be used in conjuction with a headerless Final Fight 3 (U) ROM. You must define your input file (the ROM) followed by the desired name of the output file, and lastly you must define the address of the compressed data you want to decompress. The tool offers a sample address, $2DBA32. If you follow the example, you should wind up with a binary file that contains the decompressed tile data for the game's font, both 8x8 and 16x16 versions. That's all well and good, but no guidance is given as to how to track down other relevant addresses. The tool seems to crash if you feed it an invalid offset, so you need to do some legwork to find ones that produce anything useable.

Here's how you can find relevant offsets for decompressing. Whenever the game begins decompressing tile data, the code at $E82A is executed. This is a LDA,y that points to a low-endian address stored in RAM at $1E04. The Y register usually contains #01. So to get your final offset, take the lo-endian 3 byte address from $1E04, add 1 to the least significant byte, and change the most significant byte so that it refers to an address in the ROM file itself, rather than within the CPU's vision. For example, when the game decompresses the font for the cutscene text (different from the normal in-game font), $1E04 will contain #2A 3A EF. This refers to the address EF3A2A, plus the 1 stored in Y to make it EF3A2B, which in the ROM file itself is actually 2F3A2B. Tell the decompiler the offset 0x2F3A2B and it will spit out a binary file of the cutscene font. So, set a breakpoint to $E82A and you will find relevant addresses in no time. Of course if you are using Geiger's SNES9x Debugger, the status window will show you the final address right then and there. Sometimes the game will decompress data that doesn't seem to be tiles. I haven't tested this but I suspect that this data might be VRAM tile attribute data. Who knows?

In the end, not every offset that I was able to find works 100%. The Capcom logo and a lot of the graphics for the intro cutscene do not decompress properly. However, the two sets of fonts decompress fine, and so do the tiles that make the map of Metro City in the intro. Who knows, maybe your mileage will vary. Either way, I hope Proton continues to work on it.

PROS:

• Works some of the time
• A useful tool for a game woefully neglected by the hacking scene
• Author has also released a complimentary compression tool

CONS:

• Doesn't always work
• Bare minimum of documentation included

Known offsets:

0x2BECC2 = Capcom logo (does not decompress correctly) 0x2F3A2B = 8x16 font set for cutscene text 0x2BDB31 = Map of Metro City