CLI tool
gopher64/gopher64 avatar
gopher64/gopher64

gopher64 is an N64 emulator written in Rust with rollback netplay

Highly compatible N64 emulator

1,313 stars52 forksRustGPL-3.0

At a glance

What is it?
gopher64 is a cross platform Nintendo 64 emulator whose core is Rust, its window is a native Slint interface, and its netcode uses rollback rather than lockstep. The build is a submodule checkout and a cargo release build, the licence is GPLv3, and the project is unusually explicit about what it collects during an online session and about what kind of pull request it will accept.
Who is it for?
gopher64 suits someone who wants a maintained N64 emulator built on current Rust tooling, with a GUI that is not a web view, rollback netplay that does not desynchronise on a laggy frame, and builds that come as standalone downloads for four platforms, with the Windows executable code signed.
Can I use it commercially?
Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly Rust, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.

Editorial analysis

A Rust core with a native window and no browser in sight

gopher64 is a cross platform N64 emulator, and the shape of the repository tells you how it is put together. The `Cargo.toml` names the package `gopher64` at version 1.1.42, on edition 2024, requiring Rust 1.99.0, and it builds both a `cdylib` and an `rlib`, which is what lets the same code be used as a library by something else, such as the Android project in the tree. The default feature set is `gui`, and the GUI feature pulls in Slint, a file dialog library, a crate for opening files in the default application, and the Slint build helper. On non Android targets the windowing stack is SDL3, with the SDL3 crates configured to build from source statically and the font and text crates built vendored, and Slint itself is configured with the winit backend, the femtovg wgpu renderer and the accessibility feature enabled. The point of that list is that the emulator is a native application with a native toolkit, and the GPU path is a real renderer rather than a canvas inside a browser page.

Building from source takes a submodule and a release build

The build instructions are short, which usually means the project has been made easy to compile on more than one system. You need the SDL3 build dependencies, and for Ubuntu 25 the documentation points at the SDL3 wiki page and gives the compiler packages to install:

bash
sudo apt install clang llvm

Then the source itself, and the clone is recursive because there are submodules that have to come along:

bash
git clone --recursive https://github.com/gopher64/gopher64.git
cd gopher64
git submodule update --init --recursive
cargo build --release

The result is a binary you point at a ROM file:

bash
./target/release/gopher64 /path/to/rom.z64

For most people the release binaries are the better route. The project publishes a standalone Windows executable, a macOS app bundle for aarch64, a standalone Linux x86_64 executable and an Android APK, all from the releases page, and macOS users can also install through Homebrew with `brew install --cask gopher64`, while Linux users can install the Flatpak from Flathub with `flatpak install flathub io.github.gopher64.gopher64`. The Windows release is code signed for free, with signing provided by SignPath.io and the certificate by the SignPath Foundation.

Netplay is rollback, and the server logs a little

The netplay support is peer to peer, and the dependency list shows how it is built. The `ggrs` crate at version 0.13 with the `sync-send` feature is a rollback netcode library, which is the significant technical choice: instead of requiring every participant to receive the same input at the same moment, rollback lets a client rewind and resimulate when a frame arrives late, which is what keeps a session in sync over an ordinary connection. Around it sit `matchbox_socket`, `tokio-tungstenite` for WebSockets and `tokio` for the async runtime. The documentation asks you to read the netplay guide before trying it, which is sensible for a feature with that many ways to be misconfigured. The privacy section is equally specific: during an online session the server logs your IP address and basic session information, the game title and the session name, for operational purposes, and the project states that no additional personal data is collected or stored. If you turn on the RetroAchievements feature, additional data goes to that service under its own terms.

The feature list is mostly about how the picture looks

The notable features listed at the top of the documentation are netplay, homebrew support, upscaling, a CRT shader, emulated CPU overclocking, cheats, savestates and RetroAchievements. Read together, they describe an emulator that is trying to solve the two complaints people have with older emulators: that the output looks wrong on a modern display, and that the machine is not quite fast enough. Upscaling and the CRT shader address the first, with the shader recreating the look of a CRT on a modern display, and the emulated CPU overclocking addresses the second by letting you run the console's processor faster than the original hardware did. Savestates and the cheat support are conveniences that any mature emulator has. Homebrew support is the more interesting one, since it means the emulator is intended to run software that was never sold commercially, which is a different use from running a dumped retail game, and the last push to the repository was on 2026-10-15 with releases v1.1.38, v1.1.40 and v1.1.42 within the same month.

Portable mode and the Flatpak filesystem catch

