"None of this is easy", or
"Why anything 'interesting' takes time"

Revision History

Revision 2 — 2021/04/01 (April 1, 2021)

Slightly expanded examples of what SRAM stores. Toned down the SM64/Zelda section slightly. WldFb confirmed to still be alive. Expanded Expansion Pak answer.

Revision 1 — 2020/06/03 (June 3, 2020)

Added "Items in Detail" section, which explains what is required for various things being requested.

Introduction

Since the release of the various preview editions of VPW2 freem Edition, there have been many questions posed to me with regards to features and additions.

I tend to answer a decent chunk of these questions with "it requires a decompilation of the game", but people might not know what that actually entails, or why it's even necessary in the first place.

This article primarily focuses on the Nintendo 64, and specifically, the work I've been doing for VPW2 freem Edition. As this article is written for a non-technical audience, I will be glossing over a lot of details in an attempt to not confuse the reader.

What is a Disassembly/Decompilation?

The short version: having a disassembly lets you make changes to the game without needing to use a hex editor or other tools.

Disassembling a game involves multiple steps.

1. Figure out what parts of the ROM are code and data, and split them out.
2. Convert the code from binary/hex to MIPS assembly, so it can be rebuilt using an assembler.
3. Find any hardcoded memory address locations and replace them with labels, to make changing code and data easier.
4. Once the previous steps are done, attempt to convert the assembly code to matching C code. This step is optional, but highly recommended if you don't want to spend the rest of your days writing MIPS assembly.

The terms "disassembly", "decompilation", and "decomp" will be used interchangeably in this article.

Game Code

Contrary to what you might believe, game code is typically not executed directly from the cartridge on the N64. Code is copied from ROM to RAM and runs there.

Virtual Pro-Wrestling 2 is split into five distinct parts:

1. Shared code/data (loaded at all times)
2. Menu code part 1
3. Game introduction, ending, and cutscenes (including wrestler introductions)
4. Menu code part 2 (including RRS mode)
5. The actual gameplay code

The amount of RAM available on the N64 means that the last 4 sections are loaded into memory as needed, overwriting what's already there.

Game Data

Most of the game data is found in two locations: the game code sections, and an internal file table (where some, but not all, of the interesting stuff is).

Filetable items are typically referenced by file ID, which makes changing that data relatively simple. All that needs to be done is to replace the data in the filetable. However, the filetable does not include data such as default wrestler information, the default stables, RRS teams, arena items, etc.

A large chunk of game data is referenced via something called "pointers", which store the address of the data instead of the data itself. When the game is built, the data locations are hard-coded into the ROM.

Adding anything to the game code (or non-filetable game data) means rewriting these pointers so that they continue to make sense despite the extra data you've added. This is why I've mainly stuck to replacing existing data; I don't want to manually rewrite every single pointer.

Save Data

The save data (hereafter referred to as "SRAM") is where a few other items are located. This includes profile and costume data of default wrestlers (but NOT moveset, parameter, and logic data), all data for edit wrestlers, saved championship belt information, Royal/King's Road Succession progress, Event/PPV Mode data, Ranking Mode data, saved League and Tournament data, and some other stuff.

The game is not set up to read moves, parameters, and logic for default wrestlers from SRAM, and it would require lots of code editing to make it work. Again, something that requires a disassembly of the game.

Now that you (hopefully) have some sort of idea of what's going on, there are some statements that I'm expecting to hear from others. Let's go through them.

"But Super Mario 64 and the Zelda games got decompiled relatively fast!"

There are a few reasons that Mario and Zelda got this far in a short amount of time:

1. They're first party games, which gives them extra attention and interest.
2. Zelda had many debug ROMs leak. These debug ROMs include program symbols, making it a lot easier to piece things together.
3. Super Mario 64 was built without -O flags (optimization), making decomp easier to deal with.

Meanwhile, the number of people in the VPW/AKI hacking community currently capable of dealing with ASM is countable on one hand. These people are:

• S.K. Stylez
• randymanfoo/RetroRandy
• LIGHTNING/jordyad
• WldFb
• and myself (freem)

If you cull this list further to "who actually has a VPW2 decomp environment set up?" then it's just me (for now, anyways). Having the environment available also doesn't guarantee the above people (other than myself) will actually work on the VPW2 decomp, as they've all got their own projects.

"You should just use GameShark codes like everyone else."

Anyone who says this is 99.999999% likely to have never actually used an N64 GameShark on the original console. These people are also likely to only use emulators, and not give a damn about original console compatibility.

There are a number of issues with using GameShark codes:

