Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Project516/sm64dx/llms.txt

Use this file to discover all available pages before exploring further.

If you have written a feature or fix that belongs in the enhancements/ directory, you can package it as a standalone .patch file using tools/create_patch.sh. The script captures all staged and unstaged changes relative to the current master branch in standard unified-diff format, making the result immediately usable by tools/apply_patch.sh and the POSIX patch utility.

​
Workflow

1

Switch to the master branch

Patches are always authored against master. Make sure you are on that branch before starting.
git checkout master
2

Make your changes

Edit, add, or delete source files as needed. Do not commit the changes — create_patch.sh works against the unstaged and untracked diff relative to the last commit.New files that have never been tracked by Git are included automatically: the script runs git add . internally to stage them before generating the diff, then immediately runs git reset to unstage everything, leaving your working tree exactly as it was.
3

Run create_patch.sh

Pass the desired output path as the only argument. By convention, patch files live in the enhancements/ directory.
tools/create_patch.sh enhancements/my_feature.patch
The script will:
  1. Run git add . to pick up any new untracked files.
  2. Run git diff -p --staged > enhancements/my_feature.patch to write the patch.
  3. Run git reset to unstage everything.
4

Verify the patch

Open the generated file and check that all intended hunks are present and that no unrelated changes leaked in. Then do a dry-run apply to confirm it applies cleanly:
patch -p1 --dry-run < enhancements/my_feature.patch

​
Patch format

The output is a standard unified diff (git diff -p --staged) with one level of path prefix — the same format consumed by patch -p1. Each hunk records the original and modified lines with ---/+++ headers so the patch can be applied to or reversed from any checkout of the repository.
The patch file is stored in enhancements/ alongside the existing patches. This keeps all optional features in a single, predictable location and makes it easy to share the file with other developers.

​
Code style

Run clang-format on your modified files before creating the patch. The sm64dx codebase follows a consistent C style, and a well-formatted patch is easier to review and less likely to produce conflicts when applied to other forks.
clang-format -i src/your_file.c
After formatting, regenerate the patch so the formatting changes are baked in rather than left as a separate step for the person applying the patch.

Build docs developers (and LLMs) love

Get started for freeTalk to us