Pyrite64: an N64 game engine and editor built on libdragon and tiny3d

What Pyrite64 is for, and who it is aimed at

Pyrite64 is a visual editor plus a runtime engine for 3D games that run on a real Nintendo 64 or on emulators accurate enough to stand in for one. The README is explicit that the project does not use any proprietary N64 SDKs or libraries. Its two dependencies are libdragon and tiny3d, both open source. That choice defines the audience: developers who want to ship homebrew N64 software without touching a licensed SDK, and who are willing to work inside a smaller ecosystem than the one that surrounds modern consoles. The editor is the entry point. It handles scene management, rendering, collision and audio at runtime, and it exposes a node-graph editor for scripting basic control flow, so a designer can wire up behaviour without writing C++ for every interaction. Asset handling is global, with automatic memory cleanup, which matters on a machine with 4 MB of RAM. The README notes the project is in early development, that features are missing, and that documentation is a work in progress. It also warns that breaking API changes are expected. That warning is the single most useful sentence in the file for anyone deciding whether to start a project today.

How the editor and runtime engine fit together

The repository splits into src/, n64/, tools/, data/, docs/, packaging/, scripts/ and vendored/. That layout reflects the two halves of the product. The editor is a desktop application built from CMake; the n64/ directory holds the code that ends up on the console. External libraries used by the editor sit under /vendored, each with its own licence, which is why the README points there rather than listing them all. Assets move in one direction: GLTF models are imported from Blender with fast64 material support, and the editor converts them into a form the runtime can load. The README lists HDR with bloom and 256x256 big-texture rendering as rendering features, both of which are unusual for the platform and both of which depend on tiny3d. At runtime the engine owns scene management, rendering, collision and audio, so a game built in Pyrite64 is mostly configuration and node graphs plus whatever C++ you add. The node-graph editor is described as covering basic control flow. That word basic is doing real work: it tells you the graph is not a general-purpose scripting language, and logic that outgrows it belongs in code. The README does not document the graph's node set or its limits, so treat that boundary as something to discover by reading /docs.

Installing Pyrite64 on Windows and running a first project

The README states that the editor performs automatic toolchain installation on Windows, which is the path of least resistance. The documentation site at hailtododongo.github.io/pyrite64 also covers how to build the editor from source. Before anything else, the README asks you to read the FAQ on the documentation site. Once the editor is installed, the docs are where project creation and building are described. The README itself does not give a command sequence for creating or building a project, so no walkthrough beyond that point can be written from the README alone. What the README does name are the two emulators accurate enough to run and test games: Ares v147 or newer, and gopher64. Anything less accurate will not reproduce hardware behaviour, and the README frames this as a requirement rather than a preference, because the project targets real hardware first. The README links a release video and a game called Cathode Quest 64 as examples of what the engine produces; those are the closest thing to a reference project in the README. For a first real use, follow the editor's project creation flow in the documentation, import a GLTF model with fast64 materials, place it in a scene, and build a ROM to load in Ares or gopher64.

Emulator accuracy is a hard requirement, not a convenience

Most console toolchains treat emulation as a debugging shortcut. Pyrite64 inverts that. The README says the project focuses on real hardware and that accurate emulation is required to run and test games on PC, naming Ares v147 or newer and gopher64 as the emulators that qualify. The practical consequence is that a ROM which renders correctly in a permissive emulator may still fail on a console, and the failure will look like a bug in your game rather than a limitation of the emulator. If your existing workflow depends on an older or faster emulator, Pyrite64 will not fit it. The same emphasis explains why HDR with bloom and 256x256 textures are worth mentioning at all: they are rendering paths that stress the hardware in ways that inaccurate emulation tends to paper over. The README does not describe a fallback for developers who cannot test on hardware, and it does not claim that any emulator is a substitute for one.

Where Pyrite64 is the wrong tool

Three cases stand out. First, if you need API stability, the README's warning about breaking API changes should end the evaluation. A project that expects its interface to move is a poor base for a long-lived codebase with multiple contributors. Second, if you develop on macOS, the README documents automatic toolchain installation for Windows only, and it does not describe an equivalent for other platforms. Building the editor from source may work, but the README does not promise it, and the docs are described as a work in progress. Third, if your game is mostly 2D or does not need the editor's scene and asset pipeline, the engine's value proposition shrinks: you would be carrying a 3D runtime, a node-graph system and a global asset manager for features you are not using. The README also does not document rollback, migration steps between releases, or a compatibility policy across versions, so an upgrade from v0.7.0 to v0.8.0 is something you plan for rather than assume. None of this is unusual for a project at this stage. It is simply the cost of adopting early.

How Pyrite64 differs from writing libdragon code directly

The obvious alternative is libdragon itself, which Pyrite64 builds on. Libdragon is a library: you write C, you call its APIs, and you own the build, the asset pipeline and the scene structure. Pyrite64 sits above that and adds an editor, GLTF import through fast64 materials, a global asset manager with automatic cleanup, and a node-graph editor for control flow. The difference is where the work happens. With libdragon you decide how a level is represented and how assets are loaded; with Pyrite64 those decisions are made for you, which is faster to start and harder to change. The trade is control for speed. If you already have a libdragon codebase, or you want to tune memory layout yourself on a 4 MB machine, the editor's abstractions will get in the way. If you are starting from nothing and want a scene with a model in it running on hardware this week, Pyrite64 removes a large amount of setup. The README's note that Pyrite64 does not use proprietary SDKs applies to both paths, so that is not the deciding factor.

Licence, attribution and what it costs to keep up

Pyrite64 is MIT licensed, and the README states the terms plainly: the project does not force restrictions or licences on games made with it, and it does not claim copyright over assets or source code generated by the editor. Crediting Pyrite64 with a logo or name in your credits or boot sequence is requested but not required. That is a permissive position, and it is worth confirming against the LICENSE file and the per-directory licences under /vendored before you ship, since the editor bundles external libraries with their own terms. On maintenance, the repository is not archived, and the last push was on 2026-09-12. Releases are frequent: v0.8.0 on 2026-07-28, v0.7.0 on 2026-06-16, and v0.6.0 on 2026-03-30. That cadence cuts both ways. Fixes arrive quickly, and so do the breaking API changes the README warns about. Budget for reading release notes and retesting your build after each version bump, and keep your project pinned to a known release rather than tracking main. The README does not document a deprecation window or a migration guide, so plan on reading the diff.

Editorial conclusion

Adopt Pyrite64 if you want to build 3D N64 games against libdragon and tiny3d without assembling a toolchain by hand, and you accept that the README warns of missing features and breaking API changes. Do not adopt it if you need a frozen API or you plan to develop primarily on macOS, since automatic toolchain installation is documented for Windows only. Before committing, read the FAQ and the documentation site, confirm your emulator is Ares v147 or newer or gopher64, and check the /docs source in the repository against the version you install.

Frequently asked questions

Official sources

1. HailToDodongo/pyrite64 on GitHub
2. License: MIT
3. Project website
4. README
5. Releases