Code Lab
Lichii on GitHub: Ocarina of Time Fixes and the Code Behind Switch 2 Emulation
CODE LAB · PROJECT SPOTLIGHT
Lichii C++ · Experimental
Explore the source, rendering fixes, and published builds.
Preview: GitHub · zortos293/Lichii
A disappearing bush, a white flash, an outdated targeting marker: small visual bugs can lead to surprisingly interesting engineering.
Lichii is an experimental C++ emulator for Nintendo Switch and Switch 2, developed as an independent fork with roots in Eglantine, Eden, yuzu and Sudachi. Its public repository gives readers a way to follow the code, rather than judging a project only by a gameplay clip. The project says it is unaffiliated with Nintendo and distributes no games, keys or firmware. Project README.
This first Code Lab article follows the repository and a specific release. It is a source-and-release review, not a hands-on performance test. Checked November 8, 2026.
What changed for Ocarina of Time?
The release titled Lichii nx2 build 95 (222877d) focuses on several Ocarina of Time rendering problems. Its notes describe fixes for nearby foliage disappearing, white flashes during camera movement, terrain covering the scene, and a stale Z-target marker. They also list shader, memory and stability work. These are developer-reported changes; this article does not independently verify them. Build 95 release notes.
| Visible symptom | Engineering topic to explore |
|---|---|
| Objects vanish as the camera approaches | Visibility decisions and rendering state |
| The picture flashes when the camera moves | When the CPU can safely read GPU results |
| An old targeting marker remains visible | Keeping CPU and GPU memory updates consistent |
The useful question is: what information became available too early, arrived too late, or overwrote a newer value? That turns a screenshot into a starting point for reading a patch.
Version trap: this release’s URL and tag say build-94, while its title and application identify build 95. The maintainer explains that the tag is a numbering mistake. Record the title, tag and commit together when comparing reports.
The notes describe limited gameplay testing and unresolved issues, including AMD foliage/haze problems, HUD flicker, cutscene audio drift and a first-launch Linux shader stall. They promise no measured FPS improvement. Treat a newer build as a new test candidate, not proof of complete compatibility.
Read GitHub in this order
- README: establish what the project does, its ancestry and its stated limitations.
- Releases: select an identifiable snapshot. A pre-release label matters; a download is not necessarily a stable recommendation.
- Linked pull requests: follow one symptom into its implementation and discussion.
- Changed files and tests: look for the behavior the patch checks, then ask what still needs real gameplay testing.
- Issues: compare reports only when the build, hardware, drivers and reproduction steps are clear.
A commit identifies source history; a release packages a snapshot for users; a pull request explains a proposed change. Keeping these separate makes fast-moving projects much easier to follow.
Source code is different from a ready-made build
The repository provides a build guide that links platform-specific instructions for Windows, Linux and macOS. Start with the guide for your operating system rather than assuming that downloading a source archive produces a runnable application.
The README also notes an inherited naming detail: the GUI build target remains yuzu, while the desktop output is named Lichii. Old internal names can survive a rebrand; they do not, by themselves, identify a different download.
For a useful build report, record the source commit, operating system, compiler/toolchain and result. A successful compilation answers whether that source can be built in that environment. Gameplay correctness and frame pacing require separate checks.
Where does the Frizti fork fit?
Frizti/Lichii is publicly marked as a fork of zortos293/Lichii and describes a specialized focus. It is a separate development branch to inspect, not an interchangeable version number.
Compare the actual patches and matching build dates before choosing between forks. A useful comparison should keep the game version, scene, graphics settings and machine consistent, and separate average frame rate from pauses or visual errors. We have not run that comparison and do not rank either fork as faster.
What Code Lab will follow next
Code Lab explores public projects through their repositories: what a patch changes, how a build is produced, what a release claims, and what remains untested. Future coverage can follow one rendering fix from issue to pull request, or explain how an automated build becomes a downloadable release.
For this project, begin with the source repository, the maintainer’s release page, and the license. Public access to a repository is not a blanket permission to reuse everything in it; check the applicable license and file notices. This article links the software project and does not distribute game or system data.