ひつぶのチラ裏

久々の記事となります。ひつぶです。

Twitterなどでは「○○フレームで光る」という表現をよく見かけます。

あまり違和感が無いこの文章。

しかし、よく考えてみてください。「1フレーム」とは何秒なのでしょうか。

一般的に普及しているディスプレイは毎秒約60回描画することが出来ます。

でも、それはあくまでディスプレイ側の話であって、内部処理はもっと多くの回数が処理されるのが一般的です。

さて、これを踏まえて、「1フレーム」とは何なのでしょうか。
その「フレーム」単位で行われているという判定の仕組みはどうなってるのでしょうか。

調べていくうちにいろいろな事実が判明しました。

この記事では

• beatmania IIDX 22 PENDUAL
• GITADORA初代 (DrumMania)

について検証をします。

検証結果を以下にまとめます。

音ゲーマーのみなさんはぜひ読んでみてください。　　

目次

はじめに

FPS値とリフレッシュレートの違い

知ってる方は飛ばしてもらって構いません。

FPS値とは、Frames per secondの略で、1秒間に何枚の画像を描写できるかを示します。

動画やゲーム等でどれだけ滑らかに動いてるか示す指標となります。

ここで注意したいのは、例として100FPSで動くゲームがあったとしても、実際にディスプレイに反映されるとは限らないことです。

ディスプレイには「リフレッシュレート」と呼ばれる、FPSと同じ指標があります。

ゲームが100FPSで動いていても、60Hzのディスプレイで表示した場合、実際に描写されるのは毎秒60回だけです。

つまり、30FPSで動いてるゲームは、60Hzと120Hzのディスプレイどちらに接続しても同じ、ということになります。

120FPSのゲームを60Hzのディスプレイで描写した場合、1回描写するうちに2回分の画像が送られてくるため、フレームが引き裂かれ、ちらつきの原因になります。

このため、垂直同期と呼ばれる、処理回数をディスプレイのリフレッシュレートと合わせる機能が存在し、入力遅延に対しシビアではないゲーム等でよく使われています。

同期しない場合に比べ入力と同じタイミングで処理が行われないわけですから、遅延に対しシビアなゲームで使えないのは当然とも言えます。

※最近はゲーム側でフレームの引き裂き現象(ティアリング)に対応するタイトルもあるようです。
ここでは秒あたりのゲーム処理回数について検証をするため、IIDXが対応しているかは考えません。

きっかけ

さて、本題に移ります。
きっかけは新作DDRAにおける判定騒動。

アップデート直後、判定がひどいと話題になりました。

先日、それに対する修正が入ったわけですが、その際に

やっぱりいろんなところで1Fしか差が無いのにもかかわらず、グレとマベに分かれるパターンが多いな。

— 厄介な音ゲーマーの方のShalon (@Sha10n) 2016年4月12日

という発言を見かけました。

僕としては、記事冒頭で述べたとおり1秒間における処理回数と描画回数が異なるのだから、「当然だろう」という感想しか持たなかったわけです。

しかし、疑問が湧きます。
なぜ今まで誰もそれを指摘していないんだ？という疑問です。

もし、１秒間に60回しか処理していなければ、1秒/60回 ≒ 0.016秒/回、
つまり16ミリ秒に1度しか判定処理を挟めないことになります。

そのため、当初は「ありえない」と考えていました。

音ゲーという入力に超シビアなものが判定部分で雑になっているとは考えにくかったからです。

そこで、内部処理が60回より多い証明がしたくなったわけです。
まぁ、その試みは失敗に終わるわけですが。

beatmania IIDXの検証

※この記事においてBGMとはキー音を抜いた楽曲を指すとします
※この項における整数で表したFPS値は小数点以下を丸めた整数値とします

フォロワーさんが決定的となる弐寺のキャプチャ動画の提供を持ちかけてくれました。以下の動画の掲載は許可を得ています。

【4/23追記】検証動画の解析疑惑について
記事公開から1日、多くの方に読んでもらうことが出来て光栄です。
さて、Twitterにて「これらの動画は解析ではないか」との指摘を複数回受けました。
2chでも晒されてしまったこともあり、提供者さんに連絡を取り詳細を確認しました。
結論から言いますと、以下の3本の動画は解析ではなく、全てゲームセンター協力のもと、正規の手段を踏んで撮影したもので、動画提供者さんから疑惑に対し納得の行く説明をしてもらうことができました。
が、提供者さんの希望によりここに記すことは出来ません。

