TriAevum: a native PC recompilation of Ocarina of Time 3D, explained

What TriAevum actually is, and who it is for

TriAevum is described in its README as an AOT recompilation of The Legend of Zelda: Ocarina of Time 3D into a native PC application, in the same general spirit as the Xbox 360 recompilation projects. It is not an emulator that interprets a ROM at runtime. The README says the author spent most of the time on the renderer rather than on playing the game, and that the goal is to push the visuals further without completely losing the original look.

The intended user is narrow. You need Windows or Linux x64, a Vulkan-capable GPU with current drivers, and your own supported decrypted ROM. The README states Forge accepts .3ds and .cci and checks the contents rather than the filename, and that any personal EUR or USA dump should work if it is decrypted and in one of those two formats. No ROM or original game assets ship with the project.

That is the whole audience: someone with a legal dump, a Vulkan GPU and a tolerance for alpha software. Anyone looking for a turnkey way to play Ocarina of Time 3D without owning the cartridge data is outside the project's scope by design, and the README is explicit that no ROM or original assets are included.

How the recompilation and the NRI/Vulkan renderer fit together

The architecture visible in the README splits into two stages. Ahead of time, the game code is recompiled into native code, which is why no compiler or SDK is needed at install time. At runtime, a separate renderer built on NVIDIA NRI and Vulkan draws the scene, and a Forge tool handles preparation: it validates the ROM, downloads the official TopScreen texture package, and prepares the bundled shaders for your GPU automatically. Shaders encountered later are cached while playing.

The renderer carries the features that distinguish the project: cel and toon shading with outlines, ambient occlusion, optional reflections, shadows and anti-aliasing, real widescreen framing with a configurable field of view, and procedural grass. The README also lists 60/90 FPS visual interpolation of the original 30 Hz game state, with an explicit caveat that game logic and gameplay speed stay unchanged and that this is not 60/90 Hz physics. That distinction matters: interpolation changes what you see between simulation steps, not how fast Link moves.

Two smaller pieces round out the runtime. The single-screen HUD and menus are a reimplementation of TopScreen by rlgcarrot, credited in the README, and the input layer covers configurable keyboard and mouse plus controllers, with the SDL controller-mapping community listed among the credits. Settings profiles, audio and save states are named as features, and F1 opens the settings UI.

Installing TriAevum on Windows and taking the first run

The README gives a three-step Windows path. Download the Windows-x64 ZIP rather than GitHub's source-code archive, and extract it into a writable folder. Then run TriAevumForge.exe and select your decrypted ROM. When setup finishes, choose Launch game; afterwards you start the game with TriAevum.exe instead of Forge.

If you prefer the command line, the repository also ships a helper script for the mesh viewer, which is a separate diagnostic tool rather than the game:

run_oot3d_native_mesh_viewer.cmd

On Linux and Steam Deck the README uses a Flatpak. Install it through your software manager or from the terminal:

flatpak install --user ./TriAevum-v0.6.0-alpha.2c-Linux-x86_64.flatpak

Then open TriAevum, select your decrypted ROM in Forge, and choose Launch game when preparation finishes. On Steam Deck, the README says to prepare the game in Desktop Mode before adding TriAevum to Steam, and notes that physical Steam Deck and Gaming Mode testing have not yet been performed.

Two operational details are easy to miss. Forge downloads the official TopScreen texture package during setup, so an Internet connection is required unless that package is provided locally via docs/TRIAEVUM_TOPSCREEN_INSTALLATION.md. And the README asks you to back up saves, settings and prepared data: data/ beside the Windows application, or ~/.var/app/io.github.coccofresco.TriAevum/ on Linux. Press F1 for settings once you are in; F2 temporarily disables the main added graphics effects and restores them without losing your configuration.

The alpha testing record is the real limitation

The README does not hedge about maturity. It calls the project an experimental alpha and not a fully tested port, and states that gameplay testing currently covers the early parts of the game. The USA adapter has been checked through installation, the title intro and file selection, not a full playthrough. The author notes a preference for tweaking shaders over finishing Zelda again and asks for people willing to actually play through it.

