はじめに

各種アケコンをPCで使った場合の遅延を比較していきます。

鉄拳7のSteam版（240Hz）を用いての計測です。

注意事項その他は前回記事を参照してください。

（2023/02/13追記）
なお、これまでの記事で書いていませんでしたが、Steam入力（英語では"Steam Input"）についてはOFFにして計測を行っています。

これがONになっていると入力情報がSteamクライアントを介してやりとりされるため、遅延が増すのではないか……と考えられます（具体的には調べていません）。

アケコンもゲーム側も大抵はX-Inputに対応しており、Steam入力を使う必要はないと思いますので、余計なものは外した方が良かろうと思います。また逆に、これをONにしていると動作してくれないアケコンもありました（Qanba Obsidian）。

なおスト5のように、Direct-Inputにも対応している親切なゲームもあります。スト5はUnreal Engineのようなミドルウェアを使っていないため対応しやすいのかもしれません（スト6も同様です）。

計測したアケコン

• RAP.N

• Panthera（旧版）

• Fighting Edge 刃

• Qanba Obsidian

• HITBOX

• Fighting Stick α

• 鉄拳7スティック

• Brook UFB（Xbox360モード）

• Brook UFB（PS4モード）

• Pico Fighting Board

結果

先に結果を書いておきます。

ただし後々説明する通り、1ms単位の世界ではどうしてもブレが残ってしまう、という点には注意してください。また測定条件など様々な前提もあるので、以後の説明も読んでおくことを推奨します。

全アケコンのデータ

左が1000fps撮影、右が240fps撮影で、いずれも100回平均の数値です。

遅延が少ない順に並べ替え

以下、経過や途中に考えたことなども挟みつつ説明していきます。すこし長いです。

240fps撮影・100回平均での結果について

まず従来通りの計測を20回平均で行ったのですが、精度に不足があったため、試行を100回に増やすことにしました。その結果が先の画像の「240fps」列です。

計測はかなり大変でしたが、まあまあの精度が出たと思います。ただ、まだ若干ブレがあるように見えましたので、追試を行うことにしました。

なお、ここでGameSir C2を予選落ちとしました。20回平均で測定した時に他のアケコンより10ms程度の遅延増がみとめられたため、以後は計測していません。1Fに満たない程度ではありますが、遅延を気にするのであれば選択肢からは外れるでしょう。

計測精度について

前回、「これからは1ms単位で比較すべき」というようなことを書きましたが、実際問題、20回平均での結果を見てみると±2ms程度は簡単にズレてしまっていました。

これは考えてみれば当然なのですが、iPadでは240fps撮影をしているのに対して、ゲーム側は60fpsでしか動いていないため、1F（1/60秒）が4分割される（1～4/240秒）うち、どのタイミングでボタンが押されたかによって、結果に最大3/240秒≒12.5msのズレが生じてしまうのです。

さらに、1ms（1/1000秒）単位で計測したいのに対し、240fps撮影だと約1/4の頻度でしか撮影ができていません。これでは精度を出すのはなかなか難しく、純粋に試行回数を増やすしか対策がないことになります。計測手段の限界といった感じですね。

そこで、1000fps撮影が可能なデジカメを引っ張り出してきて使ってみることにしました。

実は、もう5年以上前になりますが、鉄拳7の家庭用が発売された時、今回使っているトライアングル・サービスさんのユニバーサル遅延測定器のような回路を自作し、遅延を計測したことがあります。

仕組みもほぼおなじで「ボタン入力と同時にLEDが点灯するようにし、ゲーム画面と同時に撮影する」というものです。回路の作りが適当で、電池を直列で繋いであったりしますが……。

LED点灯する押しボタンを繋いでみたりもしました。

この時に使ったのが下記のデジカメで、1000fps撮影が可能という製品です。

ただし1000fps撮影時の解像度は非常に低く（224x64）、画面も暗くなってしまうため、あまり良好な撮影性能とは言えません。240fps・フルHDで撮れるiPadとは雲泥の差です。

