There is a floor texture bug in Dodongo's Cavern. Floor texture glitch in Dodongo's Cavern. #1717
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
1 participant
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#1717
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hookshot version
2.0.13
What kind of problem
Graphics (missing, black or wrong-coloured things, lighting, flicker)
What happened
Where in the game
Floor texture error on the left side of 1F in Dodongo’s Cavern.
How often
Every time
Graphics card and driver version
RTX 5070 Ti Laptop GPU 621.14
CPU, RAM and operating system
i7 14950HX 32G Win11
Changes from the defaults
No response
Other software hooked into the game
No, nothing hooked in
hookshot_log.txt
hookshot_log.txt
Screenshots or video
No response
Before you send it
The issue goes away after re-entering the game.
I also encountered the same issue on 2F.
hookshot_log.txt
Confirming this on v2.0.14, so the latest release does not fix it.
Unlike the original report I don't get it at one fixed spot — the floor breaks at various points through Dodongo's Cavern as I progress, rather than reliably on the left side of 1F. Re-entering the room clears it each time, same as described above.
What it looks like on my end: the ground plane renders as a repeating dark red-brown diagonal weave / wood-grain pattern instead of the cavern rock floor. The grey stone slabs sitting on top of it still render correctly, so it reads like the wrong texture being bound to that one surface rather than general corruption.
System
Possibly useful for narrowing it down: the original reporter is on an RTX 5070 Ti Laptop on v2.0.13, and I'm on a desktop Ada card on v2.0.14 — but we are both on driver 621.14. So this does not look specific to Blackwell, to laptop GPUs, or to 2.0.13.
No texture or decode errors appear in my log when it happens — it seems to go wrong silently. Happy to attach
hookshot_log.txtif that would help.A similar report from Discord on v2.0.14: an incorrect floor texture spreading over a room. To narrow this down: what's your Frame rate cap (60 or higher), and what's the last version where this floor looked right? v2.0.14 changed no rendering of the game itself (only the old menu's HDR colours, the FPS counter size and bracket paths), so the version it started with helps.
Frame rate cap: 60. But I should correct something in my comment above — I said frame generation was off, which is only true of Hookshot's own setting. I have NVIDIA Smooth Motion enabled at the driver level, interpolating to ~120 fps. So there is driver-side frame generation in play, which given your question may be the relevant part.
Last version where it looked right: I have no data point, unfortunately. I only reached Dodongo's Cavern after updating to v2.0.14 — I never visited that room on v2.0.13 — so I can't tell you whether it was already broken there. I first installed on 2026-11-08 on v2.0.13, and those two builds are the only ones I have ever run.
New data since my last comment: after saving and restarting the game, I have not been able to reproduce it — the floor has rendered correctly on my run through the cavern since. That's a stronger fix than the room re-entry described earlier, and it suggests something that accumulates over a session rather than anything tied to a specific room or asset.
In version 2.0.14, after playing for a while, terrain texture errors also appeared in Hyrule Field (the average frame rate in Hyrule Field is 49 FPS without frame generation).
hookshot_log.txt
One more from Discord: the floor in the Royal Family's Tomb glitches, with a red seam (RX 9070 XT). Same family as the floors here and in #1006.
I'm taking this one, as part of the worklist row for ground textures that garble over play time and come back after a restart.
What the logs show: the logs here, in #2276 and in #2297 all have the same line from the texture cache:
vk: upload over a drawn image: ... 260x260x1 x1 NVN 0xd ... finalized. That is a CPU upload written over a 260x260 terrain tile the GPU drew and the game finalized, so the tile ends up holding stale memory instead of what was drawn. It shows up on an RX 7900 XT with 20 GB that was nowhere near its VRAM limit, so this isn't only VRAM pressure.Next: reproducing it on Linux with an RTX 4070 Ti, in Dodongo's Cavern with per-eviction logging (#1879) and
RX_VK_LOG_REMADE=1, then fixing that upload path. I'll post results here.🤖 Generated with Claude Code
@Joey-Magnus I reproduce this within about 10 minutes (RTX 3090, Linux, v2.1.0, Fire Temple) and recorded a session with extra logging on the 260x260 tiles. Sharing it in case it saves you time; the fix is yours unless you'd rather I open a PR.
What the recording shows
upload over a drawn image ... 260x260x1 x1 NVN 0xd ... finalizedappears twice in that session, both uploading zeros. I think it is the same cause through another path, so fixing only that upload would leave the 61 tiles above.What I tried
A test build that writes a GPU-drawn tile's texels into guest memory two frames after it is drawn. In an 80-minute session the floor never broke. Of 871 normal tiles the game made from memory, 854 were byte-identical to a tile written back earlier. The other 17 were zero, all copies of one tile that was finalized the frame after it was drawn, which my rule skipped.
I can share the patch (against v2.1.0, test quality, its rule is too wide), post log excerpts, or run a branch of yours on this setup. A teleport tour does not reproduce it, since a map change resets the tile pool; it takes several minutes of play inside one map.
Thanks for the report. Reports of the same problem are now collected in #2508, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #2508 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.