記せない以上、無駄でしょうが弁明を書いておきますと、筆者は解析された弐寺があるといのを今回初めて知りました。
筐体を所持しているのと何が違うのかいまいち分かっていませんが。

ともかく、説明は受けたもののここに記すことは出来ないため、動画の公開は取りやめ文章のみでの説明とさせて頂きます。
説得力半減どころではないためこのような結果になって非常に残念ですが。

もしこの話を信じてもらえるのであれば、自分のやっている画面と違うから解析だ、匿名の撮影者などいるはずがないなどという、短絡的な考えは止めていただけると幸いです。

＊＊＊＊＊＊＊＊＊＊＊
再度追記です。
提案されたこともあって提供者さんとINIFINITASで同様の動画が得られないか相談し試してもらいましたが、現在配信されているものはリフレッシュレートの変更をしても緑数値の変動が確認できませんでした。
よって、INIFINITASで同様の検証は出来ないため、動画抜きでの記事公開継続とさせて頂きます。
※筆者はMac環境しか所持しておらず、INIFINITASの詳細について分かっていません。もし、同様の検証結果を得る手段があれば教えていただければ幸いです。
※リフレッシュレートをプレイ中に変更する行為は規約違反に該当します故、試される場合は自己責任で行ってください。
※アルファテスト及びベータテスト時のINIFINITASはAC同様の仕様であったらしいため、質問項における緑数字の話は正しいと思われます。

＊＊＊＊＊＊＊＊＊＊＊


合計で3つです。
動画は公開できない状況になってしまったため、動画内容を追記しています。
そちらをご覧ください。

動画1つ目。弐寺の起動時、FPS値をチェックしています。
もしここでFPS値が不安定であれば弐寺の起動に失敗する仕組みになっています。
動画では60FPSでほぼ安定しているので弐寺が起動されています。
この時点で雲行きが怪しくなっていますね。

＊動画の内容
データやネットワークのチェック後、「MONITOR CHECKING」の表示とともにFPSが表示されます。
このまま10秒程度FPSが安定するかチェックされ、問題なければいつもの弐寺の画面に遷移します。




続いて、2つ目の動画です。
30FPSまで落として起動してみましょう。
起動成功したのだから問題ないはず。そう思っていました。

＊動画の内容
先ほどの動画より、FPS値が安定していれば起動することが分かったので、
30FPSに抑えたうえで通常のプレイ画面に遷移させています。
すると、下記の箇条書きのような症状が現れます。



既に頭を壁に打ち付けたいですが何がおかしいのか見てみましょう。

• ノーツが曲に合っていない
• アニメーションがおよそ1/2の速度になっている
• BGM、ムービーは正常の速度である

この時点でいろいろ分かりますね。
結論は後にするとして、ノーツ速度の挙動が不思議です。

アニメーションは1/2の速度で動いてるのに対し、ノーツ速度は1/2ではありません。
現に、BGM終了後、ほどなくしてノーツ落下も終わります。
BGMの2倍の長さにわたってノーツが降ってくる、という自体にはなりませんでした。

つまり、ここでは完全ではないにしろ、
ノーツにはFPS値に応じてある程度の補正がかけられていたことになります。
1つ目の動画、及び動画冒頭にあるFPS値チェックは無駄ではないわけですね。
プレー出来るレベルではありませんが。

さて、気を取り直して3つ目の動画を。
先ほどの30FPSのプレイ後、IIDXを立ち上げた状態で60FPSに戻した際のプレー映像です。

＊動画の内容
弐寺が立ち上がっている状態で30FPSから60FPSに移行させた環境での動画です。
症状は下記の箇条書きの通りになります。

BGM・ムービーが楽曲の半分ほどでリザルトに移行しました。

もう明らかですがまとめると

• ノーツがおよそ2倍速になっている
• アニメーションが正常な速度で動いている
• BGM、ムービーは正常である
• 楽曲終了判定がノーツ基準である