ただ、自分も画像のチェックに大分慣れてきていて、ポイントを押さえればキャラクターの動き出しを判断するのには問題なさそうであるため、採用することにしました。

ちなみに960fps撮影が可能なSONYのサイバーショット（DSC-RX100M5）もレンタルして試したのですが、こちらは解像度912x308まで出るものの、960fpsでは7秒間しか録画できず、撮影が終わるたびに「記録中」となって処理に4～5分かかるということで、今回のような計測では実質使えないことが分かりました。

画面上部と下部とのズレ

今回のデジカメではかなり狭い範囲しか録画できないため、「どの部分を撮るか」が問題になってきます。最初は一番目立つ、つまり見落としが少ないキー履歴表示を解像度の範囲に収めれば良いか、と思っていたのですが、ここで若干問題発生です。

じつは240fps撮影していた時点で、キャラクターの動き出しのタイミングに対して、キー履歴表示の切り替わるタイミングがすこし遅れていることに気付いていました。そのズレが1000fps撮影だとより顕著になったのです。240fps撮影の時はキャラクターの動き出しを基準に数値を取っていたので、1000fpsの際にキー履歴表示を基準にしてしまうと、240fps撮影の時よりすこし遅れることになってしまいます。

「キャラの動き出し」というのは、あきらかにキャラクターがモーションに入っている状態のことで、多くの場合は下画像のようになります。これはサイバーショットで960fps撮影した画像です。

一八の頭部がなんだかブレていることが分かるでしょうか？　これはジャブの初動モーションに入っている最初のコマです。そして、注目すべきことに腕や下半身はまだ動き出していないように見えます。

これは描画の仕組みの都合で、一般に画面上部から更新（リフレッシュ）していくためと考えられます。超高速で画面を切り替えるリフレッシュレート240Hzと言えども、240～1000fpsで撮影すると、画面上部から順に描画していることがバレちゃった、という感じでしょうか。

したがって、画面上部で感知できるキャラの動き出しと、画面下部にしか表示されないキー履歴では若干ながら差が出てしまうわけです。具体的にどれくらい差が生じるのかは、これも計測してみましたが、平均すると2.39msほどキャラの動き出しが速くなっていました。1000ms / 240Hz = 約4.17ms ということで、それくらいになるのでしょうか。

キー履歴を撮影しての計測を行い、後から差分の数値2.39msを引いても良いのですが、なんだか気持ち悪いので、最初からキャラクターの頭部を画面に収める方針に変更します。特に何も考えずにデフォルトカーソルの合っている一八を選んでいたのですが、髪型のおかげで動き出しがめっちゃ分かりやすいというのも一因です。

なお、キー履歴とキャラの動き出しについて、ためしに他のゲームでもチェックしてみましたが、やはりソウルキャリバー6、DOA6といった画面下部にキー履歴が表示されるゲームでは若干の差が見られたのに対して、スト5、GGSTなど、キー履歴が画面左上から更新されていくゲームについては差が0ms～極小となっていました。やはり「画面が上部から更新されていくため」と結論づけて良さそうです。

計測全体のワークフロー

撮影後に数値を割り出すまでの手順について、今までは10～20回平均でやっていたので適当だったのですが、100回平均となると大変なので色々考えました。

AVIUtlで現在のフレーム番号を拾いやすくする

まず、コマ数のカウントに使っているAVIUtlの現在のフレーム数表示ですが、これを基本機能「現在のフレーム番号をクリップボードにコピー」を使って素早く拾えるようにします。

この機能はデフォルトでも「編集」メニュー内に存在しているのですが、やや深いところに置いてあって使いにくいので、ショートカットを設定します。「ファイル」→「環境設定」→「ショートカットキーの設定」に入り……。

下の方に行くとお目当ての「現在のフレーム番号をクリップボードにコピー」があるので、ショートカットキーを割り当てます。

「Ctrl+X」などに設定しておけば良いでしょう。

