[BUGFIX] Fix Hit Window Being Offset By FPS

[JackXson-Real]

Associated Assets PR

FunkinCrew/funkin.assets#226

Linked Issues

Fixes #5667

Description

Fixes the issue with the hit window being offset slightly on lower FPS values. Previously, playing on 500FPS would grant you the most accuracy and have the hit window be closest to the center of the strumline, and playing on lower FPS like 60 would offset the hit window down a bit, making it so that you have to hit the notes much earlier than you would think, making the hit windows inconsistent between FPS. This is an issue that should not be in a rhythm game due to accuracy being key. This PR aims to fix this issue by scaling the offset of the hit window based on your set FPS cap in preferences using an equation. Different FPS values should play nearly identical to each other on this PR with the exception of more input delay on lower FPS, but that can't be helped. Special thanks to @Lasercar for fixing the known issues. Check out his comment to see more videos showcasing the fix on other FPS values. I'm only posting 60fps videos because I'm lazy and it's the most noticeable.

Known Issues

- Sustain trail is affected by the offset causing it to appear above the hold note cover
- Downscroll is currently weirdly affected by the offsets

Screenshots/Videos

60FPS - Before Fix

8mb.video-XlF-Z271MvZj.mp4

60FPS - After Fix

8mb.video-aFo-a3wYhyiV.mp4

[Lasercar]

Amazing! Will approve once my changes have been merged. These changes should be more than enough until a proper fix can be found for this issue (unless this turns out to be the only way to fix it....).

Tests after Lasercar's changes

30 FPS, Funkin note style:

2025-08-13.17-48-15.mp4

500 FPS, Funkin note style:

2025-08-13.17-51-41.mp4

500 FPS, pixel note style:

2025-08-13.17-57-11.mp4

[Kade-github]

this function is a little unreadable,

my only request is to try cleaning this up with readable variables and docs because:

• Im going to forget what this does
• Im going to look at this code
• And im going to close vscode and cry

nice changes tho, just a weird implementation (I feel like this should be something to do with a deltatime value instead of magic numbers and the fps value itself(?), but if it works it works.)

[JackXson-Real]

this function is a little unreadable,

my only request is to try cleaning this up with readable variables and docs because:

• Im going to forget what this does
• Im going to look at this code
• And im going to close vscode and cry

nice changes tho, just a weird implementation (I feel like this should be something to do with a deltatime value instead of magic numbers and the fps value itself(?), but if it works it works.)

Will work on the readability. I'm not entirely sure what deltatime values really are so I cannot do anything like that, but if you guys are able to do something similar internally using those, that would probably also work. This fix can potentially be inaccurate due to the offset being based on your FPS cap, and not the actual FPS itself.

[Kade-github]

solid improvement, nice job

will merge once the known issues are fixed

[Kade-github]

also gotta make sure that @EliteMasterEric and @Hundrec / @AbnormalPoof are good with it as well

[AbnormalPoof]

[Lasercar]

solid improvement, nice job

will merge once the known issues are fixed

May I ask what the known issues are?

I was going to approve this myself but there's still more issues?

[Hundrec]

This worked well in my testing, but Eric had some comments about something regarding data
Maybe the implementation just needs to be tweaked for better code

[Lasercar]

It'd be nice to make it use the current FPS, but there currently isn't a way to accurately get it: #4374