1. The GameShark hardware is notorious for causing game freezes. This especially pops up when you're trying to use the GS button for anything. This is something that people only learn when they have the actual hardware.
2. In order to use the GameShark with the 64drive, you need to load the ROM (and save data) via USB. Most people are not equipped to handle this, nor do they want to go through the process. (and I don't blame them.)
3. The Everdrive64 menu supports GameShark codes, but only 24 of them. That's not nearly enough space for any non-trivial hack.
4. Even if you do go the emulator-only route, Project64 has limitations on GameShark code count. I have no idea about other emulators, because I only care about emulators that include debuggers, and every N64 emulator not named "Nemu", "Project64 v2.x", or "MAME" doesn't have them.

"You should use the Expansion Pak memory."

Some AKI projects do this, but I prefer to not require the Expansion Pak for any projects I make. Furthermore, the AKI projects that DO use the Expansion Pak memory space currently don't use the proper setup function, meaning they always assume the Expansion Pak is there. Again, they're typically optimizing for emulator-only play. I'm optimizing for playing the game on the original hardware.

This is not a condemnation of the method; it's mainly my preference to do things cleanly. If I were to use the Expansion Pak memory, I would prefer to have it be optional, instead of required.

"But WWF No Mercy does [x]!"

Yes, and AKI spent a lot of time between VPW2 and No Mercy changing a large portion of the codebase, so most things aren't immediately compatible between the two games.

"You should just hack No Mercy instead."

Then I would have to do even MORE work restoring the removed combo system code, the shootfighting system code, the mask system...

No. Just no. Let me hack the game I actually care about in peace.

p.s. Remember how I said VPW2 has 5 code sections? No Mercy has 6, which means any No Mercy decomp project will take EVEN LONGER than VPW2 has already.

p.p.s. I don't want to start a No Mercy decomp, because then people will only work on that and I'll be left holding the bag for VPW2.

Why can't you just add things to the game?

It's complicated, and depends on each item. See below for more information.

Items in Detail

I get asked to add things quite often, as if it was really simple to do. This is NOT the case. This section attempts to explain why that is for each possible component.

There are a lot of hardcoded file IDs, and adding anything after the last filetable entry requires updating multiple parts of the game code. Furthermore, you have to be able to select the item(s) in Edit Mode, which ALSO requires editing game code. Certain items are defined only by a single filetable ID, and the game expects all of the relevant entries to be sequentially placed after that file ID.

Wrestlers

Wrestler data is split into multiple parts.

• Main Wrestler Definition — This exists in ROM, and requires editing pointers of EVERYTHING just to add a wrestler.
• Moveset and Parameters — These exist in the filetable.
• Default Costume Data — Also exists in the filetable.
• Name Data — Also exists in the filetable.

Hair

Multiple times now, I've been asked to add new hairstyles. This is not as easy as you think.

• Models — Found in the filetable. Not 100% sure, but you may need to provide multiple models to deal with the different head options.
• Textures — Found in the filetable.
• Edit Mode Menu Entries — Not 100% sure about where these are defined for hair.
• Item Name — Found in the filetable.

Costume Items

Costume items are similar to hair items:

• Models — Found in the filetable. You need to provide six models to account for every Body Size selectable in Edit Mode. Adding items requires changing pointers.
• Textures — Found in the filetable, also defined in ROM. Adding items requires changing pointers.
• Edit Mode Menu Entries — I don't think I've found these out yet for costume items, just the data and main pointer lists.
• Item Name — Found in the filetable.

Moves

The primary issue with moves is that the game expects animations to start at certain file IDs, so I can't just throw move data elsewhere in the filetable.

• Animations — These exist in the filetable.
• Damage Data — Also found in the filetable.
• "Toki 1" Data — Also found in the filetable. This data includes sounds, rumble pak output, hand gestures, and more.
• Edit Mode Menu Entries — There are lists of what moves belong in each section of the moveset. These would need to be updated, and requires editing various pointers.
• Move Name — Found in the filetable.
• Reversal Data — Found in the filetable. Not sure of the actual data format at the moment; I've only identified them in 2020.

Arenas

Arena data is VERY pointer-dependent. I would have to rewrite the pointers of everything that appears after it.

• Models — Found in the filetable.
• Textures — Found in the filetable.
• Arena Data — Found in the ROM; very pointer-dependent.
• Guardrail Data — Found in the ROM; pointer-dependent.

Belts

• Models — Found in the filetable. Not too many of them, either.
• Textures — Found in the filetable. Two textures are required for each belt: the menu texture, and the texture used for the belt model.
• Belt Entries — Found in the ROM; requires pointer updates to add new belts.
• Belt Style — Also found in the ROM. These define how the double and triple titles show up. They won't need to be edited for any design that only uses one belt.

In short, if adding something requires me to edit pointers or hardcoded filetable IDs, I can't easily do it without a full decompilation of the game.