プレイ時の遅延を計測してみる

長すぎるので結論だけ見たい人のための短いまとめ

• • 実機＆ブラウン管テレビの遅延は、3F(極たまに2Fが出る)

  • 実機をVGAアナログ変換してレスポンスの良いモニターに出力すると遅延約4F

  • 実機のコンポジット端子をVGAアナログ変換する時に発生する遅延は体感で1Fかそれより少し少ないくらい？

  • コンポジット→VGA変換する時のアップスキャンコンバータのおすすめはとりあえずESYNiC

  • VGAケーブルの長さで遅延の変化はほぼ起こらない気がする

  • エミュレータでオフラインで６４スマブラすると、遅延は2F～5Fほど

  • モニター内でアナログデジタル変換する時に発生する遅延は体感で0.5F前後？

  • エミュレータのFPSを細かく設定する方法さえあれば、実機を再現可能？

この記事でやること、その目的について

実機やエミュレータなど様々な環境で６４スマブラをプレイしたときの操作の遅延を計測し、

実際に私たちは普段どれくらいの遅延の中でプレイしているのかを確認してみようという試み。

私たち64スマブラーは、実機で64スマブラを試みるたび、

重く大きなオブジェクトであるブラウン管TVの取り扱いに辟易してきた。

「本当にブラウン管TVは必要なのか？液晶モニターではダメなのか？エミュレータで代用できないのか？」

そんなことを考えるための材料にしたい。

遅延の計測の方法について

詳細に遅延を計測する手段を持っていないので、

iPhoneの60FPSカメラを使って

ボタンを押してから実際にキャラクターが反応するまでの様子を撮影し、

それをAviutlのフレーム送り機能を使って観察するというアバウトかつ力ずくな手法を取る。

この方法で遅延の検証を行った場合の大きな問題点は、

1.まず入力方法自体が人力で、ボタンを押したタイミングを確定するのが難しいため、精密な検証方法とは言いがたい

2.遅延は正確には2Fや3Fといった整数では無く、あえてフレームで正確なところを表すなら「2.65F」みたいな数字になるはずだが、60FPSというゲーム内の時間を基準に撮影＆検証をするので、結果が整数でしか出てこない。また、遅延はそもそも一定ではない。

ということだが、まあ参考程度にはなるだろうと思う。

検証方法の検証

実は一度、上記の方法で色々な環境で遅延を計測してみたのだが、

実際は30FPSで動画を見ていたことが発覚したり、

ボタンを押した瞬間のフレームかどうかが判別できないことが多かったので、

まずは検証方法自体を検証してみることにする。

60FPSで撮影できているかどうかの検証

スマブラの中で流れる時間の最小単位は、1Fだ。

1F=1/60秒なので、60Fでぴったり1秒が経過する。

Aviutlで60回コマ送りした時に、ぴったり1秒経過していれば、60FPSで撮影できていると言える。

というわけで、iPhoneでiPhoneのストップウォッチを撮影してみた。

タイマーが動いていない時のフレームを便宜上0F目、

タイマーが動き出した瞬間のフレームを1F目とする。

すると60F目には1分、120F目には2分の表示が現れた。

ちゃんと60FPSで撮影＆検証ができていると言えるだろう。

ボタンを押したタイミングを確定できるかどうかという話

遅延計測のために入力するボタンはZボタンを採用した。

シールドの発生が1Fで見た目にもハッキリと動いたことが分かるからだ。

だがしかし、60FPSで撮影すると、いくら素早くZボタンをサムスのためキャンの要領で入力しても、

ボタンを押したかどうか判断に困ることが多くなってしまう。

30FPSだと指が結構な距離をワープするので、簡単にボタン入力が入ったフレームを確定できたのだが･･･

というわけで、もっと入力したことが分かりやすいボタンを移植した。

Lボタンのところから飛び出ているが、Zボタンの電気信号を乗っ取っている。

この赤いボタンを押し込むと、64コンでZを押したのと同じ電気信号が流れ、シールドが出る。

このボタンを素早く押し込み、ボタンのへこんだ距離で入力が入ったかどうかを判断する。

64コントローラのボタンをそのまま使うよりは大分入力の確定がしやすいと思われる。