ためしに使ってみます。下画像のようにLEDが点灯した最初のフレームで「Ctrl+X」を押すと、画面左上の現在のフレーム番号がクリップボードに送られます（コピーされます）。

適当な場所でペーストしてみると、17999。たしかに上画像のフレーム番号になっています。同様に下画像のキャラの動き出しのフレームでも「Ctrl+X」。

ペーストしてみると、18058です。

この差分を取れば良いわけですが、これは暗算しても良いですし、Excelやスプレッドシートにあらかじめ関数を用意しておいても良いでしょう。

このやり方は、格ゲーで60fps撮影し、硬直差や全体硬直を調べたりする時にも便利なので覚えておいて損はないと思います。

ただし、この計測方法だと最初のフレームはカウントしていないことになる点には注意してください。上記の例であれば、（最初の）点灯したフレームの数値をそのまま引いてしまっているからです。

たとえば「全体硬直を調べたいな～」といったケースでは、この最初のFも硬直に含まれることが多いでしょうから、これをやると1F少なくカウントしてしまいます（カウントの仕方にもよります）。調べている数値の性格やカウントの仕方により、必要に応じて+1Fしてください。

クリップボード管理ソフトを使う

今のところデータはExcelで管理しているのですが、数値を1つずつコピーしてくるたびに適切なセルにペーストして……とやるのも面倒です。そこで、下記のクリップボード管理ソフトを使うことにしました。

このフリーソフト「ペースター」には、クリップボードの履歴をテキストファイルとして書き出す機能があります。それを使ってどうするのかというと、

1. AVIUtl上ではひたすら「Ctrl+X」の操作だけを行う

2. データはクリップボードに蓄積されていくので、テキストファイルとして吐き出す

3. テキストファイルに記されている数字の羅列を全文コピペしなおし、一気にExcelに貼り付ける

……ということです。

なおペースターが扱える「履歴の個数」は設定で400～500くらいまで増やしておきます。

実際にクリップボード履歴を吐き出す操作はこんな感じです。

吐き出したファイルを覗いてみると、これまでコピーしてきた数値が並んでいます。設定で「項目間に区切り線を挿入」のチェックボックスはOFFにしておいたので不要な文字列は含まれていませんが、項目ごとに改行が1行挟まってしまうのは仕様のようですね。

なおクリップボード管理については、Windows10以降では標準機能としてショートカット「Win+V」に割り振られている他、ペースター以外に下記のようなフリーソフトもあり、先のAVIUtlの機能とあわせて使うと便利です。

Excel上で差分の計算と平均値の算出を行う

とりまExcelにデータをコピペすると、こんな感じです。

この数字の羅列をそれぞれ計算して、左隣の列にだーっと並べたいと思います。その後は関数で平均値を出せばOK。

計算方法ですが、関数ではちょっと無理なのでVBAを使います。ググったりしながら、たどたどしく書いていきますが、今回はかなり単純なコードで済んだので助かりました。

「自分のセルから2つ下の行の数値を引き、結果を左隣の列の i 行目に貼る」ということになってます。i が計算で出せるのでそんなに難しくないとゆーことですね。

このVBAマクロを「Ctrl+U」に割り振って、先ほど貼り付けた数値の羅列の一番上のセルで実行します。これで差分の平均値まで一気に計算できました。

作業自体はだいぶ楽になったと思います。あとはアケコン10種について、ポーリングレート250Hzと1000Hzの2パターン、それぞれ100回計測した動画をAVIUtlで読み込み、点灯・キャラの動き出しのタイミングを見切って「Ctrl+X」をひたすら押していくだけだな（白目

240fpsと1000fpsの差

今回は240fps撮影と1000fpsの2種類で計測を行いましたが、やはり差が出たのでしょうか？　下記画像のように差分を計算してみました。「撮影方法」列がその数値です。

全体には1000fpsの方が計測値が小さくなる傾向があるようです。ただし、逆に240fpsの方が数値が小さかったケースも散見されますね。

