CitraVR is a Quest-native emulator port built without a game engine

A proof of concept for three XR problems

The reason this project exists is stated more clearly than most, and it is not simply that a 3DS emulator runs well in VR. The author describes it as a proof of concept of techniques XR developers were curious about, and names three of them: building a 2D and 3D hybrid application, creating a VR app that renders 2D interactive windows without an engine, and using VR layers to get sharp text and visuals. The emulator was the vehicle, not the point. That framing matters for a reader deciding whether to care, because the techniques are the transferable part. The third item is the one that has the most visible effect. Layered composition in XR is how you get a panel of text that stays crisp instead of turning into a smear of a curved display surface, and a project that renders a dense interface of game screens is a demanding test of that idea.

Engineless, native OpenXR, no Meta SDK

The implementation constraint is unusual. CitraVR is described as a Quest-native application, which in practice means OpenXR without a third-party game engine, and it is fully GPL licensed with the source publicly available. The independence claim is specific: 100 percent independent of the Meta SDK, which means the application talks to the runtime through the open standard rather than through the vendor's libraries. That has a practical consequence for anyone building on it. There is no Meta SDK to license, no vendor toolchain requirement and no closed component, so the build path is the same shape as any other OpenXR application, and the repository layout supports that reading. There is a CMakeLists.txt at the top level, a CMakeModules/ directory, a docker/ directory, externals/ for vendored dependencies, a .gitmodules file for submodules, a tools/ directory, and the src/ and dist/ trees. There is also a Doxyfile, so the project documents its own internals.

Upstream moved from a defunct Citra to Azahar

The project did not build on a stable upstream forever, and the migration is the most important maintenance fact here. CitraVR began as a port of the Citra 3DS emulator, and the README states plainly that the original Citra project is now defunct. Azahar was built on Citra's foundation and continues its development, and CitraVR has since incorporated those changes and now uses Azahar as its upstream emulator project. For a user, that means the emulator core underneath is improving on a schedule the project does not control. For a developer reading the code, it means the boundary between the port and the upstream has shifted, and the interesting part of this repository is the VR integration rather than the emulation. The release history shows the port moving in small steps, with a 0.6.0 beta and 0.6.0-beta.2 and beta.3 both dated 2026-07-25, and the 0.6.0 beta release on 2026-08-17.

Quest headsets and third party controllers are the supported surface

The compatibility story is narrow on hardware and wide on input, and that combination is a deliberate trade-off. On the headset side, the supported devices are Meta Quest 2, Meta Quest Pro, Meta Quest 3 and Meta Quest 3S, which means a standalone headset with no PC link requirement. There is no mention of SteamVR, Pico or any other runtime, so the project is a Quest application in the practical sense even though the underlying API is open. On input, the opposite holds. Touch controller bindings are documented as a diagram in the wiki, and for games that need more inputs, or for players who want them faster, the project supports a multitude of third party wired USB and wireless bluetooth controllers. That is the sensible priority order for a handheld emulator, since a 3DS has a control layout that a generic gamepad cannot express, so the native touch controls have to work well and the extra buttons are a bonus.

What the screen does inside the headset

The feature list is short and each entry is a design decision rather than a checkbox. Stereoscopic rendering is the obvious one for a 2D screen console in VR, since a flat panel in a headset is exactly the case where you want depth. A large, moveable and resizeable screen is the second, and it is the one that changes how you play, because you can pull the console display up to fill your view when you want detail and shrink it into a corner when you do not. Playable in mixed reality means the screen is composited into your actual surroundings rather than replacing them, which is what makes a virtual handheld feel like a handheld rather than a floating rectangle. A low-overhead port is the fourth, and it is the claim that matters most for a Quest, where the headset's own power budget is the binding constraint. The last feature, full GPL licensing with no Meta SDK dependency, is what makes the rest reproducible.

Installation and building live in the wiki, not the README

The README does not carry an install command, and it says where the instructions are instead, which is a reasonable choice for a project with a specific sideloading flow and a moving upstream. For running the application, the wiki holds a page titled How to install and run CitraVR on Quest and another titled How to back up 3DS Games, and those two are the whole getting started path. For compiling, there is a Building for Quest page. Everything else is organised the same way, with a Known Issues page, a Troubleshooting page, a touch controller input bindings diagram and a game compatibility list kept as a shared spreadsheet rather than in the repository. Support runs through the Flat2VR Discord, where a cvr-join channel leads to a CitraVR community and support forums, with cvr-support for questions and an issue tracker for bug reports and feature requests. The author also links a small donation page, described as buying a beer.

The limits are the platform, the upstream and the beta tag

Three constraints define where this project can go. The platform constraint is the headset list. Four Quest models are named, and nothing in the documentation suggests other vendors are supported, so a developer with a SteamVR headset or a Pico has no path in the current state. The upstream constraint is more subtle: the emulator underneath is now Azahar, which is still under active development, and a port that tracks an active upstream inherits that churn in its own build and compatibility behaviour. The third constraint is the beta label, which is attached to the project name itself in the README title and to the 0.6.0 release, so nothing here should be read as stable. The project is not archived, the last push was on 2026-09-07, and there is no homepage beyond the repository itself, so the wiki is the only documentation surface. The licence is GPLv3 or any later version, and the LICENSE.txt file in the repository root is the authoritative statement for anyone who wants to redistribute a build.

Editorial conclusion

CitraVR fits an XR developer who wants a worked example of a 2D and 3D hybrid application built on OpenXR with no engine in between, since the layering, the text rendering approach and the engineless structure are all visible in the source, and it fits a Quest owner with their own 3DS backups who wants stereoscopic play on a headset. It does not fit anyone outside the Meta Quest line, because the supported headset list stops at the Quest 3S, and it does not fit a team that needs a stable upstream pin, since the emulator project it follows is itself still under active development and the last push was on 2026-09-07 with the 0.6.0 beta release dated 2026-08-17. Before you build it, read the Install-Run-on-Quest wiki page for the sideloading path, check the game compatibility list for the titles you care about, and read license.txt, since the project is GPLv3 or any later version and that obligation follows your build as well as your source.

Frequently asked questions

Official sources

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