なにこれ
オチとしては、こんなことやらなくてよかったなって話です。
まず前提として、一般的なゲームパッドでは125Hzで動作します。
125Hzで動作している場合、楽曲が始まった瞬間を0.000秒とすると0.008秒、0.016秒……と0.008秒間隔で入力判定がされることになります。
1.000(秒) を 125(Hz) で割るわけですから、0.008秒間隔になるわけです。
次にBPM125の楽曲では16分音符1個につき0.120秒です。
0.120は0.008で割れるので、実際の入力と完璧なタイミングのズレはノーツによらず常に一定になるはずです。
（BPMが62.5の倍数の楽曲でありさえすれば16分音符は0.008の倍数秒になってくれるはずなので、必ずしも125の曲である必要はありません）
StepManiaのテーマ『SimplyLove』ではリザルト画面に判定のヒストグラムが出ます。
これは実際の入力と完璧なタイミングをミリ秒単位で比較した誤差をヒストグラムとしたものです。
BPM125の倍数であり、かつ125Hzで動作しているゲームパッドでプレーすると、このヒストグラムがFF7のクラウドの髪型のようにツンツンになることが知られています。
www.instructables.com
このツンツンになったグラフを確認したくて、適当なBPM125の楽曲に滝を置きました。
それを適当なUSBコントローラでプレーしたのが以下。
BPM125の曲で、そんなにいいゲームパッドを使っていないので判定ヒストグラムにスパイクが現れる想定だったのに、なぜかそんなこともなく普通のグラフになってしまった。
— Shalon (@Sha10n) 2022年12月29日
あれー？ pic.twitter.com/uaCGyYoIw2
想定と違う結果になりましたね。
これを修正（？）する話です。
修正方法
まず、結論から書くと
Themes\Simply Love\BGAnimations\ScreenEvaluation common\Panes\Pane4
にある
Calculations.lua
の29行目の
local ScaleFactor = { 0.045, 0.090, 0.180, 0.370, 0.180, 0.090, 0.045 }
によって滑らかにされています。
より厳密に言えばこれは単なる補正値で、実際に滑らかにしているのは36行目から43行目のfor文でしょうが、そこを弄ってバグが出ても嫌なので補正値を弄ります。
この7つの値はヒストグラムに対してどれだけ影響させるかという値です。
真ん中の0.370は実際のズレの値であり、そこから1つズレるたびに±0.001秒の所に影響しているはずです。
なので、私は次のように数値を書き換えました。
local ScaleFactor = { 0, 0, 0, 1.000, 0, 0, 0 }
メチャクチャわかりやすいですね。
補正しないで欲しいので、ズレてる部分の重みを0にしました。
よく分からんけど、とりあえず
— Shalon (@Sha10n) 2022年12月29日
0,0,0,1,0,0,0
にしておけば補正はかからんだろうと思ってこうした。 pic.twitter.com/DARph0HFwi
ツンツンし始めましたね。
これでちゃんと入力に対して正確なグラフになったと思います。
オチ
こうするとどっちがゲームパッドか分かりやすくなるかな（ノート数を減らしただけ） pic.twitter.com/oJ4lRxzrVQ
— Shalon (@Sha10n) 2022年12月29日
グラフ化の対象となるノート数を減らしたら、わざわざこんな修正をしなくてもツンツンしてました。
