fix(framegen): 2x uses the renderer's own blend again; FSR 3.1 interpolation opt-in (#1635) #1730

Merged

NotRexed merged 2 commits from fix/framegen-2x-own-blend into main

2026-11-10 17:10:16 +00:00

NotRexed commented

2026-11-10 14:49:56 +00:00

(Migrated from github.com)

Fixes #1635 and its duplicates (#1690, #1713, #1716, #1725 and others): with Frame generation 2x, the HUD smears, a ghost trail follows Link, and a see-through rectangle appears. It happens at 2x only.

Cause

Since #1386 (v2.0.12), 2x uses AMD FSR 3.1's frame interpolation where it can run. FSR 3.1 needs a HUD-less colour to keep the HUD still. This game draws its HUD into the same picture, and vk_fsr3fi.cpp binds no HUD-less input (hudless_attached_factor = 0), so the interpolation moves the HUD with the scene. 3x and up never used FSR 3.1, which is why reporters see it only at 2x. Players found that Frame generation Off or Auto avoids it.

Change

fsr3fi::asked() defaults to 0, so 2x is made by the renderer's own blend again, as it was before v2.0.12 and as 3x+ are.
RX_VK_FSR_FG=1 still asks for FSR 3.1's interpolation; =0 turns it off, as before. The menu's 2x hint follows frames_wanted(), so it shows the right text.
The readme's two paragraphs are updated.

Follow-up

A proper FSR 3.1 path would pass a HUD-less colour: the upscaled scene captured at the gameplay upscale's dispatch, before the game's HUD passes. That would make FSR's interpolation usable at 2x again.

In-game check queued here: 2x with a HUD on screen, screenshots plus a flash check.

🤖 Generated with Claude Code

Fixes #1635 and its duplicates (#1690, #1713, #1716, #1725 and others): with **Frame generation 2x**, the HUD smears, a ghost trail follows Link, and a see-through rectangle appears. It happens at 2x only. ## Cause Since #1386 (v2.0.12), 2x uses AMD FSR 3.1's frame interpolation where it can run. FSR 3.1 needs a HUD-less colour to keep the HUD still. This game draws its HUD into the same picture, and `vk_fsr3fi.cpp` binds no HUD-less input (`hudless_attached_factor = 0`), so the interpolation moves the HUD with the scene. 3x and up never used FSR 3.1, which is why reporters see it only at 2x. Players found that Frame generation Off or Auto avoids it. ## Change - `fsr3fi::asked()` defaults to 0, so 2x is made by the renderer's own blend again, as it was before v2.0.12 and as 3x+ are. - `RX_VK_FSR_FG=1` still asks for FSR 3.1's interpolation; `=0` turns it off, as before. The menu's 2x hint follows `frames_wanted()`, so it shows the right text. - The readme's two paragraphs are updated. ## Follow-up A proper FSR 3.1 path would pass a HUD-less colour: the upscaled scene captured at the gameplay upscale's dispatch, before the game's HUD passes. That would make FSR's interpolation usable at 2x again. In-game check queued here: 2x with a HUD on screen, screenshots plus a flash check. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

hckrman101 (Migrated from github.com) approved these changes

2026-11-10 16:40:47 +00:00

hckrman101 (Migrated from github.com) left a comment

Looks good. Making asked() default to 0 sends 2x back through the renderer's own blend, which is what 3x+ already do, and frames_wanted() (and so the menu hint) follows it. RX_VK_FSR_FG=1 / =0 behave as the readme now says. CI is green. Only the in-game HUD check you queued is left.

Nit: the two readme paragraphs have gotten long single lines; consider rewrapping them like the rest of the file.

Looks good. Making `asked()` default to 0 sends 2x back through the renderer's own blend, which is what 3x+ already do, and `frames_wanted()` (and so the menu hint) follows it. `RX_VK_FSR_FG=1` / `=0` behave as the readme now says. CI is green. Only the in-game HUD check you queued is left. Nit: the two readme paragraphs have gotten long single lines; consider rewrapping them like the rest of the file.