Hookshot: Severe overexposure / bloom issue

kappageorge commented

2026-11-07 05:31:30 +00:00

(Migrated from github.com)

Hookshot: Severe overexposure / bloom issue in Kokiri Forest

Hookshot is running at a stable 60 FPS on my Ryzen 7800X3D and RTX 4080 Super, which is a significant improvement over the approximately 36 FPS I was getting through Lichii.

However, Hookshot has a severe lighting issue in Kokiri Forest. The entire scene appears overexposed, with excessive bloom, washed-out colours and blown-out highlights.

I've attached comparison screenshots showing the same area in Hookshot and Frizti's Lichii build. Lichii renders the lighting correctly.

It looks potentially related to bloom compositing, exposure, tone mapping or post-processing shader translation.

Would it be possible to investigate the relevant rendering differences between Hookshot and Frizti's Lichii build?

**Hookshot: Severe overexposure / bloom issue in Kokiri Forest** Hookshot is running at a stable 60 FPS on my Ryzen 7800X3D and RTX 4080 Super, which is a significant improvement over the approximately 36 FPS I was getting through Lichii. However, Hookshot has a severe lighting issue in Kokiri Forest. The entire scene appears overexposed, with excessive bloom, washed-out colours and blown-out highlights. I've attached comparison screenshots showing the same area in Hookshot and Frizti's Lichii build. Lichii renders the lighting correctly. It looks potentially related to bloom compositing, exposure, tone mapping or post-processing shader translation. Would it be possible to investigate the relevant rendering differences between Hookshot and Frizti's Lichii build?

sansyundertale commented

2026-11-07 05:46:10 +00:00

(Migrated from github.com)

This is also occurring on my AMD card, 9060xt 16gb ... Everything looks very blown out/extremely bright and shadowed areas look very dark.

litechenacc commented

2026-11-07 15:11:03 +00:00

(Migrated from github.com)

### On an RX 9060 XT the picture does not just look overexposed — at some sun angles it goes completely white, and the renderer keeps working

I am on the same card as @sansyundertale (RX 9060 XT 16 GB), so this may be the same thing they described, with numbers attached.

