Overwatchのウィンドウモードごとの遅延

先日Twitterに書きましたが，Overwatchの描画遅延を測定しました．この検証により，どのウィンドウモードでプレイするのが「最も強いのか」ということを解き明かしました．
また，Windows10にアップデートしたので，ゲーマーにおけるWindows 10の最大のテーマ「Aero 3フレーム遅延説」についても簡単に議論します．

測定方法

測定方法は今までの記事と同様で，視点を左右に動かすようなデータをHID Device経由で送信すると同時に，LEDを点灯させます．ここで，LEDの点灯(HID Deviceのモーション送信)からディスプレイの映像が実際に動き始める時間を描画遅延とします．LED点灯からディスプレイの映像が動き始めるまでは数十msしかないので，Nikon1 V1のスローモーション撮影機能を用いて1200fpsで撮影しておきます．撮影されたスローモーション映像をPCでコマ送りで確認することで，描画遅延の時間を測定します．

この手順で，フルスクリーン・枠なしウィンドウ(フルスクリーンウィンドウ)・ウィンドウの3種のウィンドウモードの描画遅延を測定します．

評価環境 Experimental Setup

評価環境の概要は以下のようになります．OSとHID Deviceが変更になりました．

• PC
• OS : Microsoft Windows 10 Home
• CPU : Intel Core i7 2600 (HT Enable)
• GPU : NVIDIA GeForce GTX670
• Display : BenQ XL2410T (120Hz)
• Camera : Nikon1 V1 with 1 NIKKOR 10mm F2.8
• F : 2.8，SS : 1/1250s
• HID Device : CY8CKIT-059 PSoC 5LP Prototyping Kit (CY8C5888LTI-LP097)
• Overwatch Settings
• Resolution : 1920x1080 120Hz
• Render Scale : 50%
• Graphic Settings : Low or OFF
• V-Sync : OFF

評価結果 Experimental Results

まず，測定したデータを時系列にまとめたものを図1に示します．

図1 時系列の遅延データ

図1のように，ディスプレイのリフレッシュレートが低いため描画遅延のフレーム数がバラけています．
また，Fullscreen(青線)では測定回が奇数の場合と偶数の場合で1フレームほど数値が異なります．
(※なぜこういう傾向になったのかは不明です．データは一発取りなのでもう少し詳しく測定する必要がありそうです．)

図1は描画遅延のフレーム数なので，わかりやすいようにミリ秒に換算し，平均値を出します．
Nikon1 V1のスローモーション撮影は1200fpsなので描画遅延の時間は，

描画遅延時間[ms] = 描画遅延のフレーム数×(1/1200)×1000

となります．この描画遅延時間から平均値を出したものが図2になります．

図2 描画遅延の平均時間

また，奇数/偶数を考慮した場合の平均値は図3のようになります．

図3 奇数/偶数を考慮した描画遅延の平均時間

図2，3のように，フルスクリーンの時が最も描画遅延が少ないです．要するに，フルスクリーンのほうが敵が早く見える上に，マウスの動きと画面の動きのラグが少なくなるのでAimもしやすいということになります．

Aero 3フレーム遅延説@Windows10

いわゆるAeroが有効だと，この環境では2フレームの遅延の差があると言えます．
(奇数偶数を考慮しない場合は1フレームですが，おそらく考慮した方が正しいデータであると考えています．)
Windows 10はWindows 7のようにAeroを明示的に切ることができないので，コンペティティブなタイトルは基本的にフルスクリーンに設定するのが無難だと言えるでしょう．
Windows 7のようにAeroを切れるOSであれば，そこまで大きな遅延は発生しないのですが・・・(それでもフルスクリーンが最速です)

参考 : Win8.1で測定されたデータ http://www58.atwiki.jp/grassan/pages/17.html

Overwatchのゲームエンジンは低遅延なのか?

今回の測定にあたり，OSをWindows7 → Windows10へと変更したため，他のゲームエンジンとの描画遅延の優劣は比較できないと考えています．

