Quick Answer: SkyboundTOTK is an experimental Windows x64 static recompilation of The Legend of Zelda: Tears of the Kingdom base game 1.0.0. It translates the AArch64 game code into C, compiles a native executable, and renders through WebGPU via wgpu-native. You must supply your own legally obtained, unmodified 1.0.0 ExeFS and RomFS, and expect rough edges.

SkyboundTOTK is a static recompilation project, not a Switch emulator, and that difference shapes everything about it. The game code is translated ahead of time, then compiled on your own machine into a standalone Windows program. Most of the real work happens during the build, and that's where most people get stuck. A successful compile doesn't mean you'll finish the game. Here's what the project actually does, what you need before you start, and which problems are still open.

What the static recompilation actually does

Static recompilation takes compiled machine code from one architecture and rewrites it as source code for another. In this project, the source architecture is AArch64, the code the Switch runs, and the output is C. The build then compiles that C into a native executable. Nothing is interpreted at runtime the way an emulator would do it.

The pipeline has four parts:

  1. Lift: the AArch64 game code is translated into C.
  2. Compile: the generated C is built into a native executable with local toolchains.
  3. Runtime: a custom layer implements the system services the game expects.
  4. Render: graphics work and shaders are translated for WebGPU, then run through wgpu-native on Vulkan or Direct3D 12.

That last step is where people get confused. WebGPU is the graphics API the renderer targets. Choosing it doesn't mean the game runs in a browser. The Windows launcher produces a desktop program. Browser builds are not packaged or validated by build.bat.

Some graphics translation still happens at runtime. That's why the first launch of a new scene can stutter. The native pipeline cache in rxcache/ helps on later launches, but it can't guarantee smooth play.

You need your own, already-extracted, unmodified 1.0.0 base-game ExeFS and RomFS. The project includes no game files, generated game code, keys, firmware, or saves. It also doesn't extract NSP or XCI files, and other versions or updates aren't supported by the game-specific hooks.

Keep your dump, the generated code, the dist/ package, and your saves private. The game/, build/, and dist/ folders are Git-ignored, but the README says to check what you're publishing rather than trusting ignore rules. The generated standalone package contains copyrighted game-derived data and must not be shared or committed.

Here's the part most people miss. The build script checks the main and sdk module build IDs and a few RomFS directories. It does not verify the full RomFS or confirm that your dump is complete. A matching build ID tells you the right base game is present, not that every file is intact. If your package misbehaves, a bad dump is one of the first things to rule out.

Building on Windows: prerequisites and the failures you'll hit

The build needs a lot of room. Plan for at least 45 GB free in addition to the original game dump, because the lift creates large intermediate files and a separate packaged RomFS. The build is also CPU- and memory-intensive.

