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

nomd346 commented

2026-11-07 13:14:01 +00:00

(Migrated from github.com)

you can see both issues in video

https://github.com/user-attachments/assets/3d479079-43a5-4d3f-8874-fe037689b886

you can see both issues in video https://github.com/user-attachments/assets/3d479079-43a5-4d3f-8874-fe037689b886

👍 3

alawigame-tech commented

2026-11-07 13:28:04 +00:00

(Migrated from github.com)

Same issue as me am going to delete my post you have video

NotRexed commented

2026-11-07 14:01:15 +00:00

(Migrated from github.com)

Thanks for the video. Which release are you on, and which GPU? The newest builds stopped darkening the picture with an old exposure workaround, so the game's own brightness adaptation now shows, but it shouldn't flicker. A hookshot_log.txt would help, and so would knowing whether RX_VK_OOT_EXPOSURE=0.65 in hookshot_env.txt makes the flicker stop.

Thanks for the video. Which release are you on, and which GPU? The newest builds stopped darkening the picture with an old exposure workaround, so the game's own brightness adaptation now shows, but it shouldn't flicker. A `hookshot_log.txt` would help, and so would knowing whether `RX_VK_OOT_EXPOSURE=0.65` in `hookshot_env.txt` makes the flicker stop.

nomd346 commented

2026-11-07 14:03:44 +00:00

(Migrated from github.com)

On the brighter scenes release and a 4060 mobile 8gb

I don't have the device with me right now sorry

On the brighter scenes release and a 4060 mobile 8gb I don't have the device with me right now sorry

ItsKozmic commented

2026-11-07 14:29:00 +00:00

(Migrated from github.com)

I am experiencing this exact issue. 2080 Super 8g with a Ryzen 7 3700x and 32gb or ram

hookshot_log.txt

