Zelda Wind Waker HD Devel Build: 277 Shader Compiles Drop to 33

By Indie Kings | October 22, 2026

Updated October 22, 2026: The Wind Waker HD recompilation project published a development build on 22 October 2026, at commit a7ea411, and its own release note says plainly that this is not a release. What is in it is still worth reading: frame interpolation at 40, 60, 120 and 240 frames per second no longer changes how the game plays, a 40 fps mode lost its judder, and an optional shader preparation step cut shader compiles during play from 277 to 33 in the project's test route.

Image: GitHub repository card for ZeldaWWHDRecomp/ZeldaWWHDRecomp, the native PC port of The Wind Waker HD.

A development build, described as one

The project recompiles The Wind Waker HD for PC, macOS, Linux and Android from the player's own disc dump. Version 0.4.0, published on 21 October 2026, brought a world editor and a much better Android build. The build published a day later is a development snapshot from the devel branch, and the notes do not pretend otherwise: it carries changes that are not released yet, has had less testing than a release, and readers are told to include the commit hash when reporting a problem.

That framing is honest and it is also useful. A development build is where a project shows the shape of its next release, and this one has a clear theme. Two of the biggest items are about determinism: the game behaving the same way at 240 frames per second as it does at 30, and the same way on two runs of the same route.

The repository has 957 stars, 72 forks, 21 watchers and 28 open issues, with a size of about 20,900 KB. It is C++ under MPL-2.0 and was created on 1 October 2026, which makes the pace of the last three weeks the more impressive number.

Frame interpolation stops changing the game

Frame interpolation is what lets a 30 fps game look smooth at 60, 120 or 240. The renderer draws the game's real steps at 30 per second and generates intermediate frames between them. The catch, and the reason this change matters, is that generated frames are not free of side effects if the code that produces them touches state the game also uses.

The notes describe two specific leaks. Extra frames drawn between the game's steps were consuming random numbers, and they were deciding what was visible using the blended camera rather than the game's own. The result was that enemies, effects and sounds could play out slightly differently at a high frame rate than at 30 fps.

The fix makes the game play exactly as it does at 30 fps, at 40, 60, 120 and 240, with the 40 fps case also covered while Z-targeting. Only the picture is smoother. That is the correct definition of interpolation for a game with deterministic combat, and it is a harder property to achieve than smoothness, because it requires auditing every random draw and visibility decision that the interpolated frame path can reach.

The same section lists what now interpolates smoothly that did not before: camera shake, clouds, eye movements, lava, scene wipes, chains, the Swift Sail and its boost blur, debris, Valoo, light beams and searchlights, plus a later list that adds boss hit flashes, sand floors, cloth and flags, water masks, shadows and mod HUDs. Fade-ins and fade-outs no longer flicker with interpolation on, which was issue 273.

Why 40 fps juddered, and the three-quarter step fix

The 40 fps fix is the most precise item in the notes and the easiest to picture. A 30 fps game cannot show 40 fps by dividing each step evenly, because 40 does not divide 30. The old approach alternated between showing a frame half a step ahead and a full step ahead, which produced an uneven cadence: half, half, one, one.

The new approach shows every frame at three quarters of a step apart, so the spacing is constant and camera turns are even. The issue number is 254. It is a small change with a visible result, and it is the kind of bug that a frame rate counter cannot see: the average is right, the pacing is not.

277 shader compiles become 33

The largest performance item is an optional setup step called "Preparing shaders: models", off by default. When switched on, setup draws every object model, every stage's rooms and the characters and objects they place, the sky and weather at different times of day, plants and the file select, using the game's own code, so their shaders are compiled before the player starts.

The result in the project's own test route is specific: shaders compiled during play dropped from 277 to 33. The cost is about 8 to 10 minutes on a Mac during setup. That is a good trade to offer and a bad one to impose, which is presumably why it is off by default.

What makes this more than a precompilation trick is the cache work underneath it. Each shader is now stored once in the pipeline recipes and in the SPIR-V cache, and the SPIR-V cache had stopped growing at its size limit before this build. Shaders of an object's models are also prepared as soon as the game loads that object, which spreads some of the work out of the setup step.