Setup: HookshotBuilder build of 2026-11-07 around 20:50 local (hookshot.exe timestamp 20:58, so it predates #166), game language zh-Hant, Insert menu: frame generation 3x, frame pacing on, resolution Auto, upscaling Catmull-Rom, sharpness 60.

What happens: walking outside Hyrule Castle, at a number of angles where the sun hits the scene, the whole picture blows out to white and stays white for as long as the camera holds that angle; turning away brings the scene back. It is not a one-frame flash.

Measured, from the window itself (screenshot of the game window every 1.5 s, brightness = mean of an 8×8 luma grid of the client area):

frames	mean luma	note
2	160.6, 128.5	scene visible
37 consecutive	245.9, max 255	pure white, present ~39,4xx to 44,2xx

The renderer is fine while it is white — same frames from hookshot_log.txt:

[hos Presentation Thread] vk: 44280 presents, 35.6 fps; a frame: 895 draws (0 skipped), 112 dispatches,
106 passes, 144 barriers, 6 submits, ... GPU-bound wait 0.0 ms; 4855 pipelines (63198 ms), 81 programs
(10 failed), 1315 textures (3817 MB)
[hos Presentation Thread] vk: GPU time 20.6 ms a frame

895 draws, 112 dispatches and 106 passes are still being recorded and replayed at 35 fps with a sane GPU time: no lost device, no dropped draws.

What the log has and has not got. There is no white frame: line in it, and that is expected: the detector in vk_replay.cpp only runs inside framelog_collect(), and framelog_on() needs RX_VK_FRAMELOG to be set and a <path>.go file to exist, so it never ran, and exposure_log_dump() / probe_dump_all() were never collected. The instrumentation that did run in a later session was RX_VK_EXPOSURE_LOG=2, and its result is in the next comment: the final pass's exposure is 1.0 at every present across the white stretch.

Also on this card, from the same logs: matrix multiplies in software (the cooperative matrices lack 16x8x16 f16) (see #52) and 10 programs left out on this card (the network passes).

Frames and logs: https://github.com/litechenacc/hookshot-white-frame-evidence — the renderer's own 1280×720 dumps (renderer_*.png, present counter in the name), window captures (player_*.png), hookshot_log.txt, frames.csv and hookshot_options.ini. The session that contains the white stretch and the crash is in this gist: https://gist.github.com/litechenacc/1bdfef1b8fff37bf08923ebb2c2152ff

### On an RX 9060 XT the picture does not just look overexposed — at some sun angles it goes completely white, and the renderer keeps working I am on the same card as @sansyundertale (RX 9060 XT 16 GB), so this may be the same thing they described, with numbers attached. **Setup:** HookshotBuilder build of 2026-11-07 around 20:50 local (`hookshot.exe` timestamp 20:58, so it predates #166), game language `zh-Hant`, Insert menu: frame generation 3x, frame pacing on, resolution Auto, upscaling Catmull-Rom, sharpness 60. **What happens:** walking outside Hyrule Castle, at a number of angles where the sun hits the scene, the whole picture blows out to white and *stays* white for as long as the camera holds that angle; turning away brings the scene back. It is not a one-frame flash. **Measured, from the window itself** (screenshot of the game window every 1.5 s, brightness = mean of an 8×8 luma grid of the client area): | frames | mean luma | note | |---|---|---| | 2 | 160.6, 128.5 | scene visible | | **37 consecutive** | **245.9, max 255** | pure white, present ~39,4xx to 44,2xx | **The renderer is fine while it is white** — same frames from `hookshot_log.txt`: ``` [hos Presentation Thread] vk: 44280 presents, 35.6 fps; a frame: 895 draws (0 skipped), 112 dispatches, 106 passes, 144 barriers, 6 submits, ... GPU-bound wait 0.0 ms; 4855 pipelines (63198 ms), 81 programs (10 failed), 1315 textures (3817 MB) [hos Presentation Thread] vk: GPU time 20.6 ms a frame ``` 895 draws, 112 dispatches and 106 passes are still being recorded and replayed at 35 fps with a sane GPU time: no lost device, no dropped draws. **What the log has and has not got.** There is no `white frame:` line in it, and that is expected: the detector in `vk_replay.cpp` only runs inside `framelog_collect()`, and `framelog_on()` needs `RX_VK_FRAMELOG` to be set *and* a `<path>.go` file to exist, so it never ran, and `exposure_log_dump()` / `probe_dump_all()` were never collected. The instrumentation that did run in a later session was `RX_VK_EXPOSURE_LOG=2`, and its result is in the next comment: the final pass's exposure is 1.0 at every present across the white stretch. **Also on this card, from the same logs:** `matrix multiplies in software (the cooperative matrices lack 16x8x16 f16)` (see #52) and 10 programs `left out on this card` (the network passes). **Frames and logs:** https://github.com/litechenacc/hookshot-white-frame-evidence — the renderer's own 1280×720 dumps (`renderer_*.png`, present counter in the name), window captures (`player_*.png`), `hookshot_log.txt`, `frames.csv` and `hookshot_options.ini`. The session that contains the white stretch and the crash is in this gist: https://gist.github.com/litechenacc/1bdfef1b8fff37bf08923ebb2c2152ff

litechenacc commented

2026-11-07 15:27:39 +00:00

(Migrated from github.com)

Two more pieces of evidence, both from the same machine.

1. The renderer's own frames are in a public repo (no git needed): https://github.com/litechenacc/hookshot-white-frame-evidence

renderer_*.png are written by Hookshot itself (RX_VK_SHOTS), 1280×720, with the present counter in the name; player_*.png are captures of the window as it was on the monitor.
white at presents 1500, 2100 and 2700 (mean luma 249.6 / 251.6 / 251.6), normal at 4200 (64.7), part way at 6600 (221.6). It reproduces within a minute of a fresh start, so it is not something that builds up over a session.

2. RX_VK_EXPOSURE_LOG=2 was on for that run, and the number does not move.

2,621 samples between present 1325 and 6823 — the white stretch (1500–2700) included — are all vk: exposure <present> 1. The word at c3+0x38 of the final pass's fragment stage (program 73320e720a317817) is 1.0 before, during and after the blow-out.

3. Outdoors only. Indoors the picture is normal everywhere I have walked; the blow-out happens outside, with the sun on the scene, and it holds for as long as the camera stays at that angle. Indoors was normal in the same session, same build, minutes apart.

The session log, the per-capture brightness table and hookshot_options.ini are in the repo beside the frames.

Two more pieces of evidence, both from the same machine. **1. The renderer's own frames are in a public repo** (no git needed): https://github.com/litechenacc/hookshot-white-frame-evidence - `renderer_*.png` are written by Hookshot itself (`RX_VK_SHOTS`), 1280×720, with the present counter in the name; `player_*.png` are captures of the window as it was on the monitor. - white at presents 1500, 2100 and 2700 (mean luma 249.6 / 251.6 / 251.6), normal at 4200 (64.7), part way at 6600 (221.6). It reproduces within a minute of a fresh start, so it is not something that builds up over a session. **2. `RX_VK_EXPOSURE_LOG=2` was on for that run, and the number does not move.** 2,621 samples between present 1325 and 6823 — the white stretch (1500–2700) included — are **all** `vk: exposure <present> 1`. The word at `c3+0x38` of the final pass's fragment stage (program `73320e720a317817`) is 1.0 before, during and after the blow-out. **3. Outdoors only.** Indoors the picture is normal everywhere I have walked; the blow-out happens outside, with the sun on the scene, and it holds for as long as the camera stays at that angle. Indoors was normal in the same session, same build, minutes apart. The session log, the per-capture brightness table and `hookshot_options.ini` are in the repo beside the frames.

NotRexed commented

2026-11-07 19:41:26 +00:00

(Migrated from github.com)

Linked here from closed duplicates: #226 (RTX 4090; a Linux RTX 3080 Laptop log shows storage buffers not bound, reading zeros, in 755a777ada52677d (28x) and 78ccf14779ec3efb, 7650519f88e59b19, 102f5b0abb0f1e63, a54f19e927d8faef), #269 (Hyrule Town / Goron City NPCs dark, lit only by Navi), #212, #196, #81, #59, #51.

hiKareeem commented

2026-11-07 19:52:15 +00:00

(Migrated from github.com)

Migrating from closed thread here. Same here on NVIDIA, newest release.

Release: movie-sync, built today with Hookshot Builder; game build e0f3ccfa, en-US
GPU: RTX 3080 Ti, driver 621.01
CPU / RAM / OS: Ryzen 7 7800X3D, 64 GB, Windows 11 Pro (26200)
Settings: defaults apart from fullscreen and the FPS counter; no hookshot_env.txt; nothing hooked into the game (no ReShade or shader-cache tools)
Where: Goron City
Link is lit correctly since the lighting releases (on text-hotfix he was the dark one), but NPCs still come out dark. The only shading they get is from Navi's light: in the second screenshot Darunia's face is lit and the rest of the body is nearly black. This looks like what #34 described before it was closed as fixed in lighting-fix.

Log from the same run attached, and screenshots below.

hookshot_log.txt

Migrating from closed thread here. Same here on NVIDIA, newest release. Release: movie-sync, built today with Hookshot Builder; game build e0f3ccfa, en-US GPU: RTX 3080 Ti, driver 621.01 CPU / RAM / OS: Ryzen 7 7800X3D, 64 GB, Windows 11 Pro (26200) Settings: defaults apart from fullscreen and the FPS counter; no hookshot_env.txt; nothing hooked into the game (no ReShade or shader-cache tools) Where: Goron City Link is lit correctly since the lighting releases (on text-hotfix he was the dark one), but NPCs still come out dark. The only shading they get is from Navi's light: in the second screenshot Darunia's face is lit and the rest of the body is nearly black. This looks like what #34 described before it was closed as fixed in lighting-fix. Log from the same run attached, and screenshots below. [hookshot_log.txt](https://github.com/user-attachments/files/34527643/hookshot_log.txt) <img width="1322" height="1306" alt="Image" src="https://github.com/user-attachments/assets/dac3e56c-1c2e-4b3e-b9cc-107b3237dd05" /> <img width="661" height="1735" alt="Image" src="https://github.com/user-attachments/assets/a59c84d9-bb1a-47e2-a6fd-bb75b6303ebf" />

Wpaif commented

2026-11-08 04:25:58 +00:00

(Migrated from github.com)

Same washed-out / blown-out look on Linux, NVIDIA, at the Great Deku Tree in Kokiri Forest (inside a dialogue).

Setup: GTX 1650 Max-Q (driver 615.78.08), Linux; Hookshot built from main (2026-11-07), pt-BR game; default quality apart from the Low preset.

The log has the "storage buffer NOT bound" warning you pointed at in #226, but with different programs. Each appears 10 times, all at the same spot:

vk: storage buffer NOT bound (reads zeros): program 68642bb810ee3e7c stage 7 c5+0x60 addr 0xa0000d10a size 0x3f99999a
vk: storage buffer NOT bound (reads zeros): program 6b4dea601798c255 stage 7 c5+0x60 addr 0xa0000d10a size 0x3f99999a
vk: storage buffer NOT bound (reads zeros): program 739acd678ae08655 stage 7 c5+0x60 addr 0xa0000d10a size 0x3f99999a
vk: storage buffer NOT bound (reads zeros): program d905f52b7517c681 stage 7 c5+0x60 addr 0xa0000d10a size 0x3f99999a

Maybe a clue: the "size" 0x3f99999a is the float 1.2f, and the address isn't 4-byte aligned. So c5+0x60 may be holding ordinary uniform data rather than a buffer descriptor (address + size) in these programs, and the binding is read from the wrong offset.

Same washed-out / blown-out look on Linux, NVIDIA, at the Great Deku Tree in Kokiri Forest (inside a dialogue). **Setup:** GTX 1650 Max-Q (driver 615.78.08), Linux; Hookshot built from main (2026-11-07), pt-BR game; default quality apart from the Low preset. The log has the "storage buffer NOT bound" warning you pointed at in #226, but with different programs. Each appears 10 times, all at the same spot: ``` vk: storage buffer NOT bound (reads zeros): program 68642bb810ee3e7c stage 7 c5+0x60 addr 0xa0000d10a size 0x3f99999a vk: storage buffer NOT bound (reads zeros): program 6b4dea601798c255 stage 7 c5+0x60 addr 0xa0000d10a size 0x3f99999a vk: storage buffer NOT bound (reads zeros): program 739acd678ae08655 stage 7 c5+0x60 addr 0xa0000d10a size 0x3f99999a vk: storage buffer NOT bound (reads zeros): program d905f52b7517c681 stage 7 c5+0x60 addr 0xa0000d10a size 0x3f99999a ``` Maybe a clue: the "size" 0x3f99999a is the float 1.2f, and the address isn't 4-byte aligned. So c5+0x60 may be holding ordinary uniform data rather than a buffer descriptor (address + size) in these programs, and the binding is read from the wrong offset.

imbahzor commented

2026-11-08 05:11:24 +00:00

(Migrated from github.com)

Think I found what's behind the too-dark shadows, at least on NVIDIA.

I'm on an RTX 3060 (Win 11, 16 GB, no-visual-studio release). Everything in shade was basically pitch black for me: cliffs on Death Mountain Trail, Link as a black silhouette, even little stones in full sun were black blobs. Sunlit stuff looked fine, so it's more like the dark tones get crushed than light being missing.

It turns out to be the TAAU network running on the card's cooperative matrices. I tried three things at the same spot:

default (network on native coop matrices): black shadows, sharp, ~28 fps
RX_VK_TAAU_KEYS=fd029a317a9a4b94 (the stand-in): shadows look right, but it's soft since it's just upscaling 1536x864, ~35 fps
RX_VK_MMA_SOFTWARE=1 + RX_VK_TAAU_KEYS=- (network kept, multiplies in software): shadows look right AND it's sharp, ~32 fps

So the network itself is fine; it only goes wrong on the native coop matrix path, even though the layout check in vk_coopmat.cpp passes on my card. My guess is precision with small values (the input is sqrt-encoded and the darkest values are what collapse). It looks like the same kind of thing as the movie upscaler losing its blue channel, which you already noted in vk_shader.cpp.

If anyone on NVIDIA wants a workaround for now, put this in hookshot_env.txt:

RX_VK_TAAU_KEYS=-
RX_VK_MMA_SOFTWARE=1

Costs a few fps for me. One side effect: the movie networks get left out in software mode, so the intro is just linearly upscaled (but it plays smoothly instead of at 2 fps, so not a bad trade).

Can post screenshots of all three if that helps.

Think I found what's behind the too-dark shadows, at least on NVIDIA. I'm on an RTX 3060 (Win 11, 16 GB, no-visual-studio release). Everything in shade was basically pitch black for me: cliffs on Death Mountain Trail, Link as a black silhouette, even little stones in full sun were black blobs. Sunlit stuff looked fine, so it's more like the dark tones get crushed than light being missing. It turns out to be the TAAU network running on the card's cooperative matrices. I tried three things at the same spot: - default (network on native coop matrices): black shadows, sharp, ~28 fps - `RX_VK_TAAU_KEYS=fd029a317a9a4b94` (the stand-in): shadows look right, but it's soft since it's just upscaling 1536x864, ~35 fps - `RX_VK_MMA_SOFTWARE=1` + `RX_VK_TAAU_KEYS=-` (network kept, multiplies in software): shadows look right AND it's sharp, ~32 fps So the network itself is fine; it only goes wrong on the native coop matrix path, even though the layout check in vk_coopmat.cpp passes on my card. My guess is precision with small values (the input is sqrt-encoded and the darkest values are what collapse). It looks like the same kind of thing as the movie upscaler losing its blue channel, which you already noted in vk_shader.cpp. If anyone on NVIDIA wants a workaround for now, put this in `hookshot_env.txt`: ``` RX_VK_TAAU_KEYS=- RX_VK_MMA_SOFTWARE=1 ``` Costs a few fps for me. One side effect: the movie networks get left out in software mode, so the intro is just linearly upscaled (but it plays smoothly instead of at 2 fps, so not a bad trade). Can post screenshots of all three if that helps.

NotRexed commented

2026-11-09 05:43:18 +00:00

(Migrated from github.com)

Tracked in #1004, follow there. That issue collects every report of lighting problems (overexposure, bloom, crushed shadows, black faces), and this one is linked from it with its GPU, version and log details. v2.0.5 fixed dark/black faces and v2.0.6 fixes the bright plant stems, so a retest on v2.0.6 is useful. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your hookshot_log.txt.

Tracked in #1004, follow there. That issue collects every report of lighting problems (overexposure, bloom, crushed shadows, black faces), and this one is linked from it with its GPU, version and log details. v2.0.5 fixed dark/black faces and v2.0.6 fixes the bright plant stems, so a retest on v2.0.6 is useful. If it still happens on v2.0.6 (https://github.com/NotRexed/Hookshot/releases/tag/v2.0.6; Update next to Play in the launcher), please add a comment there with your `hookshot_log.txt`.

github-sync referenced this issue

2026-11-12 06:25:41 +00:00

weird darkened bars on the left and right and brightness flickiring after newest update #145

github-sync referenced this issue

2026-11-12 06:25:52 +00:00

docs(triage): complete part of Phase 0 of the roadmap #522

Rows
Columns

Hookshot: Severe overexposure / bloom issue #36