game-patches: memory patches for the Xenia emulator

A patch collection, and not a collection of games

The repository contains game patches for Xenia Canary, and the first thing the README does is rule out the most likely misreading. These are not actual games and not Title Updates, and the README points at Xenia's Quickstart for getting games. That distinction is the whole scope of the project: the emulation stack lives in Xenia itself, and this repository is the community's collection of configuration files that adjust a game while it runs.

The mechanics are worth stating plainly, because they determine the risk. A patch is a TOML file describing memory writes, and the emulator applies it to the game's address space. That means a patch is not a save file, a cheat code or a texture pack, it is a set of writes to fixed addresses in a specific build of a specific game. The README says as much in the strongest terms, warning that you should not change the hash unless you know what you are doing, and that you should expect crashes or the patch not working if you do.

The repository is small in structure. The top level holds a .gitattributes, a .github directory, a .gitignore, a data directory, an eslint.config.js, a package.json, and the patches directory itself. There is a Plugin-Docs.md file with the plugin documentation, and the package.json is a minimal module with three dev dependencies for linting, eslint itself, the eslint-plugin-toml for TOML aware rules, and the stylistic plugin for ESLint. That last one tells you something real: the patches are linted as TOML in continuous integration, because a malformed address line in a patch file is a runtime crash rather than a compile error.

Maintenance is current. The last push was on 2026-10-18, the repository is not archived, and the only release is a rolling one named latest, published the same day. The README also points non-patch questions at the Xenia Discord server, and links a separate Discord for game patch discussion.

Installing means extracting a 7z next to the executable

The install procedure is short and has one prerequisite that is not optional.

You need the latest Xenia Canary experimental build, and the README repeats the caveat in both the install and the usage sections: patches are not supported on master or on outdated versions of Xenia Canary. A patch that writes to an address in one build of a game, and expects an emulator of a particular vintage, is not going to behave on a different emulator.

Then the archive is downloaded, the game-patches.7z file, and the existing patches folder is deleted if it is there, with a note to back it up if needed. Finally you open the archive and extract the patches folder into the same directory as xenia_canary.exe. The expected layout is shown in the README, with the executable and the patches directory side by side.

    └─── Xenia Canary
        |  ...
        │  xenia_canary.exe
        |  ...
        └─── patches
                ...
                584111F7 - Minecraft (XBLA, TU0).patch.toml
                ...

The file naming in that listing is the second important thing, because it is how a patch is matched to a game. The format is the Title ID, then the game title, then the title update in parentheses, and the .patch.toml extension. A patch is therefore bound to one title and one build of that title, which is why the hash appears in the name at all.

There is also a configuration switch to be aware of. The apply_patches option in the Xenia Canary config has to be set to true, which the README notes is the default. If a patch file is enabled and nothing happens, that setting is the first thing to check.

Enabling a patch is one boolean in a TOML file

Each patch file lists one or more patches, and each has an is_enabled flag that is false by default. You open the file for your game in a text editor, and change that flag to true.

    [[patch]]
        is_enabled = true

That is the whole activation mechanism, and there is no runtime UI for it. The file also carries a name, a description and an author, and a section describing the memory write itself, with an address and a value.

The feedback loop is the title bar. The README says that if you see the text Patches Applied in the title bar, then the patch applied successfully. That is a much better design than a silent write, because a patch that targets an address the current build does not use either does nothing or corrupts something, and both cases are otherwise indistinguishable from a broken game.

Two prerequisites sit alongside the flag. You need the right version of the game, in the README's terms the right Title Update, and the emulator must have apply_patches enabled. And the rule that catches people out is stated twice in the documentation, in bold: do not change the hash of an existing patch, and if your version of the game is different then the patch needs to be ported to that version. Changing the hash to make a patch apply to your build is the fastest way to get a crash, because the address is now pointing at whatever happens to live there in a different layout.

The hash in the filename is the game's identity, not a version tag

The naming convention is the repository's key convention, and the guidelines section states it precisely. A patch must be named Title ID - Game Title.patch.toml and be in the /patches directory, with the example given being a patch file for Blue Dragon that must be called 4D5307DF - Blue Dragon.patch.toml. If you are making a patch for a game that already has a file, you add to that file, with the only exception being a different module.

The hash itself is the module hash, and there is a documented procedure for obtaining it. Set the log_level option in the Xenia Canary config to at least 2, which the README says is the default, run the game at least once, close Xenia Canary, and then search xenia.log for the text Module hash. The title ID and the title name come out of the same log.

The submission rules are the part that keeps the collection consistent. There must be no whitespace, the hex for the title ID, hash and media ID must be uppercase, the hex for address and value must be lowercase, and pull requests and patches must be in English except where the game's own name or something in the code makes that inappropriate.

