MagicBeanDev/Longshot

Watch

Fork 98

Game: intermittent black flashes and flickering foliage #530

New issue

Open

opened 2026-11-14 17:59:55 +00:00 by Alimjan · 3 comments

Alimjan commented

2026-11-14 17:59:55 +00:00

Longshot version

6b76ded3

Channel

Built from source

What kind of problem

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

What happened

I see intermittent black flashes and flickering foliage along the entire section from the Zero River Gate to the waterfall. All areas with vegetation are affected by these unstable visuals.

Where in the game

Zora River

How often

Every time

Graphics card and driver version

RTX 5060 Ti 621.24

CPU, RAM and operating system

AMD ThreadRipper 1950x, 64GB and Windows 11

Changes from the defaults

quality_preset=0
ultrawide=1
output_res=3840x2160
handheld_profile=0
dlss=1
dlss_model=0
resolution=4
sharpness=80
frame_generation=0
frame_generation_by=0
frame_pacing=1
frame_rate_cap=0
nvidia_reflex=2
amd_anti-lag_2=0
fullscreen=1
vsync=2
upscaling=1
ultrawide_menus=1
hdr=0
hdr_paper_white=400
hdr_peak_brightness=1400
hdr_contrast=100
hdr_tone_mapper=0
anisotropic_filtering=4
gpu_device=0
vram_budget=7

longshot_log.txt

longshot_log

Screenshots or video

Before you send it

The problem is still there on the newest release or nightly.
I searched the open issues for it.
I'm not attaching game files, keys, the game's executable, its .bin caches or saves.

### Longshot version 6b76ded3 ### Channel Built from source ### What kind of problem Graphics (missing, black or wrong-coloured things, lighting, flicker) ### What happened I see intermittent black flashes and flickering foliage along the entire section from the Zero River Gate to the waterfall. All areas with vegetation are affected by these unstable visuals. ### Where in the game Zora River ### How often Every time ### Graphics card and driver version RTX 5060 Ti 621.24 ### CPU, RAM and operating system AMD ThreadRipper 1950x, 64GB and Windows 11 ### Changes from the defaults quality_preset=0 ultrawide=1 output_res=3840x2160 handheld_profile=0 dlss=1 dlss_model=0 resolution=4 sharpness=80 frame_generation=0 frame_generation_by=0 frame_pacing=1 frame_rate_cap=0 nvidia_reflex=2 amd_anti-lag_2=0 fullscreen=1 vsync=2 upscaling=1 ultrawide_menus=1 hdr=0 hdr_paper_white=400 hdr_peak_brightness=1400 hdr_contrast=100 hdr_tone_mapper=0 anisotropic_filtering=4 gpu_device=0 vram_budget=7 ### longshot_log.txt [longshot_log](/attachments/dbb8016f-a693-4936-8406-fdc0861748a2) ### Screenshots or video <video src="/attachments/7d8facc3-9837-414a-9a7b-3b23b39009a6" title="longshot_hzz9ymbVpF" controls></video> ### Before you send it - [x] The problem is still there on the newest release or nightly. - [x] I searched the open issues for it. - [x] I'm not attaching game files, keys, the game's executable, its .bin caches or saves.

Alimjan added the

kind

bug

label

2026-11-14 17:59:55 +00:00

mooki added the

gpu/nvidia

label

2026-11-14 18:13:42 +00:00

LPX commented

2026-11-15 01:05:25 +00:00

Possibly related: black lighting flashes removed by `RX_VK_CAPTURE_WAIT=1` on nightly-130

I have additional reproduction/workaround evidence from nightly-130-0caf0618, in Kokiri village, on Windows with an RTX 4070 Laptop (8 GB), NVIDIA 621.24, Core Ultra 9 185H and 32 GB RAM. This is a different location/build from the original report; I have not tested current main or established that both symptoms have the same cause.

Lit scenery and characters intermittently darkened for a frame during walking/camera turns, while parts of the HUD/fairy/fog remained visible. It persisted after full shader/pipeline warm-up. Setting RX_VK_CAPTURE_WAIT=1 removed the flashes in our controlled test and my subsequent normal play.

Both A/B conditions kept these existing overrides:

RX_VK_COMPACT=1
RX_VK_WB_MAX_KB=1024
RX_VK_RECORDER=thread
RX_VK_IMAGE_PREALLOC=0
RX_VK_LOAD=create