Here's what you need installed before you run build.bat:

  • Windows 10 or 11 x64, with a GPU and driver supported by wgpu-native
  • Python 3.10 or newer on PATH, plus lz4 (python -m pip install lz4)
  • Visual Studio 2022 Build Tools with the MSVC C++ tools and Windows SDK
  • Clang, clang++, and lld, either through emsdk (set EMSDK if it isn't in C:\emsdk) or on PATH

Run the build from an x64 Native Tools Command Prompt. A regular shell often can't find the Windows headers and libraries, and the error messages don't always make that clear.

The most common mistake is folder layout. Your extracted files must sit directly under game/exefs/ and game/romfs/. Paths like game/exefs/exefs/main or game/romfs/romfs/Event will fail. Here's the other trap: the builder reuses a completed lift only when its recorded game and lifter inputs match. If a lift was interrupted or its inputs changed, move build/ aside before retrying. The script also refuses to overwrite a nonempty dist/SkyboundTOTK/, so move the old package out of the way first. Copy its user/ folder into the new package if you want to keep your saves and settings.

FSR 1, frame interpolation, and what the toggles really do

The presentation pass has a few display features, and each one is easy to misread.

FeatureDefaultWhat it actually doesLimitation to know
FSR 1 (F8, sharpening on F9)OnSpatial upscaling with EASU and RCAS sharpeningNot FSR 2/3 temporal upscaling. Doesn't raise the game's internal render resolution
Frame interpolation (F7)OffInserts estimated frames using the project's own optical-flow methodDoesn't reduce input latency. The display runs about one game frame behind
Ultrawide (F6)OffAttempts to adjust camera and HUD for a wider windowNeeds a window wider than 16:9. A user reported stretching instead of a proper wider view
Aspect presentation (F10)ToggleSwitches between preserving aspect ratio and stretching to fillStretching alone is not true ultrawide

The common assumption is that frame interpolation makes the game feel smoother and more responsive. It makes motion look smoother, but the game still simulates the same number of frames, and the display lags behind real input. If you're competing in fast combat, leave it off. If you're watching a slower exploration scene on a high-refresh display, it may look better.

FSR 1 has a similar trap. Turning it on makes the image look sharper when the presented frame is enlarged, but it's spatial upscaling only. If your GPU is struggling, it won't reduce the internal load. Most people will see the difference in edge clarity, not in frame times.

Ultrawide is the feature to test carefully

F6 is the feature people most want, and it's the one the project is least sure about. The README says the camera and HUD adjustments are present, but a user reported that F6 stretched the image instead of giving a correctly proportioned wider view. The cause hasn't been found, and the camera behavior in that report hasn't been independently verified.

Here's the practical advice: if you try it, use a window wider than 16:9, toggle F6, and check whether the character and the HUD look proportionally correct. Compare the image against the normal view. If anything looks stretched, turn it back off. F10 stretching doesn't fix this, and it's not a substitute for real ultrawide support.

Known issues, and which ones need a retest

The README separates confirmed reports from earlier notes, and the difference matters when you decide whether a problem is your setup or the project.

  • Shadows and shaders: shadow shader problems have been reported. The standalone startup log showed three shader-decoder assertions, and their visual effect is unknown.
  • Terrain: some terrain can look randomly stretched, and some areas show incorrect textures. Causes aren't established.
  • Weapon and shield wheel: the background can render black instead of blurred. The earlier ability-wheel workaround hasn't been verified for weapons and shields.
  • Retest items: Zonai Portable Pot particles, the Depths gloom on the path to Ganon, and fused-weapon inventory icons all had earlier workarounds or fixes. None are confirmed in standalone SkyboundTOTK.

The honest summary is this: a successful build and a clean startup test confirm that the renderer initialized and the packaged RomFS loaded. They don't confirm full gameplay or graphics correctness. If you run into a crash or visual bug, record your game version, hardware, driver, location in the game, and settings. Those details are what make a report actionable.

Frequently Asked Questions

What is SkyboundTOTK static recompilation?

SkyboundTOTK static recompilation is an experimental project that translates the AArch64 code of Tears of the Kingdom base game 1.0.0 into C and compiles it into a native Windows executable. It is not an emulator. You supply your own legally obtained game files, and the project doesn't include any game data.

How do I build SkyboundTOTK on Windows?

Place your extracted ExeFS and RomFS under game/ with the correct folder structure. Then open an x64 Native Tools Command Prompt in the project folder and run build.bat. Make sure Python 3.10 or newer, lz4, Visual Studio 2022 Build Tools, and the LLVM tools are installed first. Allow at least 45 GB of free space beyond your game dump.

Does frame interpolation reduce input lag in SkyboundTOTK?

No. The feature inserts estimated frames between real frames to make motion look smoother. The game does not simulate more frames, and the display runs about one game frame behind. Leave it off if responsiveness matters more to you than smoothness.

Is SkyboundTOTK a Switch emulator?

No. It's a game-specific static recompilation, not a general-purpose Switch emulator. Some graphics translation still happens at runtime, so first launches of new scenes can stutter.

Give the build one clean try

Build the project once with your own verified 1.0.0 dump, launch the package, and note your GPU, driver, and the first scene where something looks wrong. That single test will tell you more than any summary, including this one. Pass this to someone who keeps hitting "build failed" errors with SkyboundTOTK static recompilation, and remind them to keep their saves in user/ before they move anything aside.