最初、差が出るメカニズムが理論的に説明できず、悩んだのですが、数値を見ると一定範囲内に収まっているので、おそらく単純なfpsの違いからくる差なのではないかと思います。

そもそもですが、先述のように「240fps/1000fps撮影したとしても、ゲームは60fpsで動いているからズレが生じる」という事情があります。

1/60秒のうち、どのタイミングで押したかで結果にズレが生じるというもので、1000fps撮影ではこれが最大で16msになります。遅延を1ms単位で計ろうとしていることを考えると、かなり大きなブレ幅で、100回試行で精度を上げてはいるものの、どうしてもブレが残ってしまいそうです。

また上の図を見ると分かりますが、240fpsでは最大3/240秒≒12.5msだった誤差が、1000fpsでは最大16msに増えます。この誤差は遅延の数値が減る方向に働くので、もし平均値が出たとすると、1000fpsの方がすこし（おそらく1.75ms程度？）小さな値になるのではないか……と考えられます。

また、240fpsよりも1000fpsの方が細かく見ている分、240fpsが「この辺だ！」と言っても、1000fpsが「残念、ここでした！」となるのはしゃーないのですが、その数値の帯域も影響を与えているかもしれません。今回計測した遅延の数値は、240fpsで言うとおおむね下図のようになります。

たとえば平均60msの遅延があるアケコンの数値を計測していて、もし数値が59～61msにやたらと偏っていた場合、240fpsではそれらの数値がすべて「62.5ms」として記録されるため、1000fpsの値と比べて1.5～3.5ms程度大きな結果が全体の多くを占める……といったことも起こりえます。

今回は「ばらつき具合」についてはキチンと調べていないので、なんとも言えませんが、可能性としてはそういうこともありそうです。パッと見た感じバラつきは大きめで、あまり激しい偏りは無さそうな感じがしますが……。

ここまでの事情を踏まえると、基本的には1000fpsの数値の方が信用できると思いますが、100回平均では完璧と言えるほどの精度は出ない、という点には留意しておいた方が良さそうです。

ポーリングレート：デフォルトと1000Hzの差

さきほどの図には、ポーリングレートによる差も記してありました。「Polling Rate」の列です。

これを見ると、基本的には1000Hzに設定した方が遅延が小さくなる、と考えて良さそうです。ただ効果のほどはアケコンによりまちまちで、元々1000Hz稼働しているため影響がないと思われるBrook UFB、効果が特に少ないFighting Stick αを除いても、0.82～2.88msとブレがあります。

この数値は後述の調査ともイマイチ整合せず、元々ブレがある環境下なので仕方ないかなあといったところです。ポーリングレート250Hzと1000Hzの差ということは、理論上、4ms未満の値になるはずなので、そこは範囲内に収まって良かったです。

ポーリングレート設定の確認方法

ポーリングレートをコロコロ変えて計測していて、20回平均くらいの数値を見ると「変更前の方が遅延が少ない」といったこともザラにあったため、「本当に設定が反映されてるんかいな？」といぶかっていたのですが、hidusbf上では設定の数値が表示されるだけです。
※ポーリングレートについての説明は前回の記事を参照してください

これでは確認方法がないな……と困っていたところ、かの有名なWiresharkでUSBの通信内容が見られるよ、ということをTwitterで教えていただきました（ありがとうございます）。

Wiresharkと言えば、ネットワークの通信内容を細かく見るためのツールという印象でしたが、インストール時にパッケージを追加すればUSBのパケットも見られるようです。なんという高機能……。

色々設定してみたり、フィルターの方法をググって調べたりした結果、お目当てのアケコンを見つけられました。赤枠内に製造者が"Razer"、製品名が"Panthera"であることが示されています。
※こんなに綺麗には表示されない製品もあります

続いて、こいつがポーリングレートいくつで稼働してるんやろ、というのを探そうとしたのですが……ここで問題が発生です。このデバイス番号（1.11.0）の情報を色々見ていくと、"ENDPOINT DESCRIPTOR"というのが通信をつかさどる情報のはずなのですが、ここに表示されている"bInterbal"の数値が想定していた値になっていません。