I am experiencing this exact issue. 2080 Super 8g with a Ryzen 7 3700x and 32gb or ram [hookshot_log.txt](https://github.com/user-attachments/files/34521227/hookshot_log.txt)

nomd346 commented

2026-11-07 14:44:19 +00:00

(Migrated from github.com)

Thanks for the video. Which release are you on, and which GPU? The newest builds stopped darkening the picture with an old exposure workaround, so the game's own brightness adaptation now shows, but it shouldn't flicker. A hookshot_log.txt would help, and so would knowing whether RX_VK_OOT_EXPOSURE=0.65 in hookshot_env.txt makes the flicker stop.

hookshot_log.txt

and i dont have the hookshot_env.txt file i cant find it

> Thanks for the video. Which release are you on, and which GPU? The newest builds stopped darkening the picture with an old exposure workaround, so the game's own brightness adaptation now shows, but it shouldn't flicker. A `hookshot_log.txt` would help, and so would knowing whether `RX_VK_OOT_EXPOSURE=0.65` in `hookshot_env.txt` makes the flicker stop. [hookshot_log.txt](https://github.com/user-attachments/files/34521450/hookshot_log.txt) and i dont have the hookshot_env.txt file i cant find it

litechenacc commented

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

(Migrated from github.com)

Same card here (RX 9060 XT 16 GB, build of 2026-11-07 around 20:50), and I get both halves of this: the brightness pumping from your video, and at some sun angles the picture going fully white and staying white while the camera holds the angle — 37 consecutive captured frames at mean luma 245.9/255, with 895 draws per frame still replayed at 35 fps and 20.6 ms of GPU time, so nothing crashed and no draws were dropped.

Details, the log covering the white stretch and a per-capture brightness table are in #36: #36

Correction to my first attempt at this post, so nobody follows a dead end: in my build hookshot_env.txt is not read yet. hookshot.exe contains no hookshot_env string at all and only knows hookshot_log.txt, language.txt and mouse_sens.txt; the loader is in host/hos_main.c upstream, so it arrived after this build. That is almost certainly also why @nomd346 cannot find the file. On a build without it the switches have to be set in the shell before launching hookshot.exe (a small .cmd that does set RX_VK_...=1 and then starts the exe is enough); on a newer build, creating the file by hand beside the exe is all it takes.

One measurement that may be relevant to the flicker: with RX_VK_EXPOSURE_LOG=2 on, every present in the session that contained a white stretch logged the final pass's exposure (c3+0x38 of fragment stage 73320e720a317817) as exactly 1.0 — 2,621 samples between present 1325 and 6823, before, during and after the blow-out. So on this card the value the final pass receives is not moving while the picture does.

Same card here (RX 9060 XT 16 GB, build of 2026-11-07 around 20:50), and I get both halves of this: the brightness pumping from your video, and at some sun angles the picture going **fully white and staying white** while the camera holds the angle — 37 consecutive captured frames at mean luma 245.9/255, with 895 draws per frame still replayed at 35 fps and 20.6 ms of GPU time, so nothing crashed and no draws were dropped. Details, the log covering the white stretch and a per-capture brightness table are in #36: https://git.magicbean.dev/MagicBeanDev/Hookshot/issues/36 Correction to my first attempt at this post, so nobody follows a dead end: in *my* build `hookshot_env.txt` is not read yet. `hookshot.exe` contains no `hookshot_env` string at all and only knows `hookshot_log.txt`, `language.txt` and `mouse_sens.txt`; the loader is in `host/hos_main.c` upstream, so it arrived after this build. That is almost certainly also why @nomd346 cannot find the file. On a build without it the switches have to be set in the shell before launching `hookshot.exe` (a small `.cmd` that does `set RX_VK_...=1` and then starts the exe is enough); on a newer build, creating the file by hand beside the exe is all it takes. One measurement that may be relevant to the flicker: with `RX_VK_EXPOSURE_LOG=2` on, every present in the session that contained a white stretch logged the final pass's exposure (`c3+0x38` of fragment stage `73320e720a317817`) as exactly **1.0** — 2,621 samples between present 1325 and 6823, before, during and after the blow-out. So on this card the value the final pass receives is not moving while the picture does.

xsm2 commented

2026-11-07 17:37:18 +00:00

(Migrated from github.com)

Same issue with a 9070xt and a 5900x

Jintenzo commented

2026-11-07 22:03:33 +00:00

(Migrated from github.com)

I'm experiencing this on a 4070 Ti SUPER. Capping the fps to 30 seems to get rid of it
(Epilepsy Warning)

https://github.com/user-attachments/assets/d456b883-4708-47c2-9f63-f02b585d8ecd

hookshot_log.txt

I'm experiencing this on a 4070 Ti SUPER. Capping the fps to 30 seems to get rid of it (Epilepsy Warning) https://github.com/user-attachments/assets/d456b883-4708-47c2-9f63-f02b585d8ecd [hookshot_log.txt](https://github.com/user-attachments/files/34529292/hookshot_log.txt)

NotRexed commented

2026-11-07 22:19:53 +00:00

(Migrated from github.com)

Thanks, and the 30 fps observation fits: EvilBoyce's fix for these flashes and the flicker (CPU reads of GPU results now wait for the GPU work that writes them) is in the next release, coming soon. Your log (RTX 4070 Ti SUPER) has no device lost.

mii-kha-El commented

2026-11-07 23:37:31 +00:00

(Migrated from github.com)

hookshot_env.txt
hookshot_log.txt

https://github.com/user-attachments/assets/063ca860-f8dd-4575-9d9a-35e2f9ff6189

RX 6800 (16 GB), driver 32.0.21045.16010, Windows 11, build foliage-linux-updater.
Same brightness flicker in Kokiri Forest. RX_VK_OOT_EXPOSURE=0.65 in hookshot_env.txt does not fix it (~5% dark frames in the attached video, vs ~7% without). RX_VK_NOOPT=1 made it worse (~10%, and lower fps). Also seeing rectangular black blocks over parts of the picture and characters briefly going dark during cutscenes. Log and video attached.

EDIT : Capping at 30 fps with RivaTuner Statistics Server (log confirms a steady 30 fps) removes the flashes completely for me: 0 sudden dark frames in new test, against ~7% flashes/dark frames at 50-60 fps.

[hookshot_env.txt](https://github.com/user-attachments/files/34530510/hookshot_env.txt) [hookshot_log.txt](https://github.com/user-attachments/files/34530511/hookshot_log.txt) https://github.com/user-attachments/assets/063ca860-f8dd-4575-9d9a-35e2f9ff6189 RX 6800 (16 GB), driver 32.0.21045.16010, Windows 11, build foliage-linux-updater. Same brightness flicker in Kokiri Forest. RX_VK_OOT_EXPOSURE=0.65 in hookshot_env.txt does not fix it (~5% dark frames in the attached video, vs ~7% without). RX_VK_NOOPT=1 made it worse (~10%, and lower fps). Also seeing rectangular black blocks over parts of the picture and characters briefly going dark during cutscenes. Log and video attached. EDIT : Capping at 30 fps with RivaTuner Statistics Server (log confirms a steady 30 fps) removes the flashes completely for me: 0 sudden dark frames in new test, against ~7% flashes/dark frames at 50-60 fps.

NotRexed commented

2026-11-08 00:41:07 +00:00

(Migrated from github.com)

#368 adds a GTX 1070 / RX 9060 XT report and an RTX 2080 Super tester who found that building from main (c2c8e86) removes most of the black flashes; #371 adds an RTX 5060 Ti (CachyOS) log and points to PR #415 (flashes 26 to 10 in a 60 s test on an RTX 3090).

#368 adds a GTX 1070 / RX 9060 XT report and an RTX 2080 Super tester who found that building from main (c2c8e86) removes most of the black flashes; #371 adds an RTX 5060 Ti (CachyOS) log and points to PR #415 (flashes 26 to 10 in a 60 s test on an RTX 3090).

cosmus50 commented

2026-11-08 00:54:41 +00:00

(Migrated from github.com)

Same flickering here on Linux with NVIDIA. It flickers heavily and constantly, every time I play, even though it holds 60 fps (GPU time is about 4-5 ms a frame).

Version: release foliage-linux-updater (Linux AppImage)
GPU: NVIDIA GeForce RTX 3060, driver 615.78.08 (the PC also has the Ryzen 5700G's iGPU; the game picks the RTX 3060)
System: Ryzen 7 5700G, 32 GB, Arch Linux (kernel 7.2.14), Hyprland on Wayland
Settings: fullscreen on and Game speed set to Real time, everything else default; no hookshot_env.txt, nothing hooked into the game

From the log: the swapchain is created in immediate present mode, the start says the last start did not finish the driver's part of the shaders: left out, and 105 shader programs fail (as in #388). Log attached.

hookshot_log.txt

Same flickering here on Linux with NVIDIA. It flickers heavily and constantly, every time I play, even though it holds 60 fps (GPU time is about 4-5 ms a frame). - Version: release `foliage-linux-updater` (Linux AppImage) - GPU: NVIDIA GeForce RTX 3060, driver 615.78.08 (the PC also has the Ryzen 5700G's iGPU; the game picks the RTX 3060) - System: Ryzen 7 5700G, 32 GB, Arch Linux (kernel 7.2.14), Hyprland on Wayland - Settings: fullscreen on and Game speed set to Real time, everything else default; no `hookshot_env.txt`, nothing hooked into the game From the log: the swapchain is created in `immediate` present mode, the start says `the last start did not finish the driver's part of the shaders: left out`, and 105 shader programs fail (as in #388). Log attached. [hookshot_log.txt](https://github.com/user-attachments/files/34533365/hookshot_log.txt)

peruw commented

2026-11-08 01:18:17 +00:00

(Migrated from github.com)

Adding a Windows / RTX 4060 report from the foliage-linux-updater build.

I saw strong screen flicker with 2x frame generation enabled. Motion looked smooth and the counter was high, but the screen was flickering heavily. One captured gameplay frame showed 83 FPS with "game 41" underneath.

Frame generation was then disabled. The saved gameplay log from Kokiri Forest contains samples around 36-39 FPS, but I wasn't at the PC during that check. I therefore cannot confirm that switching it off fixed the flicker, or that frame generation caused it. I haven't retested the proposed fix or a newer build.

Hookshot settings and results

Game: Ocarina of Time, program ID 0400486024DEC000, update v131072, build e0f3ccfa.
Tools: the Windows foliage-linux-updater package. Built locally from a .nup with its bundled tools, Visual Studio Build Tools 2022 17.14.44 and Windows SDK 10.0.26100; 6 compile jobs. No source changes.
Gameplay settings for the FG-off sample: 75% resolution, Catmull-Rom, 20% sharpness, frame pacing on, game speed Real time, handheld profile off, 16:9.
Switches: RX_VK_PRECOMPILE=1, RX_VK_PIPE_SKIP=1.
Hookshot and its game files were on the D: SATA SSD.
The cold preparation log reported 14,179 shader programs, 21,609 new variants and 105 failures, taking 49.1 seconds. The program cache grew to about 4.08 GB.
With the cache warm, a later startup precompiled 759 programs, 915 graphics pipelines and 113 compute pipelines in 496 ms.
In the FG-off gameplay sample there were roughly 2,450 draws per frame, and the reported GPU time was around 16.4 ms.

Selected log samples from the FG-off run:

2640 presents, 36.6 fps; a frame: 2453 draws
2760 presents, 37.3 fps; a frame: 2457 draws
2880 presents, 36.3 fps; a frame: 2460 draws
3000 presents, 39.2 fps; a frame: 2462 draws
3120 presents, 37.8 fps; a frame: 2462 draws
3240 presents, 37.7 fps; a frame: 2459 draws
3360 presents, 38.2 fps; a frame: 2459 draws
3480 presents, 37.5 fps; a frame: 2460 draws

A separate warm-cache run at 100% resolution logged FPS in the 40s, reaching 47.8 in the saved samples. Camera position, cache state and presentation conditions were not held constant. This is not evidence that 100% is faster than 75%, and these samples aren't a controlled benchmark or 1% low measurement.

Lichii comparison on this PC

I also tried Lichii Frizti v3 (Clang 22.1.8; the repository is now named Fritchii). It used Vulkan on the RTX 4060, 1x resolution, GPU accuracy Fast, asynchronous shaders and presentation, Target 60 frame pacing, 100% speed, and the game's 30 FPS option disabled.

Before the frame-generation experiment, I sometimes saw around 60 FPS, depending on the area. With FSR 3 2x enabled, the status bar showed "Game: 30 FPS" while the motion still looked quite fluid. I didn't independently measure the presented FPS, so I'm not reporting that as a broken frame-generation feature or a confirmed 30 FPS output cap. I asked to restore the previous profile, and frame generation is now off.

The cache stayed in place; the subsequent startup recognized 23,093 pipelines. This comparison is subjective and wasn't made with the same camera and output mode as the Hookshot samples.

Machine

CPU: AMD Ryzen 7 8700G, 8 cores / 16 threads.
Motherboard: BIOSTAR B650MT; AMI BIOS 5.32.
RAM: 40 GiB installed (32 GiB + 8 GiB), configured at 4800 MT/s. Windows reports 35.65 GiB usable. SMBIOS lists the 32 GiB module as "VELVET" with no manufacturer, and the 8 GiB module as Kingston KF552C40-8. Active memory timings were not collected.
Rendering GPU: desktop NVIDIA GeForce RTX 4060, 8 GB VRAM (8188 MiB reported). NVIDIA driver 621.01 / Windows driver 32.0.16.2101; Vulkan 1.4.357.
Integrated GPU: AMD Radeon 780M, enabled, driver 32.0.32015.7029. The emulator logs identify the RTX 4060 as the rendering device.
OS: Windows 11 Home Single Language 26H2, x64, build 26300.9818.
Storage: Kingston SA2000M81000G 1 TB NVMe SSD (C:) and WD Green 2.5-inch 1 TB SATA SSD (D:).
Page file: system managed, approximately 35.65 GiB allocated.
Controller: 8BitDo Receiver, mapped through SDL as a Pro Controller.
Display conditions changed during the session. Earlier Windows queries showed the NVIDIA display at 3840x2160 / 60 Hz; the latest query shows 1920x1080 / 179 Hz. The AMD-connected display is 1920x1080 / 60 Hz. These are not measurements at one fixed output mode.

No game files, generated code, shader caches, keys or saves are attached. PSU, cooling details and CPU/GPU clock telemetry were not collected.

Adding a Windows / RTX 4060 report from the `foliage-linux-updater` build. I saw strong screen flicker with 2x frame generation enabled. Motion looked smooth and the counter was high, but the screen was flickering heavily. One captured gameplay frame showed 83 FPS with "game 41" underneath. Frame generation was then disabled. The saved gameplay log from Kokiri Forest contains samples around 36-39 FPS, but I wasn't at the PC during that check. I therefore cannot confirm that switching it off fixed the flicker, or that frame generation caused it. I haven't retested the proposed fix or a newer build. ## Hookshot settings and results - Game: Ocarina of Time, program ID `0400486024DEC000`, update v131072, build `e0f3ccfa`. - Tools: the Windows `foliage-linux-updater` package. Built locally from a .nup with its bundled tools, Visual Studio Build Tools 2022 17.14.44 and Windows SDK 10.0.26100; 6 compile jobs. No source changes. - Gameplay settings for the FG-off sample: 75% resolution, Catmull-Rom, 20% sharpness, frame pacing on, game speed Real time, handheld profile off, 16:9. - Switches: `RX_VK_PRECOMPILE=1`, `RX_VK_PIPE_SKIP=1`. - Hookshot and its game files were on the D: SATA SSD. - The cold preparation log reported 14,179 shader programs, 21,609 new variants and 105 failures, taking 49.1 seconds. The program cache grew to about 4.08 GB. - With the cache warm, a later startup precompiled 759 programs, 915 graphics pipelines and 113 compute pipelines in 496 ms. - In the FG-off gameplay sample there were roughly 2,450 draws per frame, and the reported GPU time was around 16.4 ms. Selected log samples from the FG-off run: ```text 2640 presents, 36.6 fps; a frame: 2453 draws 2760 presents, 37.3 fps; a frame: 2457 draws 2880 presents, 36.3 fps; a frame: 2460 draws 3000 presents, 39.2 fps; a frame: 2462 draws 3120 presents, 37.8 fps; a frame: 2462 draws 3240 presents, 37.7 fps; a frame: 2459 draws 3360 presents, 38.2 fps; a frame: 2459 draws 3480 presents, 37.5 fps; a frame: 2460 draws ``` A separate warm-cache run at 100% resolution logged FPS in the 40s, reaching 47.8 in the saved samples. Camera position, cache state and presentation conditions were not held constant. This is not evidence that 100% is faster than 75%, and these samples aren't a controlled benchmark or 1% low measurement. ## Lichii comparison on this PC I also tried Lichii Frizti v3 (Clang 22.1.8; the repository is now named Fritchii). It used Vulkan on the RTX 4060, 1x resolution, GPU accuracy Fast, asynchronous shaders and presentation, Target 60 frame pacing, 100% speed, and the game's 30 FPS option disabled. Before the frame-generation experiment, I sometimes saw around 60 FPS, depending on the area. With FSR 3 2x enabled, the status bar showed "Game: 30 FPS" while the motion still looked quite fluid. I didn't independently measure the presented FPS, so I'm not reporting that as a broken frame-generation feature or a confirmed 30 FPS output cap. I asked to restore the previous profile, and frame generation is now off. The cache stayed in place; the subsequent startup recognized 23,093 pipelines. This comparison is subjective and wasn't made with the same camera and output mode as the Hookshot samples. ## Machine - CPU: AMD Ryzen 7 8700G, 8 cores / 16 threads. - Motherboard: BIOSTAR B650MT; AMI BIOS 5.32. - RAM: 40 GiB installed (32 GiB + 8 GiB), configured at 4800 MT/s. Windows reports 35.65 GiB usable. SMBIOS lists the 32 GiB module as "VELVET" with no manufacturer, and the 8 GiB module as Kingston KF552C40-8. Active memory timings were not collected. - Rendering GPU: desktop NVIDIA GeForce RTX 4060, 8 GB VRAM (8188 MiB reported). NVIDIA driver 621.01 / Windows driver 32.0.16.2101; Vulkan 1.4.357. - Integrated GPU: AMD Radeon 780M, enabled, driver 32.0.32015.7029. The emulator logs identify the RTX 4060 as the rendering device. - OS: Windows 11 Home Single Language 26H2, x64, build 26300.9818. - Storage: Kingston SA2000M81000G 1 TB NVMe SSD (C:) and WD Green 2.5-inch 1 TB SATA SSD (D:). - Page file: system managed, approximately 35.65 GiB allocated. - Controller: 8BitDo Receiver, mapped through SDL as a Pro Controller. - Display conditions changed during the session. Earlier Windows queries showed the NVIDIA display at 3840x2160 / 60 Hz; the latest query shows 1920x1080 / 179 Hz. The AMD-connected display is 1920x1080 / 60 Hz. These are not measurements at one fixed output mode. No game files, generated code, shader caches, keys or saves are attached. PSU, cooling details and CPU/GPU clock telemetry were not collected.

hckrman101 commented

2026-11-08 01:43:08 +00:00

(Migrated from github.com)

#415 should fix most of the remaining one-frame flashes. I found them on Linux with an RTX 3090.

The cause: some of the game's GPU work for a frame was replayed before the scene work and the CPU writes it waits for were ready, so it used the previous frame's data (haze or sun shafts popping in or out, environment brighter or darker for one frame). Forcing that work through also stalled the main thread.

In a 60 s test standing still in Kokiri Forest, flashes went from 26 to 10 and fps from ~48 to ~60. Some flashes remain, so it's not a complete fix. If anyone here can build that branch, it would help to know whether it changes things on other GPUs, especially the NVIDIA-on-Linux reports above.

I haven't tested frame generation, so I don't know whether #415 touches the 2x frame generation flicker.

#415 should fix most of the remaining one-frame flashes. I found them on Linux with an RTX 3090. The cause: some of the game's GPU work for a frame was replayed before the scene work and the CPU writes it waits for were ready, so it used the previous frame's data (haze or sun shafts popping in or out, environment brighter or darker for one frame). Forcing that work through also stalled the main thread. In a 60 s test standing still in Kokiri Forest, flashes went from 26 to 10 and fps from ~48 to ~60. Some flashes remain, so it's not a complete fix. If anyone here can build that branch, it would help to know whether it changes things on other GPUs, especially the NVIDIA-on-Linux reports above. I haven't tested frame generation, so I don't know whether #415 touches the 2x frame generation flicker.

cosmus50 commented

2026-11-08 01:46:12 +00:00

(Migrated from github.com)

Commit e40306e fixed the flickering for me.

Commit e40306e fixed the flickering for me.

lwkalis commented

2026-11-08 14:23:03 +00:00

(Migrated from github.com)

I can reproduce the lighting flicker on Hookshot honest-eta on Windows with an RTX 3070 and frame generation off. In Kokiri Forest, I left Link idle on the path shown in the clip and held the camera still. The scenery briefly brightens and returns to normal while the hearts and minimap stay steady. Clear examples are at 1.67 s, 2.67 s, and 6.55 s. Gameplay is smoother after the rebuild, but the lighting flashes persist.

https://github.com/user-attachments/assets/f91dbd3f-f644-426a-8c3b-8966cacde7fa

I can reproduce the lighting flicker on Hookshot `honest-eta` on Windows with an RTX 3070 and frame generation off. In Kokiri Forest, I left Link idle on the path shown in the clip and held the camera still. The scenery briefly brightens and returns to normal while the hearts and minimap stay steady. Clear examples are at 1.67 s, 2.67 s, and 6.55 s. Gameplay is smoother after the rebuild, but the lighting flashes persist. https://github.com/user-attachments/assets/f91dbd3f-f644-426a-8c3b-8966cacde7fa

peruw commented

2026-11-08 14:42:00 +00:00

(Migrated from github.com)

My main problem with Hookshot is still heavy flicker during gameplay, including after updating to honest-eta. Frame generation was off in the tested profile. A high FPS counter doesn't make the flicker comfortable to play with.

I also checked actual gameplay on Death Mountain Trail outside the Goron City entrance, alongside Fritchii v4.1. The menu's 60 FPS wasn't a useful performance test.

In-game observations

Fritchii v4.1 (f6d42b8715): with Link stationary at the cave entrance, 11 consecutive renderer-log windows covered 6,600 presents, about 110.18 seconds. The renderer-reported rate was about 59.9 FPS. The longest reported frame was 42.168 ms; none exceeded 100 ms in that sample. The status bar showed 59–60 FPS. This is a stationary scene, not a walking or combat benchmark.
Hookshot honest-eta (bd9bcd71): the same copied save loaded successfully. The HUD showed 33 FPS shortly after loading, then 60 FPS after settling at the entrance. A later moving/combat scene showed 48 FPS. Those are observed counter readings, not an averaged or controlled route.
The runs differed in resolution, window/fullscreen mode, lighting and activity. They don't establish that either program is universally faster.
The heavy flicker is my own visual report. I don't have a frame-by-frame flash count or a controlled before/after recording yet.

Settings and cache behaviour

Game ID 0400486024DEC000, update v131072 (1.1.1 in the emulator UI). Frame generation was off in both.

Fritchii: Vulkan on the RTX 4060, Fast GPU mode, 1x resolution, FXAA, ScaleForce, asynchronous shaders/presentation, Target 60 pacing, built-in Dynamic FPS and Max Resolution.

Hookshot: 75% resolution, Catmull-Rom, 20% sharpness, frame pacing on, Real time speed, handheld profile off, 16:9. RX_VK_PRECOMPILE=1 and RX_VK_PIPE_SKIP=1. The updated cache contained 39,835 program keys; its shader list contained 31,985 programs. A subsequent startup precompiled 3,801 compute pipelines in 737 ms. That doesn't mean every pipeline needed by every area is ready.

With the manually forced EDEN_NX2_PRELOAD_ALL_PIPELINES=1, Fritchii prepared 17,470 pipelines and again estimated roughly 12 minutes on another launch. Removing that override temporarily selected 5,858 startup pipelines. The original cache files stayed intact. The override was restored after the test.

PC

AMD Ryzen 7 8700G, 8 cores / 16 threads.
BIOSTAR B650MT, AMI BIOS 5.32.
40 GiB RAM (32 + 8 GiB), configured at 4800 MT/s; 35.65 GiB usable. SMBIOS identifies the 32 GiB module as VELVET (manufacturer unspecified), and the 8 GiB module as Kingston KF552C40-8. Active timings weren't collected.
Desktop RTX 4060, 8 GB VRAM (8188 MiB reported), NVIDIA 621.01 / Windows driver 32.0.16.2101; Vulkan 1.4.357.
Radeon 780M enabled, driver 32.0.32015.7029; both programs selected the RTX 4060 for rendering.
Windows 11 Home Single Language 26H2 x64, build 26300.9818.
Kingston SA2000M81000G 1 TB NVMe (C:) and WD Green 2.5-inch 1 TB SATA SSD (D:). The game dump and Hookshot were on D:, Fritchii and its cache on C:.
System-managed page file, about 35.65 GiB allocated.
8BitDo Receiver, SDL Pro Controller mapping. Temporary keyboard mappings used for the test were restored.
Windows reported the NVIDIA-connected display at 1920x1080 / 179 Hz and the AMD-connected display at 1920x1080 / 60 Hz. Fritchii was windowed; Hookshot was fullscreen.
PSU, cooling details and sustained CPU/GPU clocks weren't collected.

The emulator's save files remained unchanged by hash. Hookshot used an isolated copy; the main save wasn't replaced. No game files, keys, firmware, shader caches or saves are attached.

My main problem with Hookshot is still heavy flicker during gameplay, including after updating to `honest-eta`. Frame generation was off in the tested profile. A high FPS counter doesn't make the flicker comfortable to play with. I also checked actual gameplay on Death Mountain Trail outside the Goron City entrance, alongside Fritchii v4.1. The menu's 60 FPS wasn't a useful performance test. ## In-game observations - Fritchii v4.1 (`f6d42b8715`): with Link stationary at the cave entrance, 11 consecutive renderer-log windows covered 6,600 presents, about 110.18 seconds. The renderer-reported rate was about 59.9 FPS. The longest reported frame was 42.168 ms; none exceeded 100 ms in that sample. The status bar showed 59–60 FPS. This is a stationary scene, not a walking or combat benchmark. - Hookshot `honest-eta` (`bd9bcd71`): the same copied save loaded successfully. The HUD showed 33 FPS shortly after loading, then 60 FPS after settling at the entrance. A later moving/combat scene showed 48 FPS. Those are observed counter readings, not an averaged or controlled route. - The runs differed in resolution, window/fullscreen mode, lighting and activity. They don't establish that either program is universally faster. - The heavy flicker is my own visual report. I don't have a frame-by-frame flash count or a controlled before/after recording yet. ## Settings and cache behaviour Game ID `0400486024DEC000`, update v131072 (1.1.1 in the emulator UI). Frame generation was off in both. Fritchii: Vulkan on the RTX 4060, Fast GPU mode, 1x resolution, FXAA, ScaleForce, asynchronous shaders/presentation, Target 60 pacing, built-in Dynamic FPS and Max Resolution. Hookshot: 75% resolution, Catmull-Rom, 20% sharpness, frame pacing on, Real time speed, handheld profile off, 16:9. `RX_VK_PRECOMPILE=1` and `RX_VK_PIPE_SKIP=1`. The updated cache contained 39,835 program keys; its shader list contained 31,985 programs. A subsequent startup precompiled 3,801 compute pipelines in 737 ms. That doesn't mean every pipeline needed by every area is ready. With the manually forced `EDEN_NX2_PRELOAD_ALL_PIPELINES=1`, Fritchii prepared 17,470 pipelines and again estimated roughly 12 minutes on another launch. Removing that override temporarily selected 5,858 startup pipelines. The original cache files stayed intact. The override was restored after the test. ## PC - AMD Ryzen 7 8700G, 8 cores / 16 threads. - BIOSTAR B650MT, AMI BIOS 5.32. - 40 GiB RAM (32 + 8 GiB), configured at 4800 MT/s; 35.65 GiB usable. SMBIOS identifies the 32 GiB module as VELVET (manufacturer unspecified), and the 8 GiB module as Kingston KF552C40-8. Active timings weren't collected. - Desktop RTX 4060, 8 GB VRAM (8188 MiB reported), NVIDIA 621.01 / Windows driver 32.0.16.2101; Vulkan 1.4.357. - Radeon 780M enabled, driver 32.0.32015.7029; both programs selected the RTX 4060 for rendering. - Windows 11 Home Single Language 26H2 x64, build 26300.9818. - Kingston SA2000M81000G 1 TB NVMe (C:) and WD Green 2.5-inch 1 TB SATA SSD (D:). The game dump and Hookshot were on D:, Fritchii and its cache on C:. - System-managed page file, about 35.65 GiB allocated. - 8BitDo Receiver, SDL Pro Controller mapping. Temporary keyboard mappings used for the test were restored. - Windows reported the NVIDIA-connected display at 1920x1080 / 179 Hz and the AMD-connected display at 1920x1080 / 60 Hz. Fritchii was windowed; Hookshot was fullscreen. - PSU, cooling details and sustained CPU/GPU clocks weren't collected. The emulator's save files remained unchanged by hash. Hookshot used an isolated copy; the main save wasn't replaced. No game files, keys, firmware, shader caches or saves are attached.

Daniel333313131 commented

2026-11-08 14:58:53 +00:00

(Migrated from github.com)

Windows 11, RX 7900 XTX, Ryzen 7 9800X3D, 32 GB, honest-eta, frame generation off.
White one-frame flashes of the whole scene in Hyrule Field.

Putting RX_VK_WAIT_GPU=0 in hookshot_env.txt removes them completely (unchanged release DLL). FPS stays at 58-60, so on this card the per-present GPU wait costs nothing noticeable. In vk_replay.cpp that wait is off by default on Windows (it was turned off after a ~10 fps loss on an RTX 4060 Ti), so this may be worth enabling by default when the GPU has headroom, or at least documenting as a workaround.

For reference, forcing every occlusion report to 4096 (PR #487) did not change the flashes here.

This comment was posted by Claude (Claude Code) at the explicit request of the account owner (Daniel333313131), who tested the change himself.

**Windows 11, RX 7900 XTX, Ryzen 7 9800X3D, 32 GB, `honest-eta`, frame generation off.** White one-frame flashes of the whole scene in Hyrule Field. Putting `RX_VK_WAIT_GPU=0` in `hookshot_env.txt` removes them completely (unchanged release DLL). FPS stays at 58-60, so on this card the per-present GPU wait costs nothing noticeable. In `vk_replay.cpp` that wait is off by default on Windows (it was turned off after a ~10 fps loss on an RTX 4060 Ti), so this may be worth enabling by default when the GPU has headroom, or at least documenting as a workaround. For reference, forcing every occlusion report to 4096 (PR #487) did not change the flashes here. --- *This comment was posted by Claude (Claude Code) at the explicit request of the account owner (Daniel333313131), who tested the change himself.*

hckrman101 commented

2026-11-08 17:25:48 +00:00

(Migrated from github.com)

The brightness flicker should be fixed in v2.0.2 (#645). It came from the CPU and GPU both writing the game's exposure page; a capture now waits for that page's write-back, so you don't need RX_VK_WAIT_GPU anymore. If the flicker is gone for you on v2.0.2, I think this can be closed, and the dark side bars can get an issue of their own if they're still there.

The brightness flicker should be fixed in [v2.0.2](https://github.com/NotRexed/Hookshot/releases/tag/v2.0.2) (#645). It came from the CPU and GPU both writing the game's exposure page; a capture now waits for that page's write-back, so you don't need `RX_VK_WAIT_GPU` anymore. If the flicker is gone for you on v2.0.2, I think this can be closed, and the dark side bars can get an issue of their own if they're still there.

NotRexed commented

2026-11-09 05:44:33 +00:00

(Migrated from github.com)

Tracked in #1005, follow there. That issue collects every report of flicker and flashing, and this one is linked from it with its GPU, version and log details. Several flicker causes were fixed in v2.0.0 and v2.0.2, so a retest on v2.0.6 is especially 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 #1005, follow there. That issue collects every report of flicker and flashing, and this one is linked from it with its GPU, version and log details. Several flicker causes were fixed in v2.0.0 and v2.0.2, so a retest on v2.0.6 is especially 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`.