Two small operational details are documented that will otherwise cost you time. The first is portable mode. If you want to keep all the game data in the same folder as the executable, you create a file called `portable.txt` in that directory, and the emulator then treats the folder next to the binary as the place for its data instead of the user's data directory. The second is the Flatpak, which is sandboxed and therefore cannot see your ROMs by default. The documented fix is to add the filesystem permission when you run it from a command line:

bash
flatpak run --filesystem=host:ro io.github.gopher64.gopher64 /path/to/rom.z64

The `host:ro` part is the point, since it grants read only access to the host filesystem rather than read and write. Controls are mapped through a default keyboard setup in the wiki, and Xbox style controllers get their own default mapping, so a new user is not starting from a blank configuration.

The contribution rules rule out AI agent pull requests

The contributing section is unusual enough that it deserves its own attention, because it tells you something about how the project wants to be worked on. Pull requests that are vibe coded, or co-authored by AI agents in Plan or Agent mode, are not permitted, and a pull request should be scoped to a single feature or improvement rather than a bundle. The maintainer asks to be contacted through a GitHub issue or on Discord before substantial work is started, which is a reasonable way to avoid wasted effort but does mean an outside contributor cannot simply open a large patch. For a project of this size, the consequence is that the surrounding community does the work, and the codebase is likely to read consistently because every change arrives in small, reviewable pieces. It also means that if you plan to work on gopher64 with an AI assistant in the loop, that is a conversation to have with the maintainer first.

Licence, provenance and what is borrowed

Gopher64 is licensed under GPLv3, and the licence section is candid about the origins of the code, saying that many portions have been adapted from mupen64plus and from ares, with the licences for both of those projects linked. That matters for anyone planning to reuse the code, because the obligations of GPLv3 apply to the combined work rather than only to the parts written here. The dependency list shows the usual assortment for a project of this kind, from zip and sevenz handling for compressed ROM archives, through the mimalloc allocator, to obfstr, which is a crate for obfuscating string literals. The licence file, the `.gitmodules` file, the `data/` directory, the `parallel-rdp/` directory, the `retroachievements/` directory and the `android-project/` directory make up the rest of the tree, and the presence of a `rust-toolchain.toml` means the toolchain version is pinned for everyone who builds it.

Editorial conclusion

gopher64 suits someone who wants a maintained N64 emulator built on current Rust tooling, with a GUI that is not a web view, rollback netplay that does not desynchronise on a laggy frame, and builds that come as standalone downloads for four platforms, with the Windows executable code signed. It is a poor fit if you want a fully self contained setup with no SDL3 build dependencies, and it is a poor fit if you plan to contribute patches produced by an AI agent, since the project rules that out explicitly. Before you build it, check three things: that you can install the SDL3 dependencies for your distribution, since the Ubuntu instructions are the only ones spelled out, that your Rust toolchain matches the pinned version, with the manifest requiring 1.99.0, and what you want to happen with your data during netplay, since the server logs your IP address, game title and session name.

Frequently asked questions

How do I build gopher64 from source?

Install the SDL3 build dependencies, which on Ubuntu 25 means `sudo apt install clang llvm`, then clone the repository with `git clone --recursive https://github.com/gopher64/gopher64.git`, run `git submodule update --init --recursive`, and build with `cargo build --release`. The binary is then run as `./target/release/gopher64 /path/to/rom.z64`.

Does gopher64 have netplay?

Yes, peer to peer netplay, built on the ggrs rollback netcode library with a matchmaking client and a WebSocket transport. The project asks you to read the netplay guide before trying it, and notes that the server logs your IP address, the game title and the session name during a session.

How do I install gopher64 without building it?

Standalone executables are published for Windows, Linux x86_64, a macOS app bundle for aarch64 and an Android APK. macOS users can also use `brew install --cask gopher64`, and Linux users can install the Flatpak with `flatpak install flathub io.github.gopher64.gopher64`.

Why cannot the gopher64 Flatpak see my ROMs?

The Flatpak is sandboxed, so it needs explicit filesystem access. The documented command line form adds the read only host permission, for example `flatpak run --filesystem=host:ro io.github.gopher64.gopher64 /path/to/rom.z64`.

What does gopher64 do with my game data?

The privacy section states that during online netplay sessions the server logs your IP address and basic session information, the game title and the session name, and that no additional personal data is collected or stored. Enabling RetroAchievements sends data to that service under its own terms.

Official sources

  1. gopher64/gopher64 on GitHub
  2. License: GPL-3.0
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/gopher64-gopher64.svg)](https://hysenlabs.com/projects/gopher64-gopher64)

Was this useful?