先ほどhidusbfではポーリングレートを1000Hzに設定したので、bInterbalは1（ms）になっていないとおかしいのですが……。しかも、"ENDPOINT DESCRIPTOR"自体も複数存在する……。

これは他のアケコンで試しても同様で、bInterbalの数値が2～64でたくさん存在するような製品もありました。そこで、"ENDPOINT DESCRIPTOR"を参考にするのは諦めて、こいつ（1.11.0）がホストであるPC側と、どれくらいの頻度でやりとりしているのか、を見ていくことにしました。

リアルタイムのやりとりをPantheraの番号のみでソートすると、ものすごい勢いでデータが流れていきますが、いったん止めて個々のやりとりを見ていくと、タイムスタンプが記されているのが分かります。

この移り変わりをチェックしよう、というわけです。

やりとりが2行進むごとに何ms経過したかを調べていくと（1行目がホストからデバイスへ、次の行がデバイスからホストへの通信なので2行ワンセット）、たとえばこんな感じでした。

Epoch Time: 1676195769.355607000 seconds
Epoch Time: 1676195769.356606000 seconds

差分を見ると、0.00999 seconds、ほぼ1msです。これならば1000Hzに設定されていると思って良さそうですね。

その後、他のアケコンでも計測したのですが、「Defaultでは4msの値が出てちゃんと250Hzになっているようだ」ということは確認できたものの、実は1000Hzの時に1msの数値が出たのはPantheraとHITBOXだけで、他のアケコンでは2～4msの数値が出ていました（下図）。

これはちょっと謎で、この数値が実際に影響しているとすると、ポーリングレート1000Hzに設定したはずが（1ms）、2msにしかなっていないアケコンは遅延減少効果が半分しかなさそうな気がします。

ところが、先に見た「ポーリングレートによる差」によれば、この数値が影響したような形跡はなく、2msでしか通信していないアケコンもそれなりに遅延の数値が減っています。たしかに1msになったPantheraとHITBOXは比較的良い数値となっていて、4msにしかならなかったFighting Stick αは0.5msと最低値になってはいるものの、2msのQanba ObsidianやFighting EdgeではPanthera以上の数値が出ています。

このあたりは原因がよく分かりません。この値は平時のみで、実際にパケットを送る時にはちゃんと1000Hzで通信できているのかもしれませんし、多少通信頻度が落ちても十分な遅延減少効果があるモノなのかもしれません。

そもそも計測によるブレが大きく厳密な値とは言えそうにない、というのも「ポーリングレートによる差」で述べた通りなので、より高精度の測定ができない限り、ここを追ってもあまり意味がなさそうです。ポーリングレートを1000Hzに設定した方が遅延が減る、という結論も特に変わらないでしょう。

なおHITBOXについて、自分はBrook UFBを搭載しているものと思い込んでいたのですが、おなじBrookでもFIGHTING BOARD PS3/PS4という別の製品だったようです。数値を見ると他のアケコンと同様、デフォルトでは250Hzで、設定により遅延が減っているようですね。

またPico Fighting Boardですが、これは平時にはまったく通信をしていないように見受けられました。実際にボタンを押した時のみ、パケットが流れる仕様のようです。そのため今回のWiresharkを使った方法では、何msに一回通信をしているのかを調べることはできませんでした。

Wiresharkでポーリングレート設定ができているかを確認した副産物として、「hidusbfで設定（Install Service）した後、アケコンのUSB端子を抜き差しすれば設定は反映される」ということが分かったのは収穫でした。それまでは設定するたびに念のためPCを再起動していたので、だいぶん助かりました。

所感

さて、遅延の少ない順に並べたデータを見てみます。

とりあえず言えることとして、どのアケコンもそこまで大きな差はなく、5ms以内には収まっているという点は押さえておきたいです。