見て分かるように、ノーツ落下がBGMのほぼ半分で終了し、リザルトに移行します。
(画面端のスクロールバーは下まで落ち切る)
余談ですが、楽曲終了判定にノーツが使われているのも珍しいケースであると思います。
ノーツがキー音になっている弐寺だからこそでしょうか。

ここで先に結果の1つを書いておきます。
少なくとも弐寺は、フレーム基準で処理がされている、ということです。
これはアニメーションの動きから一目瞭然です。

これを踏まえて、次の話に移ります。
ノーツが2倍速になった原因を探りましょう。

お察しかもしれませんが、弐寺起動時のFPSチェック。先程も述べたように、これによってノーツ落下速度が決定されます。

つまり、弐寺の起動中にFPS値が変動したとしても、「フレームに対する落下速度」は変わりません。

30FPSから60FPSになり、単位時間あたりのフレーム数は倍になったわけですから、
当然単位時間あたりのノーツ落下速度は倍になったわけです。

通常プレイに比べると動画2本目・3本目ともに、緑数字が半減していたことからもこの事実は分かります。
>>Idola SPN通常プレイ動画(参考)

よって、
beatmaniaIIDXは60FPSで稼働することを前提に設計されていることが分かりました。
つまり60FPS以外では内部処理が正常に動かないわけです。

さて、今まで触れませんでしたが、動画の通り、ノーツは曲に対し同期されていません。
更に、ノーツはフレーム基準で描画されています。

以上より、弐寺の判定はフレーム基準で行われており、
毎秒60回しか、16msごとにしか判定処理が行えないことが分かりました。

これにてbeatmania IIDXにおける判定の検証を終えます。


ここで、FPS値及びノーツ時間における丸め誤差は考えません。
36ノーツ分しか計算していませんが、結果は十分出ています。
相当フレームの小数点以下が0.3〜0.7の範囲のものが複数確認できます。
つまり、60FPSではこのズレ表示は機能させることが出来ません。

※この検証ではズレ表示が正しいものであるという前提のもと行っているため、
もし、内部処理が60FPSで3msズレ表示は±8msの誤差があるのかもしれません。
が、現状の資料では判断できないため以下を結果とします。

これにより、内部FPS値は60より大きいと思われます。
これは自分でも予想外の結果でした。嬉しいのですが。

また、ズレ表示が±3ms、判定調整は±6msでしか行えないことを考えると、
各処理タイミングにおいてズレが3の剰余が0になるよう丸めているのでしょう。
なお、現状の資料からは60FPSより大きいの固定フレームなのか可変フレームなのか、それについては判断することは出来ません。

以上より、内部処理は60FPSより大きいためズレ表示値の信頼性は高く、判定精度も高いと結論付けます。

検証表について詳細が知りたい方は下記からNumbersおよびExcelファイルを御覧ください。
>>GITADORA.numbers
>>GITADORA.xlsx

余談ですが、GITADORAは珍しく公式が判定について発表しています。

>>判定について公式からの説明 - ライトニングボルト！



しかし、公式の発言はあくまで「判定幅」であるため、今回の検証に関係はありません。

予想される質問

>>Ribbit! • AC IIDX 緑数字 と LR2 HS の相互変換



Q. GITADORAは3ms幅で処理しているから約333FPSの固定フレームなのでは？

違うでしょう。
考えれば分かることですが、楽曲基準で3msごとの区切りと、ノーツに対する3msごとのズレは一致しません。

もし3msが絶対的に正しい値であるとするならば、単純計算で1000FPS必要になります。
これはあまりにも現実味のない数値です。

GITADORA
・内部処理は60FPSより大きく判定の信頼性は高い

最後に

弐寺ですが、この事実が分かったからといってプレイする分には何の問題もありません。

あくまで音楽ゲームの設計として問題があるのではないか、という話です。

昔からこの仕様なのですから、今まで誰も文句を言わなかった時点で16msなんてものは人間には細かすぎるのでしょう。

こんな資料あるよ！や、それ間違ってない？等、意見がありましたらコメントなどで連絡れくれると嬉しいです。

最後に、この1件で情報提供してくれた、さこん氏(@_1u)、みの氏(@mino90h)、動画提供してくれた方、その他反応してくれた多くのフォロワー方に感謝します。
また、2chの方たちはこの記事を通して学んでくれると嬉しいです。何とは言いませんが。