Our install script does not yet support distros other than Ubuntu, Arch, and their derivatives. Please consider contributing to the script if you use another distro!
#### Base ROM
You'll need a Paper Mario (USA) ROM to work on this project. Copy it into the root directory of the repository with the name `baserom.z64`.
#### Install tools and extract ROM
```sh
$ make setup
```
### Compile the game
```sh
$ make
```
If you get `OK`, you're all set! Otherwise, please feel free to reach out to us in [our Discord channel](https://discord.gg/urUm3VG).
## Contributing
### Dependencies
There are a few additional dependencies needed when contributing to this project. You can install them with `./install.sh --extra`.
### Rebuilding
Setting the `PM_HEADER_REBUILD` environment variable will cause `make` to rebuild all `.c` files whenever a `.h` file is modified.
```sh
$ PM_HEADER_REBUILD=1 make
```
If you use Visual Studio Code, you can use _Run Build Task_ (Ctrl+Shift+B) to run `make`. Any errors or warnings generated by the compiler will show up in the _Problems_ tab.
### Matching a function
#### Setup
Once you've created a successful (`OK`) build, copy `build/` to `expected/build/`:
```sh
$ mkdir -p expected
$ cp -r build expected
```
#### Roughly converting assembly to C
Decide on a function to match. These can be found in the subdirectories of `asm/nonmatchings/`. Currently, functions which use float constants, data sections, or jump tables are unmatchable.
Take the relevant `.s` file and pass it to [mips_to_c](https://github.com/matt-kempster/mips_to_c) ([web version](https://simonsoftware.se/other/mips_to_c.py)).
Then add `PATH="$PATH:/usr/local/bin/mips_to_c"` to the end of your `~/.bashrc` file.
You should be able to run `mips_to_c.py` now for any file in `asm/nonmatchings/`. Here's an example `mips_to_c.py ./asm/nonmatchings/code_13870_len_6980/func_8003B3D0.s func_8003B3D0`.
If mips_to_c gives you an error about branch-likely instructions, edit the `.s` file and rename any branch-likely instructions to their unlikely equivalent (i.e. remove the `l` suffix). Add a `nop` after the branches and move the instruction that was originally in the delay slot (directly after the branch instruction) to the start of the target label. Don't commit the edited assembly.
Open up the relevant `.c` file and replace the function's `INCLUDE_ASM` macro with the output from mips_to_c. Run the following command to attempt to compile, replacing `function_name` with the name of the function you're working with:
```sh
./diff.py -mwo function_name
```
Fix any errors and rerun `diff.py`. This will involve typing the function signature correctly, which you will probably find in [Star Rod's library database](https://github.com/nanaian/star-rod/blob/master/database/common_func_library.lib). See also [common_structs.h](include/common_structs.h).
Once a successful build is made, `diff.py` will show you the difference between the original game's assembly (on the left) and what your C code generated (on the right).
You're on your own now. Get your C code compiling to match the original assembly! `diff.py`, when running, will automatically recompile your code whenever you save the `.c` file.
If you use Visual Studio Code, you can use _Run Test Task_ to run `diff.py` and show you errors and warnings from the compiler inline. You might want to attach _Run Test Task_ to a keybinding, as you'll be using it often.
If `format.sh` has any problems with your code, go and fix the issues. If you can't fix a warning without making the function not match anymore, append `// NOLINT` to the offending line.