ただ，Windows7の時のデータを参考に考えるとOverwatchのエンジンはSource Engineと比較して大きな差はなく，結構リッチなグラフィックである割に低遅延なエンジンであると言えます．

まとめ

まとめます．

• この環境では，フルスクリーンが最良
• Windows 10ではウィンドウモードでは2(?)フレーム遅延する
• 他のタイトルでも調べる必要がある
• Overwatchのゲームエンジンは低遅延な部類だと思われる
• (コマ送りで動画を再生して確認するので，とてもめんどくさい)

Appendix

撮影した動画を掲載します．

USB HIDマウスのデータパスの16bit化

前からPSoC Creatorの3-button Mouseのサンプルのソースコードを弄って色々(これとかこれ)やってましたが，このサンプルはデータパスが8bitなので1回のポーリングで-127～127の範囲の値しか送れませんでした．そこで，データパスを16bit化することにしました．
16bit化することにより，最近のゲーミングマウスと同レベルの値の範囲を使用することができるようになるので，色々と調査が捗るはずです．

しかし，USB HID Noobな私にとっては「どこを弄ればよいのかさっぱり・・・」という感じでネットの海を彷徨うこと数時間・・・
Zowie EC2 EVOのディスクリプタを参考にすることでなんとか解決しました．
参考 : Zowie mouse wheel scroll up/down not working
(このログを出したアナライザー欲しいんですけど1ライセンス$200なんですよね・・・とりあえずはUSBViewとMicrosoft Message Analyzerで誤魔化しています)

デバイスが応答しなくなる問題の対策

ディスクリプタを弄りながらデバイスを何度も接続していると，デバイスの反応がなくなることがありますが再起動すると治るようです．

HID ディスクリプタの設定

最終的なHID Descriptorの設定は以下のようになりました．
(PSoC Creatorの3-button Mouseのサンプルから変更した部分は青線で囲んだ部分だけです．)

ディスクリプタの簡単な解説

前半がボタン関係です．3-button Mouseなので，ボタンのUSAGE_PAGEが3つあり，USAGE_MINIMUMが1でUSAGE_MAXIMUMが3，REPORT_COUNTが1になります．
ボタンは0/1しか表現できないのでLOGICAL_MINIMUMが0，LOGICAL_MAXIMUMが1となり，REPORT_SIZEが1になります．
3ボタンマウスだと，ボタンの状態表現に3bitしか必要ないため，余った5bitをパディングします(中段)．

後半がカーソル関係のディスクリプタで，USAGE_PAGEはGeneric Desktop Controls(0x01)になります．USAGEは0x20がX軸で0x21がY軸です．
データパスを16bit化するので，LOGICAL_MINIMUMを-(2^15-1) = -32767 (0x8001)にして，LOGICAL_MAXIMAMは2^15-1=32767(0x7FFF)になります．また，REPORT_SIZEを16にします．
ここで，REPORT_COUNTは変更の必要はなく，XとYの2軸なので2になります．
(ちなみに，データパスが8bitの場合はLOGICAL_MINIMUMが-127，LOGICAL_MAXIMUMが127，REPORT_SIZEが8になります．)

コード

ボタンの状態を1byte(3bit+5bitパディング)，X軸で2byte，Y軸で2byteになるので，USBFS_LoadInEP()に渡す配列は5byteになります．
例 : uint8 mouseData[MOUSE_DATA_LEN] = {0u, 0u, 0u, 0u, 0u}
この場合だと，{ボタン，X軸下位8bit，X軸上位8bit，Y軸下位8bit，Y軸上位8bit}という風になります．

X軸の変位をdxとして場合はこんな感じで代入すれば良いと思います．(あまりオーバーフローとか考慮してないですが・・・)
mouseData[1] = (uint8)dx;
mouseData[2] = dx >> 8;

ポーリングごとにdxを1ずつ増やしたり減らしたりするようなコードを書くと，こんな感じの応答になりました．

図のように，8bitデータパスの限界値である±127を超えてデータを送ることができています．

※超絶初心者なので，この記事の記述は間違っている可能性があります．