The game intro doesn't run well at more than 60 fps #1742
Labels
No labels
accessibility
autorelease: pending
autorelease: tagged
bug
dependencies
documentation
duplicate
enhancement
github_actions
good first issue
help wanted
invalid
question
testing wanted
wontfix
No milestone
No assignees
2 participants
No due date set.
Dependencies
No dependencies set
Reference
MagicBeanDev/Hookshot#1742
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hookshot version
v2.0.13
What kind of problem
Something else
What happened
When you deactivate the fps limit and set it to 120 fps, the narration speeds up and you get to hear lines that you should hear a bit later.
So, we get a sound desynchronization issue that does not exist when 60 fps are set as the limit.
Where in the game
Intro
How often
Every time
Graphics card and driver version
RTX 5070 TI
CPU, RAM and operating system
i9 14900K, 64gb, W11
Changes from the defaults
No response
Other software hooked into the game
No, nothing hooked in
hookshot_log.txt
hookshot_log.txt
hookshot_log.1.txt
hookshot_log.2.txt
hookshot_log.3.txt
hookshot_log.4.txt
Screenshots or video
No response
Before you send it
Thanks for the clear report. This looks like a side effect of #1612 (v2.0.13): above a 60 fps cap the game now steps its time to match real time, but cutscenes and dialogue animations may still advance once per frame, so they run ahead of the picture and the voice lines. #1726 (Link floating in mid-air in Saria's dialogue) is the same family and is closed into this issue.
Work-around: set the Frame rate cap back to 60 (the default) in the Insert menu.
To help pin it down: put
HOS_FPS_LOG=1in hookshot_env.txt (beside hookshot.exe), set the cap to 120, play the intro until the narration runs ahead, and attach the hookshot_log.txt.@klimovich008, as #1612's author: could you take a look? The cutscene and dialogue paths may still step once per frame above the cap.
The cutscene plays PERFECTLY. The sounds and the voices are totally in sync. You can only hear the narrator say two phrases on top of what he is already saying.
I will try and come back, thanks for the reply.
@NotRexed Gonna look into it.
So I retried it. The issue is that the narrator says 4 lines.
Two of them seem to be attached with Li
hookshot_log.1.txt
hookshot_log.txt
nk's voice when he is having the nightmare
Normally you get to hear them like this in the normal pacing:
"Long ago, there was a land called Hyrule, created by beings of supreme divinity."
"At the very edge of this kingdom there lay a small forest. Within it, an ancient, solitary tree quietly watched over the inhabitants of the forest."
"These forest dwellers were called the Kokiri, each had a fairy companion, and they lived out their innocent lives in these woods."
" However, there was one particular boy who did not have a fairy."
But what you get to hear is:
"Long ago, there was a land called Hyrule, created by beings of supreme divinity."
On top of it not even before the sentence is finished: ""These forest dwellers were called the Kokiri, each had a fairy companion, and they lived out their innocent lives in these woods."
Then ""These forest dwellers were called the Kokiri, each had a fairy companion, and they lived out their innocent lives in these woods.""
and on top of it:
"However there was one particular boy who did not have a fairy"
Then you get to hear Link's agonizing sounds and then it stops.
The rest of the sounds, the music, the sound when Link's hands are glowing, the storm, the lightnings, the door slamming on the ground, everything is perfect".
And then comes the Zelda Logo way sooner than what should have happened.
Normally Link wakes up looks outside his window, the camera zooms out over the village and then the Logo appears.
It's as if Nintendo is using the two channels synchronized with other layers of the game.
More of the same family from Discord: at a 100 fps cap, Gohma keeps running into the wall (three tries), and the fight works normally at 60. #1805 marks a Frame rate cap above 60 as experimental in the menu and the readme; until this is fixed, keep the cap at 60.
You know you were the first one to have the intro play perfectly right from your first builds. All emulators were missing frames.
Now, some of them fixed it but they do not have hookshot's performance, getting 70+ frames at 4k without upscaling at the village. No stutters at all.
I might be able to start the playthrough but I want to be able to go above 60 without issues first.
So if you are able to fix that it will be perfect, since there seems to be something like a second layer running at a different speed and is unaffected by the global fps limit.
Two more confirmed cases of the same family (Frame rate cap above 60):
Work-around for all of these: keep the Frame rate cap at 60.
Can you somehow pick these moments and auto limit the fps to 60 then apply the set limit of 90 or 120 again for the gameplay sessions?
Possibly one more above-60 case from Discord: water flickering at a 240 fps cap (RTX 4080, 9800X3D, 621.14). If you see this: does it stay with the cap at 60, and does it stay with Frame generation off?
One more on Discord: Gohma not fighting properly with the Frame rate cap above 60 (fine at 60).
Please, can may o request save files right before the encounter so reproduction gets easier.
Mechanism found (Dyst, on Discord): with the Frame rate cap above 60, each frame's step is a fraction of a 60 fps frame, and the game truncates it to a whole number of frames, so frame-counted timers add 0 every frame and never advance. That explains the consumable counter that never hides (#1832), the Scarecrow's Song stopping after the first notes, and likely the other above-60 cases here (cutscene timing, Gohma, moving platforms). The fix needs those timers to accumulate the fraction instead of truncating it; until then, keep the cap at 60.
Ok so you found the issue. That means a solution will come. Thank you so much for what you have done all these days.
Thank you and the community for the project.
Also this frame counting only works for certain elements and sounds, not the full thing. For example in the prologue it's only about two phrases, Link's grumby sounds and the logo of the game that rushes its way into the screen way before the cutscene is over.
Two more above-60 cases from Discord, both with videos at a cap above 60: no wake or ripples around Link while swimming (61-73 fps), and "weird ripples" in the Hyrule Field river (82-88 fps). The water's interactive ripples look like another frame-counted system that the fractional step breaks. How to handle the cap above 60 is still being decided; for now keep it at 60.
One more from the same player as the 82-88 fps river clip: waterfall artifacts on an RTX 4070 at a cap above 60. If you see waterfall or water artifacts: do they go away with the cap at 60?
I don't believe it. You fixed it! The prologue plays PERFECTLY at my fps limit (116).
The game has jumped from 35 to 50 fps in previous versions to 65 all the way up to 90+ at the village.
Great job, thank you all!
More reports of this, collected here:
More reports of this, collected here:
A list of the places where a frame step is cut to a whole number before it is added to a timer (the mechanism #2006 fixed for pickups), for whoever takes the remaining above-60 faults.
A read-only audit of main found these remaining candidates; I have not run them in game.
Thanks to @jordanella for #2006 and to Dyst for the fractional-step diagnosis already recorded in this thread.
Grades: S = traced in the code; I = gameplay purpose/cause still inferred; R = reproduced by the cited fix's author.
f_80a87e50f_800672e0f_803edf70f_838ceb80,f_838cfc10f_832b32b0f_832b6840(mode 10)f_832b2690f_832b6840(mode 13)f_80d90e60My work on #2668 (the Scarecrow's Song) is on the song sites:
f_832b32b0, the mode-10 branch off_832b6840andf_832b2690, which share one counter; it is being measured at 60, 120 and 240 before anything is patched. The other two unpatched sites (f_832b6840mode 13,f_80d90e60) are offered to whoever wants them, as leads and not as proven fixes.The four song cuts share one counter, so their resets and recording/playback transitions matter; replacing every integer conversion would be unsafe.
I found no demonstrated function-level cause for Gohma's wall behavior or Link's dialogue jump loop.
#2837's log has cap 90 on v2.1.0; all three #2828 logs have cap 144. A restarted 60-cap comparison remains useful for both.