The only changed variable was adding RX_VK_CAPTURE_WAIT=1, versus unset (mode 2 in this build). Visual settings: 2560x1440 Docked, game's own scaler at 100%, 0% sharpening, Native HDR/Vanilla (200-nit paper white, 1000-nit peak), frame generation off, V-Sync on.

Evidence: same archived village checkpoint and walking/pan route; fully warmed passes. Control flashed; two candidate launches/four walks had no confirmed flash across 5,268 consecutive captured frames; reverting to default brought the flash back. The reversal's second walk had omitted draws and was excluded. Some foliage obscured the first candidate run, so the repeat used clearer views. Testing/analysis used AI-assisted scripting; I also confirmed the physical-display result myself.

Important diagnostic distinction: visual A/B used the same temporary renderer instrumentation to correct the engine frame logger's HDR source image. That logging-only diff is attached; it is not the workaround. Original official binaries were restored for normal play and separate unrecorded performance tests. The workaround did not show a material average-FPS penalty in our small sample; it does not guarantee 60 FPS or solve every hitch.

In this build, mode 1 waits for relevant unfinished GPU writebacks before copying CPU-written shared pages; mode 2 defers handling to replay. This points toward captured-state/writeback ordering, but we have not identified the precise faulty read or lifetime, and altered scheduling could mask a related race. PR #526's narrow patch and RX_VK_SHADOW_FOLLOWS_SYNC=0 did not remove our symptom. PR #588 may be relevant context, but concerns a newer path.

Attached: redacted diagnostic control/wait-1 logs, representative consecutive-frame triplets, instrumentation diff, and technical notes. No game files, saves, caches or binaries are included. Please treat this as bounded historical evidence and a lead to check, not a claim that the newest release is affected or a universal fix.

### Possibly related: black lighting flashes removed by `RX_VK_CAPTURE_WAIT=1` on nightly-130 I have additional reproduction/workaround evidence from **nightly-130-0caf0618**, in **Kokiri village**, on Windows with an RTX 4070 Laptop (8 GB), NVIDIA 621.24, Core Ultra 9 185H and 32 GB RAM. This is a different location/build from the original report; I have **not tested current main** or established that both symptoms have the same cause. Lit scenery and characters intermittently darkened for a frame during walking/camera turns, while parts of the HUD/fairy/fog remained visible. It persisted after full shader/pipeline warm-up. Setting **`RX_VK_CAPTURE_WAIT=1`** removed the flashes in our controlled test and my subsequent normal play. Both A/B conditions kept these existing overrides: ``` RX_VK_COMPACT=1 RX_VK_WB_MAX_KB=1024 RX_VK_RECORDER=thread RX_VK_IMAGE_PREALLOC=0 RX_VK_LOAD=create ``` The only changed variable was adding `RX_VK_CAPTURE_WAIT=1`, versus unset (mode 2 in this build). Visual settings: 2560x1440 Docked, game's own scaler at 100%, 0% sharpening, Native HDR/Vanilla (200-nit paper white, 1000-nit peak), frame generation off, V-Sync on. **Evidence:** same archived village checkpoint and walking/pan route; fully warmed passes. Control flashed; two candidate launches/four walks had no confirmed flash across 5,268 consecutive captured frames; reverting to default brought the flash back. The reversal's second walk had omitted draws and was excluded. Some foliage obscured the first candidate run, so the repeat used clearer views. Testing/analysis used AI-assisted scripting; I also confirmed the physical-display result myself. **Important diagnostic distinction:** visual A/B used the same temporary renderer instrumentation to correct the engine frame logger's HDR source image. That logging-only diff is attached; it is not the workaround. Original official binaries were restored for normal play and separate unrecorded performance tests. The workaround did not show a material average-FPS penalty in our small sample; it does not guarantee 60 FPS or solve every hitch. In this build, mode 1 waits for relevant unfinished GPU writebacks before copying CPU-written shared pages; mode 2 defers handling to replay. This points toward captured-state/writeback ordering, but we have **not identified the precise faulty read or lifetime**, and altered scheduling could mask a related race. PR #526's narrow patch and `RX_VK_SHADOW_FOLLOWS_SYNC=0` did not remove our symptom. PR #588 may be relevant context, but concerns a newer path. Attached: redacted diagnostic control/wait-1 logs, representative consecutive-frame triplets, instrumentation diff, and technical notes. No game files, saves, caches or binaries are included. Please treat this as bounded historical evidence and a lead to check, not a claim that the newest release is affected or a universal fix.

Longshot-flicker-evidence-nightly130.zip

4.2 MiB

Alimjan commented

2026-11-15 09:06:52 +00:00

Author