それでも判断に迷うことはあるが、正確性は試行回数を稼ぐことでカバーしたいと思う。

遅延の計測結果

便宜上、ボタンが入力されたと確定できるフレームを、遅延0F目とする。

つまり、

ボタンを押したと同時にキャラクターが動いたら遅延0F、

ボタンを押した次のフレームにキャラクターが動いたら遅延1Fとする。

この数字の割り当て方には異論もあると思うが、

計測する際の混乱が少ない方法を採用したということでご容赦願いたい。

実機をブラウン管テレビに接続した場合

普通に６４スマブラをする時のスタイル。

大会でもこのスタイルですね。

ボタンを押してからキャラクターが動くまでの時間を計測したところ、

ボタンが入力されたと確定できるフレームを0Fとすると、

キャラクターが動き出したのは3F後でした。

（以下この説明は省き、単にこの状況を「遅延3F」と表記します）

また、極たまにですが、遅延が2Fになるときもありました。

実機の遅延は2Fと3Fの間で、かなり3F寄りのところにあるのでしょう。

遅延3Fと書くと、意外と遅いなという印象になるかもしれませんが、

他の計測結果を見れば、遅延3Fがいかに優秀な数字であるかが分かるかと思います。

実機をモニターに接続する場合

何をするかと言いますと、

本来の６４の出力端子であるコンポジット端子を、

D-sub15pinというコネクタに変換することで色々なモニターに出力できるようにし、

そのうえで入力遅延を計測していきます。

D-subというのは、この端子です。パソコンのモニターの接続などで使われますね。

HDMIやDVIといった形に変換することも可能ですが、

今回はVGA(≒D-sub)のみで検証を行います。

アナログ信号であるコンポジットは、

アナログ信号であるD-subを使用した方が

結果的に遅延が少なくなるのではないかという考えのためです。

しかしながら、液晶モニターに出力する場合、

モニターの方でアナログ→デジタルの変換が行われるので

最初からデジタルに変換した方が遅延が少ない説もありますが、

すべてを検証するには色々なものが不足しており、また全てを揃えるのは不可能なので、

手元にあるブラウン管モニターという絶好の検証道具を生かすという意味でも

今回はD-subのみで検証することにしました。

コンポジット端子はアナログ信号であり、

ブラウン管モニターはアナログ信号、

液晶モニターはデジタル信号となっています。

映像は何かしらの手を加えるたびに遅延が発生するはずなので、

実機のコンポジット端子を何かしらの形に変換して何かしらのモニターに出力する場合、

アナログ→デジタルの変換が不要かつモニター自体の遅延の無いブラウン管モニターが

理屈の上では最も素早く表示されると考えられます。

（何か認識の間違いなどがありましたらご指摘いただけますと助かります。）

なお、遅延計測の結果はすべて60Hzで行ったものを記載しています。

75Hzも試しましたが、今回の検証では60Hzの方が優秀な結果になりました。

モニター自体のリフレッシュレートが高くないと意味が無いのか、

はたまた自分が知らない何か遅延にかかわる要素があるのかは不明のままです。

また、解像度は出力可能な限り、最も低解像度のもので出力しています。

使用するアップスキャンコンバータについて

コンポジットをVGAに変換するために、アップスキャンコンバータというものを使います。

詳しい説明はさておき、アップスキャンコンバータは４つ用意しました。

• エアリア UP KING2

• I･O DATA VABOX2

  • テック コンポジット S端子 VGA (Dsub15Pin) 変換コンバーター TSCVGA2

  • ESYNiC VGA S-video RCA to VGA ビデオコンバーター

アナログ同士の変換なので製品にそう差は無いだろうと思っていたのですが、

結論から言うとESYNiC VGA S-video RCA to VGA ビデオコンバーターが最善でした。

アップスキャンコンバータの出力結果＆簡易レビュー

• エアリア UP KING2

ブラウン管モニターに出力して、遅延は大体5F、たまに4F。

今回使用した応答速度5msの液晶モニターだと、遅延が5Fだったり6Fだったりした。

• I･O DATA VABOX2

設定が色々可能で、動き対応レベルを１～15までで設定できる。

