You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Breath of the Wild launches, and I can hear game audio, but the video is blank or badly corrupted with green and red areas. Distorted hearts appear near the top of the screen. The corruption affects the whole game, not just one scene or frame.
Quitting and relaunching, rebuilding, and resetting shader data did not fix it.
Expected behavior
The game should display normally while it runs.
System and game
Mac: MacBook Pro, Apple M5
macOS version: not recorded
Project: seedds/nxnative
Game: Breath of the Wild, US base v0 with update 1.9.0
Title ID: 01007EF00011E000
Profile package: v1114112
Graphics diagnostics collected
The log reports shader route B, a 19,592-entry shader map, and pipeline prewarm completion (613 shaders, 730 render pipelines, 8 compute pipelines). It reported zero shader keys missing from the map.
A key dump found fragment shader 06d68917ae28a29d (ps_gsys.bin#178). Its generated Metal shader averages four texture samples. The logged draws showed real texture and sampler bindings: one sampled a 1280×720 texture and rendered to 640×360; another sampled 1050×225 and rendered to 262×56. I do not know whether this shader is related to the full-screen corruption.
A later raw-texture capture reported ser=12718 not in the serial table; that serial came from an earlier launch, so the raw texture was not captured.
Thanks for the diagnostic summary. Could you attach the complete runtime log from startup through the corrupted picture, together with the nxnative source commit/build date, macOS version and any custom environment settings?
For the packaged Mac app, the log is ~/Library/Logs/nxnative/01007EF00011E000.log (the previous run is 01007EF00011E000.prev.log). For a terminal launch, please attach the captured host output.
Please also include the shader-build log, <title ID>_build/logs/dmsh_build.log, from the build used for that run. This will let us compare the shader-chain/toolchain information with the runtime rather than infer it from individual shader excerpts.
Thanks for the diagnostic summary. Could you attach the complete runtime log from startup through the corrupted picture, together with the nxnative source commit/build date, macOS version and any custom environment settings?
For the packaged Mac app, the log is ~/Library/Logs/nxnative/01007EF00011E000.log (the previous run is 01007EF00011E000.prev.log). For a terminal launch, please attach the captured host output.
Please also include the shader-build log, <title ID>_build/logs/dmsh_build.log, from the build used for that run. This will let us compare the shader-chain/toolchain information with the runtime rather than infer it from individual shader excerpts.
Thanks for the logs, both of you. They point to the build Mac's toolchain rather than the game or the device:
@lnvdcomputer, your shader build says built with this Mac's compilers, not the ones the shaders were tested with: Metal 32023.883 (Xcode 26, on macOS 26.3), while the shader chain is tested with Metal 32023.921 (Xcode 27.1, see dm/gfx/tools/dmsh_chain.lock). Your app is also from Oct 25, about 100 commits and three shader chain changes ago.
@76552004, your log doesn't say which Mac and Xcode built the IPA. Do you know? For iPhones what counts is the Mac that built the app, not the phone.
Could you try this?
Update to macOS 26.6 or later and install Xcode 27.1 (it needs 26.6), then xcodebuild -downloadComponent MetalToolchain.
Pull the current main and rebuild (shaders included).
If the picture is still broken, attach the new shader-build.log and the runtime log.
@seedds, a note on why this can affect anyone building on macOS 26: Homebrew only has a spirv-cross bottle for macOS 27, so on 26 it builds from source and never matches the lock's fingerprint, and Xcode 26's Metal compiler isn't the tested one. dmsh_build.py warns once and builds on, and the README names no Xcode version. I'll put up two small PRs for this:
state the tested toolchain in the README requirements (macOS 26.6+, Xcode 27.1 / Metal 32023.921), and make the shader build stop on a different Metal compiler unless overridden, like --allow-shader-regressions;
pin spirv-cross with the chain the way the translator is (one known build instead of Homebrew's), so every Mac produces the same MSL.
I'll link them here when they're up. If the rebuild fixes it here, that confirms the cause.
Require the Metal compiler the shaders were tested with #333 makes the tested Metal compiler a requirement. The README now says the build Mac needs macOS 26.6+ with Xcode 27.1, plus xcodebuild -downloadComponent MetalToolchain. If the Metal compiler doesn't match dmsh_chain.lock, the NSP script now stops before the shader steps with a clear message, instead of printing a one-line note and building on. --allow-other-metal (DM_ALLOW_OTHER_METAL=1) still builds anyway. This isn't a chain bump.
Pin spirv-cross with the translation chain #337 pins spirv-cross with the chain, the same way the translator is: a committed universal build of SPIRV-Cross vulkan-sdk-1.4.363.0, made by a reproducible build script, so every Mac matches the lock fingerprint. The Homebrew spirv-cross is no longer needed. Its MSL is byte-identical to the tested build's: 15,012 SPIR-V modules from a full Breath of the Wild build, plus Hades's Vulkan shaders, with 0 differences. This one is a chain bump.
Activity
seedds commentedon Oct 26, 2026
Thanks for the diagnostic summary. Could you attach the complete runtime log from startup through the corrupted picture, together with the nxnative source commit/build date, macOS version and any custom environment settings?
For the packaged Mac app, the log is
~/Library/Logs/nxnative/01007EF00011E000.log(the previous run is01007EF00011E000.prev.log). For a terminal launch, please attach the captured host output.Please also include the shader-build log,
<title ID>_build/logs/dmsh_build.log, from the build used for that run. This will let us compare the shader-chain/toolchain information with the runtime rather than infer it from individual shader excerpts.lnvdcomputer commentedon Oct 26, 2026
here
nxnative-report-20261026-080553.zip
v0lumehi commentedon Oct 26, 2026
I can also have a look
76552004 commentedon Oct 26, 2026
I'm experiencing exactly the same issue on my iPhone 17 when running The Legend of Zelda: Breath of the Wild with nxnative.
The screen is heavily corrupted, with the same red/green graphical artifacts and distorted UI shown in the screenshots above.
I haven't found a working fix yet. It seems this issue also affects iPhone devices, not just Macs.
Please let me know if any additional logs or device information would help with debugging. Thanks!
log.txt
v0lumehi commentedon Oct 26, 2026
Thanks for the logs, both of you. They point to the build Mac's toolchain rather than the game or the device:
built with this Mac's compilers, not the ones the shaders were tested with: Metal 32023.883 (Xcode 26, on macOS 26.3), while the shader chain is tested with Metal 32023.921 (Xcode 27.1, seedm/gfx/tools/dmsh_chain.lock). Your app is also from Oct 25, about 100 commits and three shader chain changes ago.Could you try this?
xcodebuild -downloadComponent MetalToolchain.mainand rebuild (shaders included).shader-build.logand the runtime log.@seedds, a note on why this can affect anyone building on macOS 26: Homebrew only has a
spirv-crossbottle for macOS 27, so on 26 it builds from source and never matches the lock's fingerprint, and Xcode 26's Metal compiler isn't the tested one.dmsh_build.pywarns once and builds on, and the README names no Xcode version. I'll put up two small PRs for this:--allow-shader-regressions;spirv-crosswith the chain the way the translator is (one known build instead of Homebrew's), so every Mac produces the same MSL.I'll link them here when they're up. If the rebuild fixes it here, that confirms the cause.
v0lumehi commentedon Oct 26, 2026
Two small PRs for this:
xcodebuild -downloadComponent MetalToolchain. If the Metal compiler doesn't matchdmsh_chain.lock, the NSP script now stops before the shader steps with a clear message, instead of printing a one-line note and building on.--allow-other-metal(DM_ALLOW_OTHER_METAL=1) still builds anyway. This isn't a chain bump.Happy to adjust either one!
Require the Metal compiler the shaders were tested with
Pin spirv-cross with the translation chain
Pin shader tools and isolate Metal libraries by compiler
Issue forms, a pull request template and CONTRIBUTING.md (#306, #388)
Pin shader tools and isolate Metal libraries by compiler
Issue forms, a pull request template and CONTRIBUTING.md (seedds#306, s…