Scoring logic is indeed very inconsistent and fps based (I’m pretty sure hitting above 98 100% of the time isn’t even possible at 60 fps: 200/60 = 3.33 pixels per frame, 75 + (100 - 1.6 * 5) / 4 = 98, meaning there’s a 1.6 * 2 = 3.2 pixel window. (though this might be wrong if int() rounds the value, but I’m pretty sure it truncates)
Also, about the “bpm matches fps” theory, the desync variable should be making that impossible anyway, on my decently powerful laptop desync still jitters by around 3-5 ms every time it’s recalculated, which is more than enough to make a +100 improbable. I don’t have a pc to test this with right now but I doubt it’d jitter much less.
Though, for funsies I will assume that:
1. there are 9 notes in a row that could hit +100
2. the player is playing 60 fps
3. The player’s reaction time standard deviation is 16
4. The player’s spatial awareness is so great that they can attempt a hit in the exact middle of the +100 frame (yes, this is an advantage)
the player’s playing at 60 fps, meaning 16.66 ms per frame, they hit in the middle, meaning the range is ±8.33 ms
with SD = 16 ms, we calculate:
Z = 8.33/16 = 0.5208
putting this into the wonderful invention “calculator” we get P(-Z<x<Z) = 0.39752
9 times in a row, 0.39752^9 = 1 in 4000
Meaning if you ignore about half the game, 9 100’s in a row becomes somewhat believable
Though, honestly, I’m just ‘debunking’ this to prove to myself reading obfuscated code and rereading my math homework from last year for 3 hours was a worthwhile investment 😭 (and I am very bored), I highly doubt opgrhythm is actually lying
tl;dr: fix scoring pls