動き対応レベルは15にした場合は最も遅延が少ない。

ブラウン管モニターでは、安定して遅延4Fが出る。

液晶モニターには繋いでいないが、おそらく5F前後になると思われる。

めっちゃ細かい設定が可能で、

映像の粗い昔のビデオなんかを奇麗に映し出すための高画質化回路なんかが搭載されているそうだが、

私にとっては素早く出力されること以外の機能はまったくもって不要であり、

宝の持ち腐れとはこのことである。

• テック コンポジット S端子 VGA (Dsub15Pin) 変換コンバーター TSCVGA2

ブラウン管モニターに繋げると、4Fだったり5Fだったりする。

VABOX2と比べると、こちらの方が少しだけ遅延があるように感じる。

コンパクトボディで見た目は非常に好み。

ESYNiC VGA S-video RCA to VGA ビデオコンバーター

同じ見た目で色違いのものがありますが、

ボディが黒いやつを買いました。

間違わないように気を付けましょう。

今回試した４機種の中では、最もレスポンスが良かった。

その割には値段は他の機種より控えめ。

最大出力解像度が他の機種より小さめで、

あまり奇麗に画像を出力できないためなのだろう。

しかしそんなことは私にとってはどうでも良いことです。

出力結果、遅延は

ブラウン管モニター：3Fから4F、基本的には4F

液晶モニター(応答速度5ms)：4F、たまに5F

（※液晶モニターは後に出てくる17インチのもの）

となりました。

実機ブラウン管テレビで遅延3F、たまに遅延2Fになるという程度なので、

液晶モニターで4Fを出せるのは、そこそこ実用レベルが高いと思います。

しかも中古で2000円とかで売ってる液晶モニターを使っているので、

ゲーミングモニターのようにリフレッシュレートも高く応答速度も速い物を使えば、

もしかしたら4Fや3Fの安定くらいは狙えるのではという期待を持てる結果になりました。

（最大出力解像度が1280 × 1024なので、それを出力できるモニターである必要あり）

残念ながら今回は未検証ですが、いつか検証したいと思います。

また、ブラウン管モニターで3Fから4Fが出たということで、

アップスキャンコンバータを通すことで生じる遅延差は1Fほどと考えて良いと思います。

遅延Fがずれる確率を考えると、1Fよりも遅延差は小さいのではないかという気がします。

実機でオフしたいけどブラウン管を用意するのは流石に厳しすぎるという場合は、

実機より1F程度遅いということを了解してもらった上であれば

こういった省スペースな機材を使った実機６４スマブラもアリなのではないでしょうか。

手持ちのモニターに繋いでみるのもありでしょう。

D-Subケーブルの違いで遅延差はあるのか

長いものから短いものまで、新しいものから古いものまで、

７本くらいD-Subケーブルがあるので、

ブラウン管モニタ+ESYNiCアップスキャンコンバータの組み合わせで

色々なケーブルを試してみました。

結論から言うと、目に見えた違いは分かりませんでした。

もうちょっと精度の高い検査方法じゃないと発見は無理そうです。

エミュレータの遅延を考えてみる

Windows7のノートパソコンと、

Windows10のデスクトップがあるので

オフラインでProject64kを使ったエミュレータの遅延を計ってみました。

Windows7はAMD、Windows10はNVidiaのグラボを積んでいます。

液晶モニターはアナログ入力とデジタル入力どっちが速いのか(Windows10)

応答速度5msで、VGAとDVIのアナログとデジタルの入力端子のある液晶モニターに、

デスクトップパソコンからデジタルアナログ両方で出力して、エミュレータの反応を比べました。

コンバータはAdaptoidです。

アナログ入力：遅延5F前後

デジタル入力：遅延4F たまに5F

パソコンからモニターに出力する場合、

アナログで入力すると、デジタル→アナログ→デジタルという変換が起こって

微妙にレスポンスが悪くなるのだと思われます。

アナログ入力は、4Fが出たり6Fが出たり、

ちょっと今の私の知識ではついていけない現象が起こったりします。

印象としては、ほんの少しだけアナログの方が遅延がかかっている気がします。

