# MarioKart 64 Recompiled ports the N64 game without decompiling it

> MarioKart 64 Recompiled statically recompiles the Nintendo 64 game into a native Windows, Linux and macOS build, with RT64 supplying widescreen, high framerate and mod support. No game assets ship with it, so you supply your own copy of the original, and the repository is mostly tooling rather than game code.

**sonicdcer/MarioKart64Recomp** — Mario Kart 64 for PC (Windows/Linux/MacOS)

- Repository: https://github.com/sonicdcer/MarioKart64Recomp
- Stars: 617 · Forks: 17
- Language: C++
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/sonicdcer-mariokart64recomp

## Static recompilation, and why it is not a decompilation

The FAQ in the readme answers the technical question first, and the answer defines the whole project.

Static recompilation is the process of automatically translating an application from one platform to another, and this project uses N64: Recompiled to do exactly that to Mario Kart 64. The distinction the readme draws is with the decompilation projects that came before: unlike N64 ports in the past, this one is not based on source code produced by decompiling the game, because static recompilation bypasses the need for decompiled source code, which allows ports to be made without source code.

That is a large difference in what the repository contains. There is no reconstructed C for the game's logic. The repository instead holds the tooling: a CMake build, patch files, the RSP side, shaders, assets, controller data, and the toml files that describe the recompilation, with us.toml and aspMain.us.toml at the root, plus a .gitmodules file for the submodules the build pulls in.

The reverse engineering work of the decompilation team is still acknowledged, and it is used: the project uses headers and some functions from the decompilation project in order to make modifications to the game, and the readme credits that team for the enhancements that ended up in this port.

The practical result is a port that is legal to distribute for the tooling while still requiring the original game, which is why the readme states in bold that the repository and its releases do not contain game assets and that the original game is required to build or run the project.

## RT64 does the rendering, and it changes what the game looks like

The rendering engine is RT64, and the readme is clear that it is doing more than drawing triangles.

A lot of care was put into RT64 to make sure all graphical effects were rendered exactly as they did originally on the N64, and the project states that no workarounds or hacks were made to replicate those effects, with the only modifications being for enhancement purposes such as widescreen support. That constraint is the interesting part: an emulator or a modern reimplementation usually has to re-create the N64's visual quirks, and this project instead reproduces them and layers the enhancements on top.

Those enhancements are extensive. Any aspect ratio is supported, with most effects modded to work correctly in widescreen, and the HUD can be positioned at 16:9 when using ultrawide ratios. High framerate support comes from RT64 as well: game objects, terrain, texture scrolling, screen effects and most HUD elements all render at high framerates, and by default the project runs at your monitor's refresh rate, with an option to play at the original framerate instead. The readme is emphatic that changing the framerate has no effect on gameplay.

Two notes on the edges. External framerate limiters such as the NVIDIA Control Panel are known to cause problems, so the advice is to turn them off and use the manual framerate slider in the in-game graphics menu. And at very wide aspect ratios, some animation quirks appear at the edges of the screen in certain cutscenes.

Ray tracing via RT64 is on the planned features list, alongside model replacements and multi-language support with custom translations.

## You supply the cartridge, the port loads the assets

The install story is unusually short, and that is the point of the plug and play feature.

You provide your copy of the North American version of the game in the main menu and start playing. The project loads the assets from the copy you provided, so there is no separate extraction step and no need to build the game yourself.

There is a hard limit hidden in that convenience. The FAQ entry on choosing a different ROM says you do not, and that the project is only a port of Mario Kart 64 and will only accept one specific release. So the North American original is not a suggestion, it is the accepted input.

The releases are on GitLab rather than GitHub, with a link to the latest release from the readme, and the repository itself is on GitHub. There is also an interactive way to try the project before installing anything, in the form of a community Discord for the N64: Recompiled family of projects.

For anyone worried about the legal shape of it, the readme puts the boundary in one sentence: no game assets are distributed here, and the original game is required. The build and the resulting port are the project's contribution; the content stays with the person who owns it.

## The GPU list is short, and it is the real constraint

The system requirements are unusually specific, which makes them useful.

A GPU supporting Direct3D 12.0 with Shader Model 6, Vulkan 1.2, or Metal Argument Buffers Tier 2 is required. The oldest GPUs that should be supported per vendor are listed.

```yaml
* GeForce GT 630
* Radeon HD 7750 (the one from 2012, not to be confused with the RX 7000 series) and newer
* Intel HD 510 (Skylake)
* A Mac with Apple Silicon or an Intel 7th Gen CPU with MacOS 13.0+
```

The parenthetical about the 7750 being the 2012 card and not the RX 7000 series is the sort of detail that only appears in a document written by someone who has read support threads.

On x86-64 PCs there is a second requirement, a CPU supporting the SSE4.1 instruction set, which means an Intel Core 2 Penryn series or AMD Bulldozer and newer, while ARM64 builds work on any ARM64 CPU. That last point is what makes the Apple Silicon Mac a supported configuration rather than an emulated one.

The troubleshooting note is short and worth heeding: if you have crashes on startup, make sure your graphics drivers are fully up to date. For a project whose entire visual output goes through a modern graphics API, that is where the failures live.

## Menus, mods and a Steam Deck build

Beyond the rendering work, the project adds the things a modern platform is expected to have.

Gameplay settings, graphics settings, input mappings and audio settings are all configurable in an in-game config menu, and the menus can be used with a mouse, a controller or a keyboard. Additional control options let you set the stick deadzone and invert the X and Y axes for aiming. Low input lag is stated as a goal the project has been optimised for.

