2016/12/30

ゲーミングマウスのセンサとして電磁誘導方式を考える

光学式マウスのセンサ

光学式(LED式,レーザー式)マウスのセンサの原理を大まかに説明すると,内部のカメラで高速撮影した画像の変化を見て,センサがの移動量を相対的に推測するものです.
移動量の推定 (画像はADNS-3090のFrame Capture)
しかし,この方式の精度はセンサが取得した画像の品質に大きく依存します.そのため,平滑面などのトラッキングに向かない面で動作させた場合,精度が大きく低下しトラッキングエラーが発生します.
また,マウスが高速に動いていたり加速度の変化が伴う場合にトラッキングエラーが発生することが知られています.
Logitech G300(125Hz,750DPI)のトラッキングデータとエラー箇所
トラッキングエラーについてはrafa様の記事が非常に参考になります.
rafalog: ゲーミングマウスのトラッキング特性簡易検証 Tracking characteristic test of gaming mice

光学式センサの性能は向上していますが,上で挙げた通り理想的な精度を出すのはまだ難しいという問題点があります.


電磁誘導方式

電磁誘導方式はペンタブレットなどに採用されているもので,アンテナコイル群と座標支持器を用いて座標支持器の位置を絶対値で検出するものです.
Wacom Bamboo Pen CTL-460/K0のトラッキングデータ
移動量を絶対値から検出できるため,上図のように理想的トラッキングが行われていることが分かります.そこで,ゲーミングマウス用のセンサとして電磁誘導方式を採用した場合のメリットとデメリットを考えます.

メリット

  • 高精度

デメリット

  • トラッキング面の広さは,アンテナコイル群のサイズに依存
  • 現行機種ではリフトオフディスタンス(LoD)が大きい
  • 高価(特にトラッキング面が大きいもの)
  • ポーリングレートが低い

課題

先程挙げたデメリットは電磁誘導方式のゲーミングマウスを実現するための課題になります.
そこで,いくつかの課題について議論します.

トラッキング面の制限

トラッキング面の制限ですが,現状のゲーミングマウスの使い方においては問題になりません.光学式マウスの暗黙的なメリットとして「どこでも使用できる」という特徴がありますが,ゲーミングマウスはゲーミングマウスパッドと一緒に使用されることが多く,センサが読み取る面はマウスパッドのみにほぼ限定されています.

LoDが大きい

現行機種ではLoDが数cmあります(ペンタブレットとしてはメリットです).マウス用途として考えるのなら,測距センサなどの非接触で接地検出できるセンサを用いることで,リフトオフを検出することができます.また,マウスソールの裏に圧力センサなどを取り付けることで,のリフトオフ検出も可能だと考えられます.


まとめ

本記事では,光学式センサの問題点と,新しいゲーミングマウスのセンサとしての電磁誘導方式について考えました.

現在,WacomはKC-100などのペンタブレット上で使用可能なマウスをリリースしていますが,ゲーミングを意識した製品ではないため,実際にゲーミングマウスとして運用するのは難しいと思います.また,ポーリングレートの低さや,価格などの問題も存在しているのも事実で,製品化するには様々な課題を解決する必要があるでしょう.

しかし,電磁誘導方式の精度の高さは素晴らしく,電磁誘導方式を採用したゲーミングマウスが出ると,ゲーミングマウスもさらに面白くなるのではないでしょうか.

ゲーミングマウス向けのUSB HIDディスクリプタ

前に3ボタンマウスのデータパスを16Bit化したHIDディスクリプタを紹介しました.
この時のディスクリプタは,3ボタンでX,Y変位がそれぞれ16bitなディスクリプタですが,スクロールホイールの情報は転送できません.

本記事では,そこにスクロールホイールを加えたディスクリプタを紹介します.
USB HID Descriptor (3 button, 16bit data-path, wheel)
これによって,3ボタン(左・中・右クリック),16bitのXY変位,スクロールホイールの変位を転送できることになり,ゲーミングマウスとして最低限必要な情報を転送できます.

送られる情報は8bit×6の配列で,各バイトの情報は以下のようになります.
  • 1バイト目 : ボタンのON/OFF情報
  • 2,3バイト目 : X変位
  • 4,5バイト目 : Y変位
  • 6バイト目 : スクロールホイールの変位

実はこのディスクリプタを使ってポインティングデバイスを開発しました.

この記事もそのデバイス(と市販のキーボード)を使いながら書いています.自前でファームウェアを開発することで,機能の追加や微妙なチューニングができ,とても便利です.入力機器は様々な種類を経て拘りはじめると,「結局自分で作るしか無いじゃん」という展開になりがちですね.
この話を始めるととても長くなるので,またいずれ(書けるといいですが・・・).

2016/12/03

描画遅延とデバイスの出力周期の関係に関する一考察

はじめに

描画遅延(入力遅延とも言います)は,競技ゲームにおけるプレイヤーのパフォーマンスに大きく影響します.本記事は,ゲーミングシステムを構成するゲーミングデバイスやプログラムの出力周期に着目して,描画遅延の定式化を行い,描画遅延を減らすために要求されるシステム要件について議論します.

記事が長いので,「理屈はどうでも良い」という方は最後のまとめの項だけ参照してください.

出力周期

ゲーミングシステムは,ヒューマンインタフェースからの入力を,ゲームエンジンが受け取り,その情報に基いてディスプレイに描画します.これらのデバイスやプログラムはそれぞれ出力周期を持っています.

以下にそれぞれのデバイス,プログラムの一般的な出力周期とその名称を示します.

  • マウス,キーボード,コントローラ
    • レポートレート : 125Hz~1000Hz
  • ゲームエンジン(ゲームプログラム)
    • フレームレート : 30fps~500fps
  • ディスプレイ
    • リフレッシュレート : 60Hz~240Hz

遅延時間の見積もり

単純化した例

遅延時間も見積もるために,単純化した例で議論します.まず,マウスからの入力がリフレッシュレートが1Hzのディスプレイに出力された例を考えます.この時,入力された情報はデバイスやプログラムには即時反映されるものとします.

図1 リフレッシュレート1Hzの場合の遅延時間

図1に,リフレッシュレートが1Hzの場合の遅延時間について,最良・最悪・平均(期待値)の3パターンの入力と描画のタイミングを示します.

図1のように,入力の直後にディスプレイがリフレッシュされる場合,入力結果がディスプレイに即反映されるため,遅延時間は0sとなります.一方,リフレッシュ直後に入力がされる場合,入力結果は1s後にディスプレイに反映されるため,遅延時間は1sとなります.

プレイヤーによる入力のタイミングはランダムであるため,入力のタイミングは一様に分布することになります.したがって,遅延時間の期待値は,0s~1sの中間の0.5sとなります.

このように,遅延時間の期待値はディスプレイの出力周期に依存します.例えば,リフレッシュレートが100Hzの場合,最短の遅延時間は0sであり,最長の遅延時間は0.01sとなります.つまり,遅延時間の期待値は0s~0.01sの中間である0.005sとなります.

以上を踏まえると,1つの出力周期をもつシステムの場合,遅延時間の期待値t[s]は出力周期r[Hz]を用いて以下の式で表すことができます.
t = 1/2r


複数の出力周期が存在する場合

次に,複数のシステムが連なった時の例を考えます.レポートレートが1Hzのマウスとリフレッシュレートが1Hzのディスプレイで構成されている場合を考えます.
レポートレート1Hz,リフレッシュレート1Hzの場合の遅延時間


図2に,リフレッシュレートが1Hzのディスプレイとレポートレートが1Hzのマウスから成るシステムの場合の遅延時間について,最良・最悪の2パターンの入力と描画のタイミングを示します.
それぞれのデバイスは同期をしていないため,それぞれの出力(描画)タイミングはランダムになります.

図2のように,最良のケースでは入力の直後にマウスがレポート,その直後にディスプレイが描画することになり,遅延時間は0sとなります.一方最悪のケースでは,マウスのレポートの直後に入力が起き,1s後に入力された情報をレポートし,さらに1s後にディスプレイが描画するため,遅延時間は2sとなります.
したがって,それぞれのデバイスの同期タイミングと物理的な入力のタイミングを加味すると,遅延時間の期待値は1sとなります.

ゲームエンジンについて考えると,図2のマウスとディスプレイの間にゲームエンジンのタイミングが追加されます.この場合は,ゲームエンジンの出力周期に応じて描画遅延の期待値は増加します.つまり,ゲームエンジンの出力周期(フレームレート)を上げれば,描画遅延の期待値は減少し,フレームレートが下がれば期待値は増加することになります.

以上ように,複数のデバイス/プログラムが出力周期をもつ場合,全体の遅延時間はそれぞれのデバイス/プログラムの遅延時間の期待値の合計になります.


遅延時間の定式化

以上を踏まえると,出力周期に基づいた遅延時間の期待値は以下のように見積もることができます.全体の遅延時間をT[s]とし,それぞれの出力周期をr[Hz]とすると,Tはシステムを構成するデバイスとプログラムの遅延時間tの合計値となるため,以下のようになります.
T = Σ(1/2r)


実際のシステム構成の場合

マウスのレポートレートが1000Hz,ゲームエンジンのフレームレートが200fps,ディスプレイのリフレッシュレートが120Hzである場合は,以下のように遅延時間を見積もることができます.
T = (1/(2*1000))+(1/(2*200))+(1/(2*120)) = 0.00716[s] = 7.2[ms]


出力周期以外の遅延時間(オーバヘッド)

今までの例は,入力された情報をそれぞれのデバイス/プログラムがすぐに次のデバイス/プログラムに渡せる場合を考えてきました.しかし,実際のシステムにおいては,出力周期以外の遅延時間(本記事ではオーバヘッドと呼びます)が存在しています.
今回は以前行った測定データ(図3)から,それらのオーバヘッドを見積もることにします.

図3 ゲームタイトルごとの描画遅延
※測定方法/環境については当該記事参照

まずは,Baselineのプログラムについて考えます.このBaselineのプログラムは4300fps程度で動作します.したがって,出力周期から見積もれる遅延時間は,
T = (1/(2*1000))+(1/(2*4300))+(1/(2*120)) = 0.00478[s] = 4.8[ms]
となります.しかし,実際に測定された描画遅延の時間は8.4msです.したがって,残りの3.6msはUSBホストコントローラ,OS,OpenGLのAPI,グラフィックカード,ディスプレイなどがもつオーバヘッドであるといえます.

次に,CS:GOのSource Engine自体がもつオーバヘッドについて考えます.CS:GOのde_dust2は私の環境ではおよそ200fps程度で動作していたと思うので(うろ覚えですいません),出力周期から見積もれる遅延時間は,
T = (1/(2*1000))+(1/(2*200))+(1/(2*120)) = 0.00716[s] = 7.2[ms]
となります.ここに測定環境のオーバヘッド3.6msを足した10.8msが出力周期とシステムのオーバヘッドから予想できる描画遅延ですが,実際は15.7msとなっています.この差のゲームエンジン自体のオーバヘッドである4.9msは,OSから受け取ったマウスの変位からカメラの姿勢計算などを行い,グラフィックカードへのデータ転送,グラフィックカードが描画処理(ラスタライズ,シェーディング,ポストプロセスなど)を行うための時間だと考えられます.

CS1.6はフレームレートの制限があり,全体の描画遅延はCS:GOと大きく変わりませんが,フレームレート制限の分を加味すると,ゲームエンジン自体のオーバヘッドはCS:GOと比較して小さいと言えます.この差は,CS1.6からCS:GOでグラフィックがリッチになった影響で,グラフィックパイプラインがより深くなり,ゲーム内の内部処理もより複雑になったためだと考えられます.

ゲームエンジンの高度化,グラフィックのリッチ化は多くの一般的なプレイヤーにとって利益になります.しかし,コンペティティブなタイトルでは描画遅延の増加というトレードオフも存在しており,競技性を意識したタイトルでは慎重に調整するべきだと思います.


遅延を減らすためにプレイヤーができること

遅延時間を少なくするためには,それぞれの出力周期を上げる必要があります.
つまり,マウスに関して言えば,レポートレートをできるだけ高くすることです.デバイスの設定によって1000Hzや,設定できるのならそれ以上の値に設定します.
また,プロセッサとメモリを高速なものに移行することと,ゲーム内設定をできるだけ低負荷なものにすることでフレームレートを上げるのも有効です.
そして,リフレッシュレートの高いディスプレイに置き換えることも有効でしょう.
デバイスやディスプレイを買い換える場合は,余計な遅延が発生するようなものは避けることが必要です.

特に,フレームレートはゲームの設定を調整するだけで容易に改善できます.フレームレートを上げるには,レンダリング解像度やテクスチャ解像度,シェーディングなどの設定を下げるとよいでしょう.グラフィック設定は基本全部低設定にして,視認性に影響を与えない範囲でレンダリング解像度を下げるというのがよいでしょう.


まとめ

まとめます.

  • 出力周期に基づく描画遅延時間の期待値はΣ(1/2*出力周期)で表すことができる
    • 遅延時間はそれに加えて,プログラムの計算時間やデータ転送時間などの要素で増加する
  • 出力周期を小さくすることで描画遅延時間を小さくできる
    • デバイス
      • デバイスのレポートレートを上げる
      • レポートレートの高いデバイスを買う
    • ゲーム(エンジン)のフレームレートを上げる
      • CPU・メモリ・GPUを高速なものに買い換える
      • グラフィックの設定(解像度,その他)をできる限り下げる
    • ディスプレイのリフレッシュレートを上げる
    • リフレッシュレートの高いディスプレイに買い換える
  • 描画遅延の中でオーバヘッドが占める割合は大きく,プレイヤーが出力周期を上げることで対応できる範囲は小さい
    • 描画遅延を極限まで小さくするには,より小さいオーバヘッドのシステムを考える必要がある
      • 今までのソフトウェア資産を失うことになるため,システムのアーキテクチャ自体を大きく変える事はとても難しい
      • オーバヘッドの小さいゲームエンジンを高く評価するような雰囲気づくりが必要