同じ応答速度の液晶モニターで遅延の差はあるのか(Windows10)

Windows10から、Adaptoidで入力し、VGA（アナログ）端子から、

同じBAFFALO製の17インチモニターと19インチモニターに出力します。

17インチモニターの方は、

最初からずっと検証に使っている液晶モニターです。アナログ入力のみ。

19インチモニターの方は、

先ほど使ったデジタルアナログ入力が両方あるモニターです。

17インチ：3Fから4F

19インチ：5F前後

同じメーカーで、ほとんど同じモニターだと思います。

何故1Fほど入力がずれたのでしょうか？

17インチモニターがアナログ入力しかないために

アナログの変換に適した構造になっているのでしょうか？

画面が小さいから遅延が少ないのでしょうか？

（解像度は同じなのですが…）

モニターの設定を比べてみても、

特に遅延に影響のありそうな項目の違いが見当たらなく、謎です。

応答速度と垂直周波数(リフレッシュレート)以外にも

見るべきところがあるのでしょうか？

また、17インチのモニターのレスポンスが、

実機をコンポジット→VGA変換して繋いだ時よりも、

パソコンからVGA入力した方が素早いのは興味深いところです。

コンポジット→ＶＧＡは、アナログ→アナログという変換ですが、

ＰＣからアナログ出力される時よりも大きな遅延が発生している気がします。

今回は機材がありませんが、機会があれば、

この２つのモニターでレスポンスの差が生まれた原因と、

コンポジットをデジタル変換したときの遅延を調べてみたいと思います。

Windows10でブラウン管モニターに出力してみよう

先ほどは、Windows10で液晶モニタにVGAアナログ出力して遅延3F～4Fでした。

今度はブラウン管モニターにVGAアナログ出力してみます。

Windows10、Adaptoid、ブラウン管モニター

この組み合わせで、遅延は3Fで安定しました。

4Fが出ないので、液晶モニターに出力するより素早いです。

この4Fが出るか出ないかの境目にあるのは、

液晶モニターの遅延5msと、

モニター側で行われるアナログ→デジタル変換の２つだと思われます。

体感だと、それらの遅延を合わせて0.5F前後な気がします。

Windows7でエミュレータを動かしてみよう

Windows10は重たいとよく言われます。

ではWindows7でやって比べてみましょう。

Windows7、Adaptoid、Aeroオフで、

ノートパソコンのディスプレイにそのまま出力した場合、

遅延は3F、たまに4Fが出ます。

また、ノートパソコンのVGAアナログ出力ポートを使って出力してみます。

17インチの液晶モニターに出力：遅延2Fから3F

ブラウン管モニターに出力：遅延2Fから3F

特にゲーミングノートパソコンというわけでもないからだと思いますが、

外部モニターに出力した方が遅延が少なくなりました。

また、Windows10のデスクトップからモニターに出力した時に比べ、

1Fほど遅延が少なくなっているのが見受けられますが、

これは単に今回使用したWindows10パソコンに積んでいるNVIDIAグラボの設定のレンダリング前フレームの1Fが遅延に乗った結果なのではないかなと思っています。

Windows10はAeroが切れないと言われていますが、

Aeroがあると3F遅延が起こるはずなので、

明らかにこれはAeroの遅延が乗っていません。

自分が過去にどんな設定やったか覚えていませんが、

何らかの方法でAeroを停止したか、それに準ずる何かをしたのだと思います。

Adaptoidのレスポンスの優秀さを調べてみよう

Windows10でブラウン管モニターにAdaptoidを使ってコントローラ入力した際、

遅延がたったの3Fと非常に優秀でした。

実際のところ、Adaptoidってどれくらいの優秀なコンバータなのか気になったので

同じ条件で、手元にあるものの入力遅延を調べて、比べてみました。

結論を先に言うと、

遅延3Fという数字は非常に優秀で、

入力デバイスとしては、これ以上を望むのは難しいレベルな気がします。

話題のRaphnetのUSB adapter V3とAdaptoidの差が気になりますね。

• N64 コントローラーアダプター

遅延5F

予想通り、遅延が大きい

• RETROLINK

遅延3F