Mod support is the most open-ended of the features. Mods can change any part of the game, including adding completely new features and content, and they are installed either by dragging the mod files onto the game window before starting or with the Install Mods button in the mod menu, after which they can be toggled and some configured in that same menu. The readme points at a mod template repository, a modding documentation site and the RT64 documentation for texture packs.

For Linux, a binary and a Flatpak are available for most up to date distributions, including the Steam Deck. The Deck instructions are specific: extract the Linux build onto the deck, then in desktop mode right click the MarioKart64Recompiled executable and select Add to Steam, after which you return to Gaming mode and configure the controls.

That path is a good illustration of the project's shape in general. The port runs natively, the mod scene is built on top of it, and the deployment story is worked out per platform rather than left to a generic installer.

## Building it is a CMake job with patch files

The repository is a build tree rather than a game source tree, and its layout says what building it involves.

There is a CMakeLists.txt at the root with a CMakeSettings.json and a launch.vs.json for Visual Studio, a .clang-format for style, a .gitmodules file for the submodules, and a set of patches in a patches directory with a patches.toml describing them. The recompilation inputs are the toml files, us.toml and aspMain.us.toml, and there are directories for the RSP side, the shaders, the assets, the icons, the include headers, the source, a lib directory, and a flatpak directory for the Linux package. The controller database is recompcontrollerdb.txt, and BUILDING.md is the build document.

So the inputs to a build are the original game, the toolchain that N64: Recompiled provides, the patch set that adapts the recompiled code to this particular game, and the RT64 rendering library that supplies the graphics backend. The output is a native executable for Windows, Linux or macOS.

That is a meaningful difference from a decompilation-based port, where the reconstructed source is the input and the build is a normal compile. Here the translation is done by the recompilation tool and the port's personality lives in the patches, the shaders and the configuration files. It also means the build is tied to a specific toolchain and a specific set of patches, which is the maintenance cost that comes with the approach.

The project is not archived, and the last push was on 2026-08-11. The tagged releases are 0.9.2 in February 2026 and 0.9.1 in August 2025, which tells you the release line moves when there is something to release rather than on a schedule.

## Licence, saves and where this is the wrong choice

The licence is GPL-3.0, with the COPYING file at the repository root, and the trade is the usual one: you can read, build and modify the tooling, and the game content stays with you.

Save files are written to the platform's conventional location, and the readme lists all three.

```yaml
- Windows: `%LOCALAPPDATA%\MarioKart64Recompiled\saves`
- Linux: `~/.config/MarioKart64Recompiled/saves`
- macOS: `~/Library/Application Support/MarioKart64Recompiled/saves`
```

The case where this project is the wrong choice is straightforward: you do not own the original North American release, and there is no version of this port that ships the assets. If you wanted the game without owning it, this is not the route, and nothing in the project tries to be.

The second case is hardware. The renderer needs Direct3D 12 with Shader Model 6, Vulkan 1.2 or Metal Argument Buffers Tier 2, and on x86-64 a CPU with SSE4.1. A machine from before those eras can run the original hardware or an emulator, and this port is not an option.

The third case is expectations about the repository. People looking for readable, decompiled source to study will not find it, and people expecting a plugin ecosystem comparable to what the PC Mario Kart games have will find a mod scene that depends on a specific template and documentation set. What they will find is a working native port with widescreen, high framerate and mods, released under a copyleft licence, with the build left to the curious.

## Conclusion

MarioKart 64 Recompiled fits a player who owns the original North American release and wants it running natively on a modern machine, at a high refresh rate and in widescreen, with a modding scene attached. It is the wrong choice if you do not hold the original cartridge, if your GPU predates the Direct3D 12, Vulkan 1.2 or Metal tier the renderer needs, or if you expected a source code release. Check first that the release you download matches your platform, that your graphics drivers are current, since the readme ties startup crashes to outdated drivers, and that the build tooling in BUILDING.md and the CMake files works with the compiler on your machine.

## FAQ

### Do I need my own copy of Mario Kart 64 for MarioKart 64 Recompiled?

Yes. The repository and its releases do not contain game assets, and the original game is required to build or run the project. You provide your copy of the North American version in the main menu and the port loads the assets from it.

### What is static recompilation, and how is it different from decompilation?

Static recompilation is the automatic translation of an application from one platform to another. This project is not based on source code produced by decompiling the game, so the port can be made without decompiled source code, though it does use headers and some functions from the decompilation project to make its modifications.

### What GPU do I need to run MarioKart 64 Recompiled?

A GPU supporting Direct3D 12.0 with Shader Model 6, Vulkan 1.2, or Metal Argument Buffers Tier 2. The oldest listed are the GeForce GT 630, the Radeon HD 7750 from 2012 and the Intel HD 510, or a Mac with Apple Silicon or an Intel 7th Gen CPU running MacOS 13.0 or later.

### Where does MarioKart 64 Recompiled store save files?

In the MarioKart64Recompiled/saves folder under the local app data on Windows, under .config on Linux, and under Application Support on macOS. The readme lists the full paths for each platform.

## Sources

- [Issues](https://github.com/sonicdcer/MarioKart64Recomp/issues)
- [License: GPL-3.0](https://github.com/sonicdcer/MarioKart64Recomp/blob/main/LICENSE)
- [README](https://github.com/sonicdcer/MarioKart64Recomp/blob/main/README.md)
- [Releases](https://github.com/sonicdcer/MarioKart64Recomp/releases)
- [sonicdcer/MarioKart64Recomp on GitHub](https://github.com/sonicdcer/MarioKart64Recomp)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sonicdcer-mariokart64recomp