For anyone deciding whether to adopt this, that is the boundary. Content later in the game is unverified by the project's own account, and the README asks bug reports to include version, ROM input and revision, GPU and driver, settings and reproduction steps. It also singles out normal in-game save files as particularly useful for problems later in the game, which implies those reports are expected to come from players rather than from an internal test pass.

There is a second, structural limitation: the README states development of the project is entirely AI-assisted under human direction, and describes the TriAevum-specific work that way while distinguishing it from the mature donor projects and libraries it builds on. A reader should treat that as a statement about how the code was produced, not as a quality claim in either direction. It does mean the usual signals you would use to judge a codebase, such as a long human review history, may not apply here.

Finally, the project is renderer-first by the author's own description. If your interest is accuracy of game logic rather than presentation, this is the wrong tool, since the README frames the visual push as the point and the interpolation as purely presentational.

How TriAevum differs from Azahar and Ship of Harkinian

The README names Azahar, Ship of Harkinian, libultraship, NVIDIA NRI and the SDL controller-mapping community among the projects it depends on, and credits Nintendo and Grezzo for the original game. The relationship is not just a credit line: Azahar-compatible custom textures and texture dumping are supported, which means TriAevum slots into an existing texture-modding pipeline rather than defining its own.

The difference in approach is what happens to the game code. Azahar is an emulator, so the 3DS binary runs through emulated hardware and the rendering path is a reimplementation of the 3DS GPU's behaviour. TriAevum recompiles the game ahead of time into native PC code and drives it with an NRI/Vulkan renderer, which is what allows features like configurable field of view, toon shading and procedural grass to sit outside the original rendering model. The trade-off is that the recompilation must be correct for each supported ROM revision, which is why the README scopes support to personal EUR and USA dumps and why the USA adapter is described as checked only through the title intro and file selection.

Ship of Harkinian is the closer comparison in spirit, since it is a native port rather than an emulator and is also credited here. The practical distinction a reader can draw from the README is that TriAevum targets the 3DS release specifically, with its TopScreen-derived single-screen HUD, rather than the Nintendo 64 version.

Licence, source obligations and upgrade cost

Original contributions are licensed under GPL-3.0-or-later, and the repository separates that from the components it builds on: LICENSE_SCOPE.md describes the licence scope and THIRD_PARTY_NOTICES.md carries the third-party notices. If you fork or redistribute, the GPL-3.0-or-later terms apply to the original contributions, while Azahar, Ship of Harkinian, NRI and the other dependencies keep their own licences. This is a description of what the repository states, not legal advice; read LICENSE_SCOPE.md and THIRD_PARTY_NOTICES.md before shipping anything.

The repository layout supports the source-availability side of that: SOURCE_OFFER.md, SOURCE_ARCHIVE_MANIFEST.json and docs/TRIAEVUM_PRECOMPILED_RELEASE.md are present at the top level, and the README points to the release and build contract for source availability and developer packaging. A CMakeLists.txt and a CMake/ directory are also at the top level, so building from source is a CMake-based process, though the README does not walk through it because the normal path is a prebuilt ZIP or Flatpak.

Upgrade cost is where the alpha status bites. The release history shows three v0.6.0-alpha.2 tags on the same day, including a note that USA support returned in alpha.2b, and the README points to docs/releases/v0.6.0-alpha.2b.md for release notes and known limitations. Prepared data and shader caches live under data/ on Windows and under ~/.var/app/io.github.coccofresco.TriAevum/ on Linux, and the README asks you to back them up, so a version bump is a copy-and-restore operation rather than something the project automates. The README does not document rollback.

Editorial conclusion

Adopt TriAevum if you already own a decrypted EUR or USA .3ds or .cci dump, run Windows or Linux x64 with current Vulkan drivers, and want to play the early game with toon shading, widescreen framing and interpolated 60/90 FPS presentation. Do not adopt it if you expect a finished port: the README states gameplay testing covers only the early parts of the game, and the USA path has been checked through installation, the title intro and file selection rather than a full playthrough. Before committing, verify that your ROM passes Forge's content check, confirm the Forge texture download can complete or that the TopScreen package is provided locally, and back up the data/ folder beside the Windows application or ~/.var/app/io.github.coccofresco.TriAevum/ on Linux.

Frequently asked questions

Official sources

1. coccofresco/TriAevum on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases