Hyrule Field lighting switches between the dawn/day lighting and a dark night lighting for seconds at a time (reproducible, RTX 5080) #1011

Closed

opened 2026-11-09 05:48:42 +00:00 by KrysGG · 2 comments

KrysGG commented

2026-11-09 05:48:42 +00:00

(Migrated from github.com)

Hookshot version

Source build of main 32df58e (v2.0.5-32) with #922, #761 and #850 merged locally (also seen before them). First log line: hookshot v2.0.5-32-gd2a9123.

What kind of problem

Graphics (missing, black or wrong-coloured things, lighting, flicker)

What happened

quarter of a second an orange haze, then a dark blue night lighting that stays, and later back. The camera and Link's position do not change across the switch (screenshot: four frames ~0.25 s apart). Not one-frame flashes like #570/#382: each state holds for seconds. Lichii at the same spot with the same save does not do it.

It reproduces exactly with scripted input from the same save (headless, HOS_INPUT_LIVE: walk 6 s, turn right, walk 6 s, turn left, walk 6 s): the mean picture luma climbs as the light rises (38 -> ~80) and then drops to ~38 at the same moment of the walk in every run.

Ruled out with the same scripted walk (each one still switches to the dark lighting at the same moment):

#816 applied, and #816's EDEN_F32_ADD_TRACK=0
EDEN_NX2_GM_LEGACY=0 (the port on)
RX_VK_OCC_FIXED=100000000 and RX_VK_OCC_FIXED=-1
RX_VK_NO_EVICT=1 (no texture retired in that run)
RX_VK_COMPUTE_WAIT=1
RX_VK_WAIT_GPU=1: one run without the switch, a second run with it, so at most partly
RX_VK_NO_READBACK_WAIT=1 (more jitter, as the old exposure flicker, but the same switch) and RX_VK_READBACK_NO_CATCHUP=1
Since the switch comes at the same moment of the walk in every run whatever the switches, it seems driven by the game's own
state (time of day?): its change of lighting comes out wrong here.
With a pointer-diagnostic counter, none of the 32,719 programs translated at start has a float atomic left to the run-time search.

What differs between a bright frame and a dark one (RX_VK_DRAW_STATS just before and just after the switch):

compute 8686eb7324f84d66 (grid 3 1 1) runs only in the bright frame; compute e9f65cf0e8f4b953 is dispatched 6 times in the bright frame and 4 times in the dark one
68 small draw programs (4-16 vertices, all clipped out: occlusion/visibility test boxes) run only in the bright frame

So it looks as if the game decides on the CPU to stop its sun/lighting updates, maybe from a GPU result it reads back.

Where in the game

Hyrule Field near the path towards the ranch, around dawn (game time). Same save every run.

How often

Every time

Graphics card and driver version

NVIDIA RTX 5080, driver 621.14

CPU, RAM and operating system

Intel i9-13900K, 32 GB DDR5, Windows 11 Pro

Changes from the defaults

None in the scripted runs (headless). While playing: DLSS (#850) on or off, Hookshot frame generation on; it happens either way.

Other software hooked into the game

No, nothing hooked in

hookshot_log.txt

hookshot_log-lighting-snap.txt

Screenshots or video

Before you send it

I'm on the newest release, or the problem is still there on it.
I searched the open issues for this problem.
I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

### Hookshot version Source build of main 32df58e (v2.0.5-32) with #922, #761 and #850 merged locally (also seen before them). First log line: `hookshot v2.0.5-32-gd2a9123`. ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened quarter of a second an orange haze, then a dark blue night lighting that stays, and later back. The camera and Link's position do not change across the switch (screenshot: four frames ~0.25 s apart). Not one-frame flashes like #570/#382: each state holds for seconds. Lichii at the same spot with the same save does not do it. It reproduces exactly with scripted input from the same save (headless, `HOS_INPUT_LIVE`: walk 6 s, turn right, walk 6 s, turn left, walk 6 s): the mean picture luma climbs as the light rises (38 -> ~80) and then drops to ~38 at the same moment of the walk in every run. Ruled out with the same scripted walk (each one still switches to the dark lighting at the same moment): - #816 applied, and #816's `EDEN_F32_ADD_TRACK=0` - `EDEN_NX2_GM_LEGACY=0` (the port on) - `RX_VK_OCC_FIXED=100000000` and `RX_VK_OCC_FIXED=-1` - `RX_VK_NO_EVICT=1` (no texture retired in that run) - `RX_VK_COMPUTE_WAIT=1` - `RX_VK_WAIT_GPU=1`: one run without the switch, a second run with it, so at most partly - `RX_VK_NO_READBACK_WAIT=1` (more jitter, as the old exposure flicker, but the same switch) and `RX_VK_READBACK_NO_CATCHUP=1` - Since the switch comes at the same moment of the walk in every run whatever the switches, it seems driven by the game's own state (time of day?): its change of lighting comes out wrong here. - With a pointer-diagnostic counter, none of the 32,719 programs translated at start has a float atomic left to the run-time search. What differs between a bright frame and a dark one (`RX_VK_DRAW_STATS` just before and just after the switch): - compute `8686eb7324f84d66` (grid 3 1 1) runs only in the bright frame; compute `e9f65cf0e8f4b953` is dispatched 6 times in the bright frame and 4 times in the dark one - 68 small draw programs (4-16 vertices, all clipped out: occlusion/visibility test boxes) run only in the bright frame So it looks as if the game decides on the CPU to stop its sun/lighting updates, maybe from a GPU result it reads back. ### Where in the game Hyrule Field near the path towards the ranch, around dawn (game time). Same save every run. ### How often Every time ### Graphics card and driver version NVIDIA RTX 5080, driver 621.14 ### CPU, RAM and operating system Intel i9-13900K, 32 GB DDR5, Windows 11 Pro ### Changes from the defaults None in the scripted runs (headless). While playing: DLSS (#850) on or off, Hookshot frame generation on; it happens either way. ### Other software hooked into the game No, nothing hooked in ### hookshot_log.txt [hookshot_log-lighting-snap.txt](https://github.com/user-attachments/files/34565241/hookshot_log-lighting-snap.txt) ### Screenshots or video <img width="1280" height="720" alt="Image" src="https://github.com/user-attachments/assets/e9433c20-a876-41bb-813e-1e9e573970b7" /> ### Before you send it - [x] I'm on the newest release, or the problem is still there on it. - [x] I searched the open issues for this problem. - [x] I'm not attaching game files, keys, hookshot.exe, the .bin caches or saves.

NotRexed commented

2026-11-09 09:19:14 +00:00

(Migrated from github.com)

Thanks for the scripted repro and the draw-stat comparison. Linking this to the lighting tracker #1004.

NotRexed commented

2026-11-11 21:22:05 +00:00

(Migrated from github.com)

Thanks for the report. Reports of the same problem are now collected in #1004, which lists this one with your details and links back here, so one fix closes them together and the open list stays readable. Follow #1004 for the fix, and add new details there (or here). If this turns out to be a separate problem it will be reopened.

Commenting is not possible because the repository is archived.