The uppercase and lowercase rule for two different kinds of hex in the same file looks fussy until you realise why it exists. The title ID is a stable identifier that appears in the file name, so it is part of the repository's index and is compared byte for byte. The address and value are machine-written payload, and they are handled by the patch engine. Splitting the conventions means a human scanning a diff can tell at a glance which half of the file is identity and which half is payload.

Aspect ratio and framerate patches have their own rules

Two patch families get their own guidance in the README, and both carry a trap.

For aspect ratio patches, the first rule is that the present_letterbox option must be changed from true to false, otherwise the black bars stay and the patch does nothing visible. The second rule is the important one: aspect ratio patches do not increase resolution. A 21:9 patch on a 16:9 display widens the image into the space you have, it does not give you more pixels.

Most aspect ratio patches are 21:9, described as 3440/1440, but they can be changed to other ratios unless a patch specifies otherwise. The README gives the procedure: divide your monitor's resolution width by height, convert the result to hex, and change the value in the patch file. The hex conversion is where the README links to an external float to hex tool, which is a reminder that this is arithmetic with a rounding step in it.

For framerate patches, the rule is that anything above 60 FPS requires the vsync option to be changed from true to false in the Xenia Canary config. The reason is not explained in the README, but it follows from how vsync interacts with a patched frame timing, and the effect of getting it wrong is a stutter rather than a crash.

The two rules together are a good illustration of the project's shape. A patch file changes a value in memory, and the emulator's own options decide whether that value has any visible effect. Understanding which layer is responsible for a symptom is the actual skill the repository teaches.

Writing a patch needs a reversing toolchain and a hash hunt

The Creating a patch section lists the tools, and they are the standard reversing stack for this platform.

Cheat Engine is the primary one, and the README has a dedicated section on setting it up. Memory breakpoints can be set in Cheat Engine or in MSVC with emit_source_annotations set to true, which gives annotations in the disassembly. Cheat Engine 7.2 and later include Big Endian types, but they have to be enabled by checking all of them under Edit, then Options, then Extra Custom Types. In Scan Settings you enable MEM_MAPPED, and the Memory Scan Options set Start to 100000000 and Stop to 200000000, with the note that this may change depending on the programs you have running.

The workflow is find a value, then attach the debugger to see what reads and writes to that address. The README notes that this shows an xex address when a breakpoint is hit, and that there is currently no way to set a breakpoint on execution within the Xenia Debugger itself, which is a real limitation of the loop.

For disassembly there is Ghidra with the XEX Loader, and IDA Pro with either the IDA 7 XEX Loader or the older IDA 6 one. Text editors are Visual Studio Code, VSCodium and Notepad++, and the optional tooling is the ESLint TOML plugin plus the Even Better TOML extension for VS Code and VSCodium.

There is one practical tip in the list that saves a lot of confusion: to make things easier, put Xenia Canary in the directory that contains /patches. The patch files reference paths, and a mismatch between where the emulator is and where the patches are is a quiet failure rather than a loud one.

What a data repository like this can and cannot give you

It is worth being clear about what this project is, because the name suggests a general modding platform and it is not one.

It is a curated set of memory write files for one emulator, keyed by game title and title update, applied by the emulator at launch, and enabled by hand in a text editor. It contains no patches for other emulators, no patch authoring tool, and no mechanism for distributing patches to end users. The quality bar is community review of pull requests, with the formatting rules enforced by linting.

The alternative to a patch is a configuration change, and the README itself points at it repeatedly. Emulator options such as vsync and present_letterbox are supported switches in the Xenia config, and changing them is safer than a memory write because the emulator knows what the value means and can react to it. The difference in approach is exactly that. A configuration option is a documented, versioned knob that the emulator validates, while a patch is an address and a value that the emulator applies without understanding, which is why the repository needs rules about hashes, about not changing them, and about porting patches to a different Title Update.

So the sensible division of labour is to set the options first and to reach for a patch only when there is no option for what you want, and to accept that a patch is tied to one build.

On the practical side, the repository is MIT styled in layout but the README does not state a licence, and the top level listing shows a .gitattributes and a .github directory with no LICENSE file, so the terms are not established by the documentation you have here. Check the repository and the Discord before redistributing any of the patch files.

Editorial conclusion

game-patches fits a Xenia Canary user who wants a specific tweak, such as a higher framerate or a different aspect ratio, and who is comfortable with a file that writes to a fixed memory address, and it does not fit a user whose game version differs from the one a patch was written against. Before enabling anything, check the Title ID in the file name against your own Title Update, because the README is explicit that a mismatched hash means crashes or a patch that silently does nothing.

Frequently asked questions

Official sources

1. Issues
2. README
3. Releases
4. xenia-canary/game-patches on GitHub