Smaller caches and the new Shader compile setting

Two changes follow from the same work, and together they give the player a choice between correctness and smoothness.

Change	What it does	Default
Preparing shaders: models	Setup draws models, rooms, characters, sky and weather to compile their shaders before play; compiles during play fell from 277 to 33 in the test route, at about 8 to 10 minutes on a Mac	Off
Shader compile	Off draws everything exactly and waits for shaders that are not ready; Fast keeps playing while they compile and may leave out a few objects for a frame or two	Off
Cache layout	Each shader stored once in the pipeline recipes and the SPIR-V cache; an object's model shaders are prepared as soon as the game loads the object	Always on

The Fast setting is the honest version of a compromise that many ports hide. A missing shader normally means a stall while it compiles, and the alternative is to keep rendering and accept that a few objects may be absent for a frame or two. Making that a named setting, off by default, with the trade stated in the notes, is better than silently choosing either behaviour.

The sun that made runs differ

One fix in the notes is small enough to skim and important enough to keep. The game's check for whether the sun is hidden was answered whenever the GPU finished, which is a timing-dependent input. Two runs of the same route could therefore diverge slightly. The answer now arrives at a fixed point, so the game behaves the same regardless of timing.

The notes add one cost, stated rather than hidden: the glare reacts one game step later than it did on the Wii U, with no performance cost. That is the sort of sentence that makes a changelog trustworthy. A determinism fix that changes the timing of a visible effect by one step is exactly the kind of detail a project is tempted to leave out.

Android heat warnings and the refresh rate report

The Android build gets two fixes, one of which will be familiar to anyone who has run a demanding game on a handheld. Some devices report Android's highest heat level while they are cool; the notes give the AYANEO Pocket EVO reading Android's top level at a 30 degree battery as the example. Setup, the heat guard and the performance report now believe that signal only alongside a real high temperature, defined as a battery at 40 degrees or more, or a processor at 90 degrees or more.

The second change is diagnostic. The performance report now shows the screen's actual refresh rate, the rate the game asked for on Android, and whether the chosen frame rate divides evenly into it. Their example is the useful one: 40 fps needs a 40, 80 or 120 Hz screen to be shown evenly. That turns a vague sense that a handheld feels wrong into a check the player can perform.

The Android requirements have not moved: arm64, Android 13 or newer, Vulkan 1.3. The APK is built for phones and tablets, and the x86-64 APK exists for emulators and Chromebooks. As with the desktop builds, the game is built on the device from the player's own files, once, over a few minutes.

Launcher and data folder fixes

Three fixes in this build are about starting the game the way a PC user expects to start it, and all three carry issue number 266.

The game previously only started through the launcher. Started directly, from another folder, it could not find its game files. It now always works from its data folder, and the new data-dir option chooses one explicitly. A missing mod compiler now produces a clear message over the game and in the Mods tab, with the repair path, instead of a silent failure, and content mods no longer need the compiler at all. And the editor flag, which started the game without the world editor on Windows, is now passed through by the launcher on Windows, macOS and Linux.

That last one is a small window into the cost of shipping on four platforms. The flag worked when the game was launched directly and failed when it was launched the normal way, because the launcher filters and forwards its arguments. The fix is three separate documented invocations, one per platform.

The mod-maker additions

The remaining notes mix mod-maker additions with smaller fixes: a detailed performance profiling setting that is off by default (issue 261), Link's fist floating off his arm (issue 255), a world editor scene hang and a mod-stage jump crash, and a Meta Quest floating theater (issue 259). The mod-maker work is where the project is investing after shipping the world editor in 0.4.0. Mod islands are visible from farther away, so their grounds, kit models and distant views stay visible across their square and into the next ones, with the game's haze. A stage entry can be a hole Link falls into. A scene's area trigger can play again after Link leaves the area.

New catalogue items include the three Goron merchants, who can be placed on a mod island and given their own text, plus torches, flames, fire jets, lava bubbles, Dragon Roost's bomb flower, stone blocks, breakable rocks and boulders, and Zunari's stall in three sizes. Lava is now a real material, with a col_lava ground that burns Link exactly as the game's lava does, including the jump, the half-heart loss and the return to solid ground, and it makes bombs explode. Water in mod stages is swimmable now; its surface had been sitting one level too deep, so Link stood on it. A sea model can use the game's own materials and be lit like the islands at every time of day.