色々と遅延対策をした上での話ならば、アケコンによる差は最大でも1/3F程度ということで、冷静に考えて普通に遊ぶ分には許容範囲内と言えるのではないでしょうか。ここまで血眼になって「遅延ガー！」と言い続けておいてナンですが……。
※GameSir C2のような10ms以上も差のある製品は除く

ただし、さらに低遅延を攻める必要のある人、遅延ジャンキーやプロゲーマーなどであればもう少し詰めてもバチは当たらないでしょう。

このような前置きの上で、あえて細かい数値も見ていくとすると、まずQanba Obsidianはやや数値が良くないです。これは240fps撮影でも変わらなかったので、おそらくHORIなどのアケコンとくらべて1ms程度遅延が大きいものと思われます。プロゲーマーでも採用しているプレイヤーの多いアケコンのようですが、PFBにすれば5ms程度改善することを考えると、換装は必須と言って良いのではないでしょうか。
※個人的にはメイン以外のボタン配置が適当であったりする点など、あまり好きな製品ではありません
　先日発表されたObsidian2では改善されている模様

次にHORI製品はだいたいおなじくらいの数値に落ち着きました。RAP.Nをはじめとして使用している鉄拳プレイヤーも多いと思われますが、ポーリングレートを1000Hzに設定するだけで3.5F程度の遅延に抑えることができそうです（ディスプレイ設定240Hz時）。

なお鉄拳7スティックだけやたら良い数値が出ていますが、少々眉唾というか、他のHORIアケコンと異なるのは1000Hz設定の1000fps撮影の箇所だけですので「上振れしたんじゃないの？」と疑っています。中身の基板もRAP.Nと違うということは考えにくいなあと……。完全にネタ枠で採用したのですが、意外な結果となりました。

通常販売されているアケコンでもっとも数値が良かったのはPanthera（旧版）で、「これならBrook UFBに換装しなくても良いじゃん」と真顔になりました。換装キットは買ってあるのですが……。「Wiresharkで見た時の挙動が良いから1000Hz設定の恩恵が大きいのかな？」とも考えたのですが、そもそもの遅延が少ないっぽいですね。こうなると、これまであまり興味のなかった新型のPanthera（EVO）もちょっと気になってきます。

Brook UFBですが、前評判通り非常に低遅延のようです。公式ではPCで使う際、Xbox360モードで繋ぐことが推奨されているのですが、「PS4モードの方が遅延が少ない」という話もあり、今回試してみたところ、鉄拳7においてはほぼ同等のようです。PS4モードをPCで使うと「ボタンを放す操作の時のみやや遅延する」という不具合があるそうなので、鉄拳7をプレイする際には素直にXbox360モードで使った方が良いかもしれません。なお、他に「WiiUモードにして1000Hz設定する方が低遅延」といった情報もあります。

そして最も数値が良かったのは、前評判通りPico Fighting Board（PFB）となりました。56ms ≒ 3.36Fの数値は圧巻で、PS4版でRAP.Nを使った時の6F遅延とくらべると0.56倍、-2.64Fですから、もはや別のゲームと言っても過言ではないでしょう。PS4に繋いだ際にはレガシーモードでの使用となってしまうのが弱点ですが、PS4版鉄拳7に関しては問題なく使える上、遅延も最小ですから、「鉄拳7をやる上で遅延を気にするならPFBに換装」としておけば間違いないでしょう。自分もPantheraを換装するとすればUFBではなくPFBにするかもしれません。

※PFBについては前回記事を参照してください
　対応機種がBrook UFBよりかなり少ないといった弱点もあります

今後の予定

今回の計測でめちゃくちゃ時間を食ってしまいましたが、次はようやくリフレッシュレートごとの計測をしていきます（計測にはPFBを採用）。

その後はPS5関連（PS4 on PS5や、GGSTのPS5版と他ハード版との差）の計測をちょこっとやって、一通りおしまいという感じでしょうか。その他ではアケコン改造などもいくつか記事にしていきたいです。

今回はここまでとなります。お疲れ様でした。