直接USBに繋がってるだけあって、レスポンスが非常に素早い。

これで操作性が良かったら最高なんだけど…

• REVIVE USB

遅延3F

レスポンスの良い、コントローラ自作キット。

3Fで反応した。

コンバータを仲介して、これに引けを取らないというのは正直凄い。

エミュレータで実機を再現できるか？

実機の遅延は3F、たまに遅延2Fが出る程度だった。

エミュレータをレスポンスの良い環境で起動すれば、

遅延に関しては実機に引けを取らないどころか、

上回ることすら可能なことが分かった。

（Windows7で外部モニターに出力したところ、遅延2Fの確率が実機より高かった）

また、USB adapter V3では専用のインプットプラグインが開発されており、

実機と同じ入力値を再現できるそうだ。

つまり、現時点でも、実機と同等以上のレスポンスで、

同様の入力値で、ノートパソコンという持ち運びしやすいデバイスで

６４スマブラをオフラインで遊ぶことは可能ということだ。

だがしかし、実機とエミュレータでは微妙にゲーム速度が違う。

エミュレータは完全にFPS60で動かすことが可能だが、

実機はFPS60よりもほんのちょっとだけ遅いと言われている。

実機のFPSを予想してみる

というわけで、実機がどれくらい遅いのかを検証してみる。

まず、時間制でプププランドで対戦に入る。

試合開始の青ランプがついた瞬間のフレームを1F目とし、

そこからタイマーが丁度3分経過するまでの実時間をフレームで計る。

つまり、試合開始からタイマーをひたすらiPhoneの60FPSカメラ録画し続け、

フレームを見て実時間をフレームに直し、FPSを計算で出す。

計測結果

タイマーが３分経過するまでの時間

Project64k : 10803Ｆ（※10800として考える）

実機：10833Ｆ（※10830として考える）

1/60秒＝1Fであり、

3分＝10800Fである。

Project64kが正確に60FPSを刻み続けたと仮定すると、

端数の３はランプがついてからタイマーが動くまでのディレイだと思われる。

というわけで、端数の３は見なかったことにする。

さて、FPSとは、１秒間にフレームが何個あるかを表す数字なので、

（実機FPS / 60）× (経過した実際の時間) = (経過したゲーム内の時間)

となるはずである。この式の意味は、

ゲーム内の時間と現実の時間を両方同じ単位に直したとき、

FPSの数字が60より上下した分だけズレるということである。

さて、先ほどiPhoneの60FPSカメラで、ゲーム内の３分を撮影した。

つまり、

(実機FPS/60)×(ゲーム内で3分経過するまでの動画の時間)=(ゲーム内の３分)

ということになる。

(経過した実際の時間) =(ゲーム内で3分経過するまでの動画の時間)=10830F

(ゲーム内の３分)= (経過したゲーム内の時間)= 10800F

というわけで、実際の計算式は、

（実機FPS / 60）× (10830) = (10800)

実機FPS=59.83379501385042

となる。

正直言ってこのFPSで安定しているとは思えないが、

数字的にはなんとなくしっくりくるものがあるので、まあ良いと思う。

エミュレータのFPSを制限する方法が不明

Mupen64luaには、

Option > Setting >General >Use Speed Modifier

というゲームスピードにリミットをかける項目がある。

しかしこれは最大FPSではなく、パーセンテージでしか速度を設定できないようで、

しかもどうやら整数でしか設定できないらしい。

mupen64.cfgというファイルを開けば

Fps Modifierという項目に直接書き込めるが、

小数点以下の数字を記載しても、その通りのFPSにはなってくれない。

もしFPSを自在に変更する方法さえ分かれば、

ノートパソコンだけで気軽に

実機のように６４スマブラを持ち運べるかもしれない。

実機の良さはそんなところにあるんじゃねえという意見も分かるが、

ほとんど場所を選ばずにスマブラができたら良いなと思う。

最後に

前々から気になっていたことなのですが、

機会を得たので色々な遅延を調べてみました。

当記事はほとんど自分の興味のために書かれているので、

あまり見やすい記事とは思いませんが、個人的にはそれなりに満足しました。

また何か検証の機会があれば、追記していきたいと思います。