None of that is performance work, and all of it is the reason a recompilation project outlives its first release. The world editor needs content to edit, and a catalogue of working objects is what makes an editor useful.

A dev build, your own dump and an unsigned app

Our take: the engineering is serious and the usual caveats apply with one addition.

The addition is that this is explicitly not a release. The notes say it has had less testing, and the project tells you to report the commit hash, which is what a development build is for. If you want to play rather than test, wait for the next release and read these notes as a preview of what is coming.

The rest is unchanged from 0.4.0. It ships no game files, no game code and no keys; you need your own disc dump (.wux or .wud with its disc key, plus the Wii U common key), or a Cemu .wua archive, or an already extracted game folder, and the installer builds the game from it on your machine. The macOS app is not signed by Apple, so macOS 15 and later requires Open Anyway, and macOS 14 requires a right-click open. The Windows executable triggers SmartScreen. The Android APK publishes its signing certificate hash on the release page, which is the right check when the app is not distributed through a store.

This site has covered the legal shape of these projects before and the position is consistent: recompilation projects ship code, not games, and the obligation to own the disc is stated by the project itself. That resolves the distribution question and not the platform-terms question, which is a decision each player makes.

FAQ

Is this a release?
No. It is a development build from the devel branch at commit a7ea411, published 22 October 2026. The project says it is not a release and has had less testing than one.

What is the biggest change?
Frame interpolation no longer affects gameplay. Extra frames used to consume random numbers and decide visibility from the blended camera, so enemies, effects and sounds could differ at high frame rates. The game now plays exactly as at 30 fps, with only the picture smoother.

How much does shader preparation help?
In the project's test route, shaders compiled during play fell from 277 to 33 with the optional setup step enabled. It is off by default and takes about 8 to 10 minutes on a Mac.

Why did 40 fps judder?
40 does not divide 30 evenly, so the old timing alternated between half a step and a full step. Each frame is now shown three quarters of a step apart.

Do I need the game disc?
Yes. The release contains no game files, code or keys. You supply a disc dump with its key, a Cemu .wua archive, or an extracted game folder, and the installer builds the game from it.

Which platforms have builds?
Windows on x86-64 and ARM64, macOS 14 or newer on Apple Silicon, Linux with glibc 2.35 or newer including an AppImage, and Android 13 or newer on arm64 with Vulkan 1.3.

Bottom Line

The Wind Waker HD recompilation is at the stage where the interesting work is no longer "can it run" but "does it behave". This development build is a concentrated dose of that. Frame interpolation stops changing the game, so 240 fps is a smoother picture of the same 30 fps simulation rather than a slightly different one. The 40 fps mode stops alternating between half-step and full-step timing, which is the difference between a correct average and an even cadence. An optional setup step compiles most of the game's shaders ahead of time, at the price of eight to ten minutes on a Mac, and a new setting lets a player choose between waiting for a shader and accepting a frame or two without an object. The sun's visibility check no longer depends on when the GPU finishes, which is a determinism fix with a small and honestly stated timing cost.

Around that core are the fixes that make a port feel native: starting directly from any folder, a data-dir option, passing the editor flag through the launcher on three platforms, a clear message when the mod compiler is missing, and Android heat warnings that stop believing a single sensor. The mod catalogue grows in the direction the world editor needs. It is a development build, so treat it as a preview and report the commit if something breaks. If the next release carries these changes, it will be a much better one than 0.4.0 on the two things that matter most in an emulated game: timing and stutter.

Sources

Zelda Wind Waker HD Recomp repository README and releases, ZeldaWWHDRecomp/ZeldaWWHDRecomp, accessed 22 October 2026
Development build release notes, devel at a7ea411, published 22 October 2026
Release notes for v0.4.0, published 21 October 2026
GitHub repository metadata for ZeldaWWHDRecomp/ZeldaWWHDRecomp, accessed 22 October 2026