e353f3bb96
* Document object_rd + use it in rd and railgibud * Move limb enum to rd.h, share it across all redead actors * Copy over head/body rotation and effect documentation from Talk_Gibud to the other two * Minor spacing things in Talk_Gibud * Import tons of symbols from Talk_Gibud into Railgibud * Always set actionFunc last in Setup functions * Document the isInvincible struct var (thanks kz) * More railgibud struct documentation * Cutscene-related struct names * Damage effect enum for Railgibud * Damage effect enum for Rd * Use the UpdateDamage name that everyone else uses * Grab/Type enums in Railgibud * Document EnRailgibud_MoveGrabbedPlayerAwayFromWall * Document EnRailgibud_PlayerInRangeWithCorrectState * Document EnRailgibud_PlayerOutOfRange * Document path stuff in Railgibud * More Railgibud junk * Enum for animations * Minor documentation on effect stuff * Document Railgibud sink into ground * Document most of Railgibud that was left * Clarify one function name * Use player2, since I guess func_800B8E58 takes Player* now * Make Talk_Gibud/Railgibud consistent with each other in style * Name a few Rd functions * Name some dancing functions * Make define for is Redead * Define for if the Redead is frozen * Make most params access use TYPE * Document some Rd types * Document grab fail functions * Port a few more names from other Gibdo actors * More Rd documentation * Document alpha * Document walk to home functions * Document deathTimer in Rd * Some more timers documented * Document damageEffect struct var * Name all functions in Rd * Document unk_3E4 * Document grab stuff * Document mourning state * Document action states * Name all remaining variables * Document remaining EnRdType * Document all types of Redead * Use ACTOR_FLAGs * Verbose player stateflags * CheckCollision -> UpdateCollision * Try to explain what makes Rd different from the others better * Last changes before PR * Move the limb enum to the object * Remove unnecessary includes from the .c files * Format after sync |
||
|---|---|---|
| .github | ||
| assets | ||
| docs | ||
| include | ||
| src | ||
| tools | ||
| .clang-format | ||
| .clang-tidy | ||
| .gitattributes | ||
| .gitignore | ||
| CONTRIBUTING.md | ||
| Jenkinsfile | ||
| Makefile | ||
| README.md | ||
| REVIEWING.md | ||
| checksum.md5 | ||
| checksum_uncompressed.md5 | ||
| diff.py | ||
| diff_settings.py | ||
| extract_assets.py | ||
| first_diff.py | ||
| fixle.sh | ||
| format.sh | ||
| requirements.txt | ||
| spec | ||
| sym_info.py | ||
| undefined_syms.txt | ||
README.md
Legend of Zelda: Majora's Mask (US) 1.0
- WARNING! -
The ROM this repository builds while has a matching checksum cannot be 'shifted' due
to hardcoded pointers which have yet to be dumped. Thus this repository is currently
in an experimental and research phase and cannot currently be used traditionally as a
source code base for general changes.
This is a WIP decompilation of The Legend of Zelda: Majora's Mask. The purpose of the project is to recreate a source code base for the game from scratch, using information found inside the game along with static and/or dynamic analysis. It is not producing a PC port. For more information you can get in touch with the team on our Discord server.
The only build currently supported is N64 US, but other versions are planned to be supported.
It currently builds the following ROM:
- mm.us.rev1.rom.z64
md5: 2a0a8acb61538235bc1094d297fb6556
This repo does not include any assets or assembly code necessary for compiling the ROM. A prior copy of the game is required to extract the required assets.
Please refer to the following for more information:
Installation
Windows
For Windows 10, install WSL and a distribution by following this Windows Subsystem for Linux Installation Guide. We recommend using Debian or Ubuntu 20.04 Linux distributions.
MacOS
Preparation is covered in a separate document.
Linux (Native or under WSL / VM)
1. Install build dependencies
The build process has the following package requirements:
- make
- git
- build-essential
- binutils-mips-linux-gnu
- python3
- pip3
- libpng-dev
Under Debian / Ubuntu (which we recommend using), you can install them with the following commands:
sudo apt update
sudo apt install make git build-essential binutils-mips-linux-gnu python3 python3-pip libpng-dev
To install the Python dependencies simply run in a terminal:
python3 -m pip install -r requirements.txt
2. Fork the repository
Create your own fork of the repository at https://github.com/zeldaret/mm. Then clone your fork where you wish to have the project, with the command:
git clone https://github.com/<YOUR_USERNAME>/mm.git
3. Prepare a base ROM
Copy your ROM to inside the root of this new project directory, and rename the file of the baserom to reflect the version of ROM you are using. ex: baserom.mm.us.rev1.z64
4. Make and Build the ROM
To start the extraction/build process, run the following command:
make init
This will extract all the individual files in the ROM into a newly created baserom folder, as well as decompress the compressed files in a newly created decomp folder. This will create the build folders as well as a new folder with the ASM as well as containing the disassemblies of nearly all the files containing code.
This make target will also build the ROM. If all goes well, a new ROM called "mm.us.rev1.rom.z64" should be built and the following text should be printed:
mm.us.rev1.rom.z64: OK
If you instead see the following:
mm.us.rev1.rom.z64: FAILED
md5sum: WARNING: 1 computed checksum did NOT match
This means that something is wrong with the ROM's contents. Either the baserom files are incorrect due to a bad ROM, or some of the code is not matching.
Running make init will also make the ./expected directory and copy all of the files there, which will be useful when running the diff script. The diff script is useful in decompiling functions and can be ran with this command: ./tools/asm-differ/diff.py -wmo3 <insert_function_here>
Note: to speed up the build, you can pass -jN to make setup and make, where N is the number of threads to use in the build, e.g. make -j4. The generally-accepted wisdom is to use the number of virtual cores your computer has, which is the output of nproc (which should be installed as part of coreutils).
The disadvantage that the ordering of the terminal output is scrambled, so for debugging it is best to stick to one thread (i.e. not pass -jN).
(-j also exists, which uses unlimited jobs, but is generally slower.)
Contributing
All contributions are welcome. This is a group effort, and even small contributions can make a difference. Some tasks also don't require much knowledge to get started.
Please note that is is our strict policy that Anyone who wishes to contribute to the OOT or MM projects must not have accessed leaked source code at any point in time for Nintendo 64 SDK, iQue player SDK, libultra, Ocarina of Time, Majora's Mask, Animal Crossing/Animal Forest, or any other game that shares the same game engine or significant portions of code to a Zelda 64 game or any other console similar to the Nintendo 64.
Most discussions happen on our Discord Server, where you are welcome to ask if you need help getting started, or if you have any questions regarding this project and other decompilation projects.
For more information on getting started, see our Contributing Guide and our Code Review Guidelines to see what code quality guidelines we follow.
FAQ
Q: Why does MM use transient assembly?
A: It is the view of the MM project leads that transient asm is safer than storing the disassembly in the repo. We feel like the C code is more transformative than a straight disassembly.