After switching Game speed to Per frame once, saves in large areas load at ~5 fps on every later start #519

Closed

opened 2026-11-08 07:59:17 +00:00 by hallygtree · 4 comments

hallygtree commented

2026-11-08 07:59:17 +00:00

(Migrated from github.com)

What happens

After switching Game speed to Per frame once (and back to Real time), the game runs at about 4-5 fps on every later start, as soon as the first save loaded is in a large area (Goron City, Darunia's room, Death Mountain Trail, Hyrule Field). Once that happens, every save loaded in the same session runs at about 5 fps.

Before switching to Per frame for the first time, the same saves ran normally when loaded first after starting the game (40-60 fps in Goron City).

Steps

Start from a save that has never been played with Per frame. Saves in large areas load and run normally.
In the Insert menu, set Game speed to Per frame. Play through Darunia's first cutscene.
Set Game speed back to Real time and close the game.
Start the game and load a save in a large area: about 5 fps. This includes saves made before step 2.

Reproduced twice. Restarting the PC does not undo it.

What still works after step 3: loading a save at the entrance of Kakariko Village first (about 25 fps), then any other save, which then runs normally.

What I checked

Saves made with Per frame on and right after switching back differ only in position and play time.
Restoring the saves, option.sav, hookshot_options.ini and the three cache files (hookshot_programs.bin, hookshot_pipelines.bin, mkw_vk_pipelines.bin) from before step 2 did not undo it; neither did removing the caches or the NVIDIA shader cache.

Log of a slow session

VRAM: 4052 MB used of 3367 MB allowed (961 MB of it free in the blocks); textures 432 MB (budget 0 MB), up to 5602 MB used with 2565 MB of textures
GPU time 130-240 ms a frame; slow submit: 180 ms: draw 179 descriptors 177 texture lookups 176
0 waits for shaders or pipelines, 0 jobs queued
nvidia-smi during the slow session: GPU utilization 100%, memory utilization 0%, 31 W of an 80 W limit

Setup

Release device-lost-fix (caaaf2b7), Hookshot Builder, .nup build e0f3ccfa / v131072
Dell G15 5520: RTX 3050 Laptop GPU 4 GB, driver 617.42, i5-12500H, 40 GB RAM, Windows 11; same result with the dedicated GPU only and with Optimus
Quality preset Minimum, handheld profile on, resolution 50%, frame generation 2x
One RomFS mod (DualSense button icons)

Log of a slow session (Goron City save loaded first): https://gist.github.com/hallygtree/2ccdd7327f087579442d97d4ba42d95c

I can send the save I used if it helps.

### What happens After switching Game speed to Per frame once (and back to Real time), the game runs at about 4-5 fps on every later start, as soon as the first save loaded is in a large area (Goron City, Darunia's room, Death Mountain Trail, Hyrule Field). Once that happens, every save loaded in the same session runs at about 5 fps. Before switching to Per frame for the first time, the same saves ran normally when loaded first after starting the game (40-60 fps in Goron City). ### Steps 1. Start from a save that has never been played with Per frame. Saves in large areas load and run normally. 2. In the Insert menu, set Game speed to Per frame. Play through Darunia's first cutscene. 3. Set Game speed back to Real time and close the game. 4. Start the game and load a save in a large area: about 5 fps. This includes saves made before step 2. Reproduced twice. Restarting the PC does not undo it. What still works after step 3: loading a save at the entrance of Kakariko Village first (about 25 fps), then any other save, which then runs normally. ### What I checked - Saves made with Per frame on and right after switching back differ only in position and play time. - Restoring the saves, `option.sav`, `hookshot_options.ini` and the three cache files (`hookshot_programs.bin`, `hookshot_pipelines.bin`, `mkw_vk_pipelines.bin`) from before step 2 did not undo it; neither did removing the caches or the NVIDIA shader cache. ### Log of a slow session - `VRAM: 4052 MB used of 3367 MB allowed (961 MB of it free in the blocks); textures 432 MB (budget 0 MB)`, up to 5602 MB used with 2565 MB of textures - `GPU time` 130-240 ms a frame; `slow submit: 180 ms: draw 179 descriptors 177 texture lookups 176` - `0 waits for shaders or pipelines`, `0 jobs queued` - nvidia-smi during the slow session: GPU utilization 100%, memory utilization 0%, 31 W of an 80 W limit ### Setup - Release device-lost-fix (caaaf2b7), Hookshot Builder, .nup build e0f3ccfa / v131072 - Dell G15 5520: RTX 3050 Laptop GPU 4 GB, driver 617.42, i5-12500H, 40 GB RAM, Windows 11; same result with the dedicated GPU only and with Optimus - Quality preset Minimum, handheld profile on, resolution 50%, frame generation 2x - One RomFS mod (DualSense button icons) Log of a slow session (Goron City save loaded first): https://gist.github.com/hallygtree/2ccdd7327f087579442d97d4ba42d95c I can send the save I used if it helps.

hallygtree commented

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

(Migrated from github.com)

Update: after a crash (#287), I started the game and loaded my newest save first, without loading the Kakariko save before it, and it ran normally (about 25-40 fps). That save was made today, after the Per frame problem started, in a session that began with the Kakariko workaround. The save from before the Per frame switch (Goron City) still loads at about 5 fps unless the Kakariko save is loaded first.

NotRexed commented

2026-11-08 10:39:50 +00:00

(Migrated from github.com)

Thanks for the detailed report: the log showed it. On your 4 GB card the scene's textures were decoded uncompressed (1.75 GB of them in Goron City), so VRAM went to 5.6 GB of the 3.3 the driver allows and the driver paged. Release https://github.com/NotRexed/Hookshot/releases/tag/low-vram keeps them compressed on cards with under 6 GB (a quarter of the size). Could you update and try the Goron City save again?

hallygtree commented

2026-11-08 17:32:56 +00:00

(Migrated from github.com)

Tested v2.0.1 with the Goron City save from before the Per frame switch, the same files both times:

Goron City save loaded first after starting the game: about 5 fps. GPU time 93-176 ms a frame, most of it in texture lookups. VRAM 4233 MB used of 3367 MB allowed, textures 1503 MB.
Kakariko save loaded first, then the same Goron City save: 26-52 fps. GPU time 7-21 ms a frame. VRAM 4411 MB used of 3367 MB allowed, textures 598 MB.

The log shows big ASTC textures kept as BC3.

Logs:

Goron City save loaded first (about 5 fps): https://gist.githubusercontent.com/hallygtree/bf8b55c0bf9f1acae6bfe865695747c8/raw/v2.0.1_goron_first_5fps.txt
Kakariko save first, then Goron City (normal): https://gist.githubusercontent.com/hallygtree/bf8b55c0bf9f1acae6bfe865695747c8/raw/v2.0.1_kakariko_then_goron_normal.txt

Tested v2.0.1 with the Goron City save from before the Per frame switch, the same files both times: - Goron City save loaded first after starting the game: about 5 fps. GPU time 93-176 ms a frame, most of it in texture lookups. VRAM 4233 MB used of 3367 MB allowed, textures 1503 MB. - Kakariko save loaded first, then the same Goron City save: 26-52 fps. GPU time 7-21 ms a frame. VRAM 4411 MB used of 3367 MB allowed, textures 598 MB. The log shows big ASTC textures kept as BC3. Logs: - Goron City save loaded first (about 5 fps): https://gist.githubusercontent.com/hallygtree/bf8b55c0bf9f1acae6bfe865695747c8/raw/v2.0.1_goron_first_5fps.txt - Kakariko save first, then Goron City (normal): https://gist.githubusercontent.com/hallygtree/bf8b55c0bf9f1acae6bfe865695747c8/raw/v2.0.1_kakariko_then_goron_normal.txt

NotRexed commented

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

(Migrated from github.com)

Tracked in #993, follow there. That issue collects every report of garbled or rainbow textures that get worse over play time, and this one is linked from it with its GPU, version and log details. It is a known issue in v2.0.6 and not fixed yet. 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.