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

はじめに

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

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

出力周期

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

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

• マウス，キーボード，コントローラ
• レポートレート : 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を高速なものに買い換える
• グラフィックの設定(解像度，その他)をできる限り下げる
• ディスプレイのリフレッシュレートを上げる
• リフレッシュレートの高いディスプレイに買い換える
• 描画遅延の中でオーバヘッドが占める割合は大きく，プレイヤーが出力周期を上げることで対応できる範囲は小さい
• 描画遅延を極限まで小さくするには，より小さいオーバヘッドのシステムを考える必要がある
• 今までのソフトウェア資産を失うことになるため，システムのアーキテクチャ自体を大きく変える事はとても難しい
• オーバヘッドの小さいゲームエンジンを高く評価するような雰囲気づくりが必要

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

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

DPIと振り向きとセンシティビティ

DPI × sensitivity ∝ 振り向き

という関係は一般的に知られています．例えば，400 DPIのsensitivity 2と800 DPIのsensitivity 1は振り向きが等しいということになります．概ねこれは正しいのですが，一点だけ注意点があります．

それは，DPIを下げれば下げるほど，視点の回転が荒くなるという点です．

簡単な例を動画にしてみました．
まずは比較的一般的な1000 DPI，sensitivity1という設定です．

絶望的なまでのAimの悪さを除けばごくごく普通の視点操作ですね．

次に10 DPI，sensitivity 100という設定です．

非常にガクガクとした視点の移動ですね．特に動画の後半では，Aim出来る位置に頭がないので，Aimを合わせることができていません．


2つの動画は「ほぼ」振り向きの距離は同じですが，視点移動の粗さが大きく違うことが分かります．

これは非常に極端な例ですが，実際のもサブピクセル単位ではこれと同じ現象が起きています．つまり，ごくごく微小な範囲では，例と同様に低DPIだと欲しい角度に向くことが出来ていない可能性があるのです．
これが私がプロプレイヤーの中で一般的な400DPIという設定を倣わずに，750DPIや1000DPIに設定している理由です．

特にハイセンシなプレイヤの場合，400 DPIなどの低DPIにしてインゲームのsensitivityを上げるような設定は極力避けたほうが良いでしょう．

CS:GOの視点回転処理

CS:GO互換な視点回転をするアプリを書く時に考える必要があるのが「マウスからの変位1 countに対して，どれだけ視点が回転されるか？」というパラメタです．このパラメタが分かればCS:GOのsensitivityの設定と互換アプリのsensitivityの設定を合致させる事ができます．

というわけで実験してみましょう．
CS:GOでは，コンソールからcl_showposを1とすることで，自分の視点の角度を見ることが出来ます．

左上に位置情報と視点の回転角，速度が表示されています

小数点第2位まで表示されているので，有効数字4桁まで取れそうですね．
ちなみに-180～180までの値を取っているので単位はdegreeだということが分かりました．3D系のAPIって大体はradianだと思うのですが・・・ちょっと意外です．

sensitivityが1～10程度の低い値だと，1 countあたりの回転角が非常に小さいので有効数字を使い切るような計測ができません(本当はUSB HIDを作って1000countとか転送すれば良いんですけどね)．
そこで，sensitivityを1000として設定して1 countだけ視点を動かします．

スタート地点

1countだけ水平方向に回転

7.44から27.44になりました．つまり，sensitivity 1000の状態では，1 countで20.00度回転することになります．また，sensitivity 1の場合では1countで0.02度回転します．

ちなみに垂直方向も同様の回転量でした．

以上より，大抵の3D APIはradianを使うことになるので，フレームあたりの回転量は，

フレームあたりの回転量 = sensitivity * 0.0003491 * フレームあたりのcount数

と求めることができますね．垂直方向に関しても同様の式で回転量を求める事ができます．

加速理論とその後の周辺

はじめに

私の現在のマウス加速の設定とその設定の考え方について紹介します．

関連記事

#LogicalGaming: 加速理論とその周辺
ゲーミングにおけるマウス加速は有効にするべきか，それとも無効にするべきかという是非について議論しました．

rafalog: マウスアクセル調整ツール Interaccel紹介
rafa様によるInteraccelの紹介記事です．

rafalog: Interaccelセッティングガイド
rafa様によるInteraccelの設定方法のガイドです．

パラメタの設定方法

私は無加速時のセンシティビティを基準に設定しました．

私はCSGOをsensitivity 1.0，加速オフでプレイしていました．DPIが750の時で180度振り向くのにおよそ35cmほどです．
400DPI換算だとsensitivity 1.875程度ですね．プロプレイヤーの平均的コンフィグと比べると少し低いですが，私は左利きなのに右手でマウスを扱っている上に，身体を操作する能力が高くないので「こんなもんかな」と考えています．

この35cm/180°というセンシティビティは，私がFBを回避できるくらいの速さで視点を回すことができ，かつ遠距離でもHSを狙っていけるギリギリのラインです．
欲を言えば，500DPIのほうが遠距離の精密射撃は安定するのですが，500DPIだとFBの回避やクロスレンジでの撃ち合いがかなり厳しいです．対して，1000DPIだとクリアリングやFBの回避はスムーズに出来ますが，不調時にAimingの精度が低下し安定感がありません．

したがって，500DPI～1000DPIの「いいとこ取り」をしようということで加速を設定しました．

数時間の調整でこのようになりました．まずマウスのDPIを1000DPIに上げました．
そして，低カウント時に500DPIとなるようにPost-ScaleX，Yを0.5に設定しました．
Acceleration値は低めの0.05にしました．色々試してみたのですが，無加速時の設定に慣れすぎたためか，数値を0.1や0.2にすると違和感が大きかったです．
以上で右のグラフのように，1Count/Pollingの時に500DPI，20Count/Pollingの時に1000DPIになるような設定になります．

また，現状では，Acceleration値が低いためSensitivity Capが入れていません．今後入れるかもしれませんが・・・．Acceleration値を高く設定する場合は必須だと思います．

経過観察

Aimは無加速時の水準に戻すまでに2，3日かかりました．Aim戻し方はブランクがあった時と同じですね．ACEやいい感じのフラグシーンもそこそこ出ているので，あとは今後の慣れ次第だと思います．
加速を入れるとAWPが当たらなくなるイメージがあったのですが，そうでもないようです．

余談ですが，無理にマウスを振らなくて良くなったのでSurfがかなりやりやすくなりました．

おまけ

加速理論とその周辺

FPSシーンのデバイスのセッティングでは
マウス加速はOFFにすべきである
ということが基本的事項として言われています．

私も現状の設定では加速なしでプレイしているので，加速なし派の支持者と言えるのですが，デバイスについての知識が増えるに従ってもう一度加速について考えるべきだと感じています．

機械的な視点で考えると，

• 異なる応答特性をもつ複数のアクチュエータ
• 肩，腕，指の筋肉
• 複数のジョイント
• 肩，肘，手首，指

を用いて作業点(マウス)を動作させているので，非常に複雑な構成のシステムです．

また，アクチュエータである筋肉の電流応答を見てみましょう．

[1]

肩，腕，手の筋肉が一概にこういう特性だ，ということを断言するわけではありません．しかし，少なくともマウスを動かすのに使う筋肉も「線形応答ではないはず」という予想はできます．

そして，制御系(脳)自体も，状況に応じて様々な神経からのフィードバックと神経の遅延を加味しながらアクチュエータを制御しています．こうしたシステムで，「最終的に系全体では線形になっている」もしくは「線形な特性をもつポインタを使用するべき」と主張するのは難しいと考えています．

また，私の考えていた加速なしにしていた一つの理由として，
脳は移動量を関節角のフィードバックを元にしているはずであるので，いかなる速度で動かしても一定の関節角の動きを取る加速なしが優れている
という考えがあります．しかし，前述のとおり関節の構成は複雑です．
また，関節の長さもポイントとなります．例えば肘から作動点まで40cmだとすると，1mm平行移動させる場合の肘関節の角度差は0.14°となります．私は，複数の関節からのフィードバックを0.1°単位で加味しながら制御しているとは考えられません．
そしてプレイ中に意識して考えると，どちらかというと視覚からのフィードバックを重視しており，そこから筋張力を制御しているように感じます．したがって，実は関節角によるフィードバックは重要度が高くないと考えるようになりました．

これらを勘案すると，「加速は入れるべき」なのではないかということが分かってきます．

加速なしv.s.加速あり

それぞれのメリット・デメリットはrafa様の記事の通りなので是非参照してください．
私の経験から要点をまとめると以下のようになります．

• 加速なし
• ハイセンシ
• 成績にムラが出やすい
• 近距離に強く，遠距離に弱い
• 多くのタイトルで初期状態ではハイセンシ状態である
• 初心者にハイセンシのプレイヤーが多い
• ローセンシ
• 成績が安定する
• 遠距離に強く，近距離に弱い
• ミドルセンシ
• ハイ・ローの中間的な特性だが，近距離ではハイセンシに負け，遠距離ではローセンシに負ける
• 加速あり
• 習熟に時間が掛かる
• 極めれば(恐らく)不得手なレンジは無くなる
• 「加速特性」という複雑なパラメタを自分に合わせてチューニングする必要がある

加速特性

ちなみに「どのようなパターンの加速特性とするべきか」という問題に関しては，非常に難しい問題なので今後のユーザの試行錯誤に期待していきたいです．
さしあたり，現状で分かっている点から加速特性について少しだけ考えてみましょう．

低速域の場合，例えばの話ですが，右に3カウント動かした後に左に4カウント動かす，というのを瞬時に間違いなくやってのける人はあまりいないでしょう．400dpiだとすると，1カウントで0.06mmとなりますが，誤差±0.03mm単位で物を正しい場所に動かすのは難しいです．そういう意味では低速域ではセンシティビティを下げるべきだと考えられます．

高速域では，低中速域でのセンシティビティに大きく依存すると考えています．低中速域でのセンシティビティが低い場合，高速域では大きな力が必要となります．全力で投げるよりも8割の力で投げた方がコントロールしやすいですよね．したがって，中高速域ではある程度の加速をかけて全力で動かさなくても高速に視点が動作するようにすると良いでしょう．

問題点

「加速なし」の圧倒的なメリットとして，「振り向きを一度測れば，すべてのタイトルでセンシティビティを統一できる」というものが挙げられます．基本的にはrawinputを有効にするか，OS側の加速を切ってゲーム内の加速を切ることで加速なしの環境は構築できるのです．そして，使い慣れた振り向きになるようにセンシティビティを調整すればOKです．
ついでに言えば，ゲームエンジン毎に振り向きを計りながらセンシティビティを調整するのは面倒なので複数のタイトルで設定値を統一して欲しいですが．

加速ありで問題となるのが複数タイトルでのセンシティビティを合わせにくいというものです．私も一時期マウス加速を試していた時期があったのですが，複数タイトルでのセンシティビティが合わせにくいという理由で止めています．
インゲームの加速機能を使用すると，エンジンによる加速のかかり具合によってセンシティビティが統一できないという問題があります．また，rawinputしか選べないタイトルも存在するかもしれないのでOS側で設定するというのも難しい話です．

こうした問題を解決するには，複数タイトルに対応した統一的な加速特性設定の規格が必要なのだと思います．

さしあたっての解決法は，QL Mouse Accel Driverなどでドライバレベルで加速をかけることです．しかし，導入が少々面倒という点があります．

または，マウスレベルでの制御を行うことです．加速を掛ける段階でカウントをうまく縮尺させれば，整数型でも加速をつけることができるのでFPUを搭載していないマイコンであっても，問題にならないレベルの演算時間だと見積もることができます．マウスレベルで加速をかけることで，ネットカフェやオフラインなどの環境でも自分の加速特性を利用することができます．
しかし，こちらはファームウェア毎に異なる方法で加速をかけることになるので，複数のマウスを頻繁に取り替える場合などを想定すると，これもまた統一した規格が必要になると考えられます．

[1] 板倉直明,久保公人,井口弥寿彦,南谷晴之: "電気刺激による筋張力制御系の安定性の評価" 電子情報通信学会論文誌. J72-DII. 1543-1549 (1989)

ブランク後のAimの戻し方

7月は「その日その日の締切のタスクを消化していたら，気がついたら終わっていた」という感じで，ほとんどシュータープレイできませんでした．

ここで問題となるのは，「ブランクの後にAimを元の水準に戻すにはどうするのか？」というところ．

前に書いた記事の通り，毎日継続してまとまった時間プレイすることが重要であるのは分かっているので，今回は意図的に長時間プレイすることにしました．
初日は，Aim調整のみ，ピストル20分，デスマッチ20分，2vs2を1.5時間くらいでしょうか．
ここで，画面が思ったより遠くにおいてあることに気が付いて画面を近づけたり，センシを調整したりしました．

翌日はピストルを20分，デスマッチ20分程度してからMMをプレイしました．
3試合連続でACE(1ラウンド中で5人全員を一人で倒すこと)を出したり，前の水準よりも良いんじゃないかというくらいになりました．Aimは思っていたよりも速く戻るものなのだなと思いました．

ここまで来ると完全なる日記ですが，色々ネタはあるので8月はボチボチブログの更新をしたいと思います．Globalの方も1本か2本あげたいところですね．

マウスパッドの相性問題をマウスソールの厚さを変えることで解決してみる

先日，Artisan 紫電改を購入したのですが私のG300rではうまくトラッキングが出来ないという問題がありました．症状としては，G300rの低速移動時にカーソルが意図していない方向に動きます．また，高速移動時も意図しない方向に飛ぶことが多々あり，事務作業にすら使用できないレベルでした．
結論から言うと厚めのソールを使っていたことが原因でしたが，そのデバッグの様子を書いてみます．


とりあえず，なぜトラッキング出来ないのか調べます．
まずは，この装置(マウスの光学センサが見ている世界を見てみる)を使って表面の様子を見ます．

当該記事で他のマウスパッドと見比べていただければ分かりますが，紫電改はコントラスト比が低く「のっぺり」とした表面でかなり「悪い」部類に入ります．
確かに，カタログスペックが低いADNS-3050系センサではトラッキングするのが厳しいのもうなずけます．

しかし，どうしても紫電改が使いたいので諦めずにトライしましょう．
特徴点を増やすように試行錯誤してみたところ，基板を強く押し付けた場合( -0.1～0.2mm )に良好な結果が得られることが分かりました．

たった0.1mmか0.2mm程度の差ですが，もはや別のマウスパッドに見えます．コントラスト比が上昇したのと，表面の若干低い位置にある小さな粒状の突起にハイライトが見えるようになりました．
この結果を元にG300rのソールを薄いものに変更したところ，低速時のトラッキングエラーはほぼ無くなりました．

この装置的には，上の図の状態でソールを外してある上に，マウスパッドに押し付けていますので，メーカ設計の値の-0.5mmくらいの位置です．かなりフォーカス位置が外れている印象ですね．

まとめ

• 0.1mm単位でソール厚を追い込むことで，トラッキング性能が向上
• 相性問題をFixできることも
• 付属ソールと同じ厚さにしておくのが無難
• 3D系の表面の場合はちょっと薄めにすると良くなるかも

マウスパッドの相性問題に悩まされる場合は，ソール厚を変更することで実用レベルまでに改善することがあるので是非お試し下さい．

※今回は「ソール薄くする」ことで解決しましたが，一概に薄くすれば良いというわけでもないと思いますので色々試行錯誤してみてください．

Logitech G400 のデータパスを解析してみる

--------------------------------------------
2015/05/31 初出
2015/06/04 rafa様の関連記事を追記
--------------------------------------------
rafa様の記事(-rafalog: 鼠とオシロ)に便乗する形でLogitechの名機であるG400のデータパスをマイコンを使って覗いてみました．

ハードウェア (Hardware)

ハードはこんな感じに，ポリウレタン線でMISO，MOSI，SCLK，SSをセンサのピンから引き出します．

基盤が載っている筺体が違うことに気がついた方は相当の鼠ソムリエですが，コイツです．筺体のデザインに関しては，今まで触った100種以上(店頭で触ったものも含む)のマウスの中で最も良いです．
「ワクワクしながら家に持ち帰ったら，センサー性能と実装に絶望した」という悲しい過去があります．事務用マウスも一応ウォッチしていると良いことがあったりなかったりですね．

極めて良い筺体形状なので，一年ほど前にG400の基盤を無理やり載せました．その作業内容や顛末とかも記事にすると面白そうですが，「ひたすら筺体と基盤を弄って物理的・電気的整合性をとるだけ」という単純作業なので割愛します．基盤にメモが書いてあるのはその時の名残です．

マイコンはいつもの CY8CKIT-042 PSoC® 4 Pioneer Kitを使用します．このキットは色々な所で売っています．(秋月)

ソフトウェアの実装(Software implementation)

IDEは，PSoC Creator  3.0 SP2 (3.0.0.3140)を使用します．コードは全世界に公開できるクオリティに達していないので，「見たい」という奇特な方はご連絡を・・・ということで．
データのキャプチャにはSPI Slave コンポーネントを使用します．このコンポーネントはMaster(MCU)にぶら下がってSlaveとして振る舞います．MCUと本当のSlaveであるセンサ間でのみ通信が行われるので，全バイトデータをキャプチャすればMCUとセンサのやりとりを(理論上は)キャプチャできます．

図のように，2入力(マウス側のMOSI，MISO)をORゲートのコンポーネントで論理和にし，SPI SlaveのMOSIに入力します．SCLKとSSはマウスから引っ張ってきたものをそのまま使用します．このコンポーネントからマウスへのデータ転送は行わない(というよりMasterはG400の基板上のMCUなのでデータを送ると何が起きるか分からない)ので，NC(No Connect)とします．

SPI Slaveの設定はこんな感じにします．

ADNSシリーズはCPHA=1，CPCL=1なのでそのように設定します．ビットレートは1.5Mbpsとします．
もし違うマウスで調べる場合は，対象マウスのMCUからでているSCLKのビットレート調べて，それと同じ値にする必要があります．他の項目はDefaultで問題ありません．

プログラム

プログラムは，MCUかセンサからデータが来たら保存するという事を2000byte分行うだけです．

データレートも見たいので，2000byte分の取得の開始時間と終了時間もTimerを使用してマイクロ秒単位で記録しておきます．
2000/取得にかかった時間 でデータレートを算出できます．

データ (Data Result)

データは本来は2000バイト取得していますが似たようなデータは割愛しています．
もし，特定の条件でのデータが見たいという奇特な方がいらっしゃればコメントして下さい．

データレート(Data Rate)

以下がデータレートの測定結果です．

Stream Read Info ->
Size    :       2000
Start   :       5814 us
End     :       17684 us
Time    :       11870 us ( 12 ms )

Data Rate : 168 Byte/ms

このように，約12msの間に2000Byteをやりとりしていることが分かります．つまり，1msあたり168Byte程度になります．MotionBurstはMCUがセンサに1Byte分の命令を送り，7Byte分のデータを受け取るので，1通信に8Byteのやりとりが発生します．(詳しくはデータシートのMotion Readの項を参照)
これらを勘案すると，MCUはセンサーへ1msの間に複数回アクセスしている可能性が高いと言えます．168/8=21なので，大体20回変位データを取得してるんじゃないの？と考えられます．とりあえず生データを見てみましょう．

2015/06/04追記
rafa様がオシロスコープでRazer Abyssusの解析をしてくださいました．
-rafalog: 初代AbyssusのSPI通信解析
これを見ると，AbyssusはMotion→Delta_X→Delta_Yレジスタの転送をしたところで，NCS(SS)をプルアップして強制的に転送を止めています．確かに，これだと変位のスループットが稼げます．記事によると，Abyssusは1msで6回程度アクセスしているようです．
データシートには「転送後にNCSをHIGHにする必要がある」，とは書いてありましたが「転送中にNCSをHIGHにすれば転送を中断できる」ことには気づきませんでした．ゲーミングデバイスは奥が深いですね．

生データ(Raw Data)

以下から生データになります．前半はマウスが静止している時のもので，後半はマウスを動かしている時のものです．静止時はMOSIのみとMISOのみのものも取りました．

移動中に0x80になっている部分は，Motionレジスタなので7bitが1になっているはずなので，本当は0xf0になります．つまり，データのキャプチャが1Clock分遅れており，データが微妙にずれているという結果になります．もう少しちゃんと書く必要がありますね．

MOSI&MISO (No Motion)

55 50 00 00 00 bd 00 50 00 00 00 0a 01 1f 55 50 00 00 00 50 00 00 00 3d c3 0a 01 1f
55 50 00 00 00 bd 00 50 00 00 00 0a 01 1f 55 50 00 00 00 50 00 00 00 3d c3 0a 01 1f
55 50 00 00 00 bd 00 50 00 00 00 0a 01 1f 55 50 00 00 00 50 00 00 00 3d c3 0a 01 1f
55 50 00 00 00 bd 00 50 00 00 00 0a 01 1f 55 50 00 00 00 50 00 00 00 3d c3 0a 01 1f

MOSI (No Motion)

55 00 00 00 00 00 00 00 00 00 00 00 01 00 55 00 00 00 00 00 00 00 00 00 c3 00 01 00
55 00 00 00 00 00 00 00 00 00 00 00 01 00 55 00 00 00 00 00 00 00 00 00 c3 00 01 00
55 00 00 00 00 00 00 00 00 00 00 00 01 00 55 00 00 00 00 00 00 00 00 00 c3 00 01 00
55 00 00 00 00 00 00 00 00 00 00 00 01 00 55 00 00 00 00 00 00 00 00 00 c3 00 01 00

MISO+Data Offset (No Motion)

※MOSIのデータで1列目のバイトを決めているので，MISOのみのデータは行がずれています．
00 50 00 00 00 3d 00 0a 00 1f 00 50 00 00 00 bd 00 50 00 00 00 0a 00 1f 00 50 00 00
00 50 00 00 00 3d 00 0a 00 1f 00 50 00 00 00 bd 00 50 00 00 00 0a 00 1f 00 50 00 00
00 50 00 00 00 3d 00 0a 00 1f 00 50 00 00 00 bd 00 50 00 00 00 0a 00 1f 00 50 00 00
00 50 00 00 00 3d 00 0a 00 1f 00 50 00 00 00 bd 00 50 00 00 00 0a 00 1f 00 50 00 00

Low Speed (MOSI&MISO)

-----Stream-----
55 50 80 00 fa bd 00 50 80 ff fd 0a 01 1f 55 50 80 00 fd 50 80 00 fb 3d c3 0a 01 1f
55 50 80 00 fc bd 00 50 80 00 fb 0a 01 1f 55 50 80 ff fd 50 80 00 fa 3d cb 0a 01 1f
55 50 80 00 fe bd 00 50 80 00 fa 0a 01 1f 55 50 80 00 fb 50 80 00 fb 3d c3 0a 01 1f
55 50 80 00 fe bd 00 50 80 00 f9 0a 01 1f 55 50 80 00 fc 50 80 00 fb 3d c3 0a 01 1f
55 50 80 00 fd bd 00 50 80 00 fd 0a 01 1f 55 50 80 00 fb 50 80 02 fa 3d c3 0a 01 1f
55 50 80 01 fd bd 00 50 80 00 fc 0a 01 1f 55 50 80 01 fb 50 80 01 fc 3d c3 0a 01 1f
55 50 80 01 f9 bd 00 50 80 01 fc 0a 01 1f 55 50 80 00 fb 50 80 00 fc 3d cb 0a 01 1f
55 50 80 02 fa bd 00 50 80 00 fb 0a 01 1f 55 50 80 02 fc 50 80 01 fb 3d c7 0a 01 1f
55 50 80 02 fb bd 00 50 80 00 fb 0a 01 1f 55 50 80 02 fb 50 80 01 fb 3d c3 0a 01 1f
55 50 80 00 fb bd 00 50 80 03 fa 0a 01 1f 55 50 80 01 fc 50 80 01 fb 3d c3 0a 01 1f
55 50 80 03 fa bd 00 50 80 01 fc 0a 01 1f 55 50 80 01 fb 50 80 00 fc 3d c7 0a 01 1f
55 50 80 03 fa bd 00 50 80 01 fa 0a 01 1f 55 50 80 02 fa 50 80 02 fd 3d cb 0a 01 1f
55 50 80 01 fa bd 00 50 80 03 fb 0a 01 1f 55 50 80 01 fa 50 80 03 fa 3d c3 0a 01 1f
...
-----Stream END-----

Middle Speed (MOSI&MISO)

-----Stream-----
55 50 80 06 1c bd 00 50 80 06 1c 0a 01 1f 55 50 80 07 24 50 80 04 1e 3d c7 0a 01 1f
55 50 80 05 1b bd 00 50 80 04 1d 0a 01 1f 55 50 80 04 1d 50 80 05 26 3d cf 0a 01 1f
55 50 80 02 1e bd 00 50 80 00 1e 0a 01 1f 55 50 80 fe 1c 50 80 04 26 3d c7 0a 01 1f
55 50 80 02 1d bd 00 50 80 00 1f 0a 01 1f 55 50 80 00 1e 50 80 00 1d 3d c7 0a 01 1f
55 50 80 00 28 bd 00 50 80 00 1d 0a 01 1f 55 50 80 ff 1e 50 80 00 1d 3d c7 0a 01 1f
55 50 80 00 29 bd 00 50 80 01 1d 0a 01 1f 55 50 80 fe 1c 50 80 00 1e 3d c7 0a 01 1f
55 50 80 fc 28 bd 00 50 80 01 1f 0a 01 1f 55 50 80 ff 1c 50 80 ff 1c 3d cf 0a 01 1f
55 50 80 fc 1f bd 00 50 80 01 1d 0a 01 1f 55 50 80 fe 1c 50 80 fb 1e 3d c7 0a 01 1f
55 50 80 fc 1e bd 00 50 80 fc 1d 0a 01 1f 55 50 80 fa 27 50 80 fc 1e 3d c7 0a 01 1f
55 50 80 fb 1c bd 00 50 80 fb 1e 0a 01 1f 55 50 80 f8 26 50 80 fa 1d 3d c7 0a 01 1f
55 50 80 fa 1e bd 00 50 80 fa 1d 0a 01 1f 55 50 80 f9 1a 50 80 f7 27 3d c7 0a 01 1f
55 50 80 f9 1c bd 00 50 80 f7 1c 0a 01 1f 55 50 80 f9 1c 50 80 f8 1c 3d cf 0a 01 1f
55 50 80 f4 23 bd 00 50 80 f8 1c 0a 01 1f 55 50 80 f9 1a 50 80 f7 1b 3d c7 0a 01 1f
...
-----Stream END-----

まとめ 

ここからわかったことをまとめます．

• G400はMotionBurstを使用している
• 1msの間にセンサから複数回(おそらく10回以上)変位を読んでいる

複数回アクセスは予想通りですね．(G300でもやっていました)
AnkerのマウスもMotionBurstを使っていましたし，ゲーミングマウスでのデータ取得はMotionBurstが基本なのかもしれません．

キャプチャを正確にしてデータが取れたら，さらに分かることが多そうです．なにか分かったら，また記事にしたいと思います．

最近の私的デバイス事情とか進捗とか

リアルの方の進捗メイキングのほうが中々どうして・・・という感じで記事になりそうな進捗はないです．今回はゲーミングデバイスの雑談というか日記的なものになります．

進捗など

ゴールデンウィークと5月一杯を使ってAim調整ソフトウェアに仕立てることは出来たのですが，使用しているライブラリのLicenseなどの諸事情がありアプリケーション自体の公開はしない予定です．ちゃんと表に出してフィードバックをもらうのが重要だというのは理解しているのですが・・・ ：(
最近は毎日1時間ほど，このアプリケーションを遊んでいます．
2年位前から，「こんなアプリケーションが欲しいけど，誰も作らないだろうから自分で作るしかないなぁ」と考えていたものなので肩の荷が下りた気持ちです．

4月はコレの続きとして，ADNS-9500対応のものを作ろうとしていました．
しかし，問題が発生しました．

あーなるほど。 pic.twitter.com/IDGWY29JGn

— systema (@systema_) 2015, 5月 4

センサ側のMISO(SPI用のMaster入力Slave出力)のポートが死んだようです．図の上の部分がMISOの信号なのですが，最大でも0.5V程度しか出ていません．筺体に星の絵が書いてあるのが特徴のマウスだったのですが，センサーがお星様になりました．RIP Anker Laser Precision Gaming Mouse．
しかし#LogicalGamingの夏はまだ終わりません．Perixx MX-2000 IIの熱いカバーによって願望は成されるでしょう．

以上を踏まえて，日本周辺の優秀なゲーミングデバイス若人へ以下の言葉を送ります．
「ADNSセンサは出力ピンに電流をSinkさせると壊れることがあるので，通電前にMCU側のピン設定をよく確認しましょう．」

マウス

今使っているのはRazer Abyssus (2014)です．G300r best という結論が出たのですが，紫電改が原因でこうなりました．マウスパッドの項で詳しく書きます．

個人的な使いたいマウス候補を順で並べると，G300r，G100s，Razer Abyssus(2014)，その他，の順です．
G100sの形状が許容出来て，G300rのセンサー性能が問題となるのならG100sが一番オススメです．価格が安いのも良いポイントです．
ここ一年で，数十種類のマウスを店頭で触りましたが，サイズと重量の項目でほとんどが選外となりました．

他にはADNS-3090のドナーとしてELECOMのM-XG3Gを買いました．Amazonで購入できるADNS-3090センサ搭載マウスで一番安いと思います．このマウスは，カウントクリップが特徴のマウスですが，実際にプレイしてみると低IPS帯での使用ならクリティカルな問題はないのかなと感じました．
形状的は良いと思うのですが，少し大きすぎるのと，重量は完全にアウトの領域なので私のマウス候補からは除外となりました．そのうちセンサーからケーブルが生えることになるでしょう．コレのADNS-3090版を予定しています．最終的に基板から剥がす所まで行くかも知れません．

また，大手サプライから出ている極小の安マウスを捕獲して筺体の作りについて考えたりしていました．
今欲しいマウスははるか昔にディスコンしているWMOです．欲しいと言いつつ，WMOを使うのならG100sで良い気がします．
他には，DRTCM37/38関係のマウスがC国のメーカからチラホラ出ているようなのでこちらも気になります．

マウスパッド

後述の紫電改を買うまでの数ヶ月はCOUGAR CONTROL mouse padを使用していました．非常に良い布マウスパッドです．
個人的に使いたいマウスパッド候補を順で並べると，紫電改，COUGAR CONTROL，ROCCAT Tait，その他，の順になります．紫電改はかなり滑るマウスパッドなので，人を選ぶと思います．マウスパッドもまた，Arkなどの店頭で数十枚触りましたが，滑走性を考えると選外になりました．

最後に，最近Artisan 紫電改を購入しました．大変興味深いマウスパッドです．
摩擦係数はプラスチックマウスパッドとほぼ同等だと感じました．しかし，布，プラスチック製のマウスパッドと比較して，動摩擦係数と静止摩擦係数の比が1に近いです．もう少し全体の摩擦係数が高ければ完璧だったでしょう．
紫電改でG300(r)で使用すると低速時にセンサの誤動作が起きるので，Razer Abyssus(2014)を使うことにしました．紫電改を使い始めて2週間ほどですが，プラスチックマウスパッド並に滑る点を除けば非常によいと感じます．
Abyssusはブランド上の理由でL社のマウスが使えないといった軽量マウサーの方にオススメだと思います．(当然，中の錘は外してある前提ですが．)軽いのは確かですが，大きさ的には小型にはジャンルされないのかなという感じがします．

キーボード

RealforceのALL 30gモデルを買いました．しかし，テンキーが邪魔だったので一日でサブキーボードへ移動せさました．文章作成能力は非常に高いので，長文を書く時に出して使っています．これを買うために，実験装置のファームウェアの修正アップデート(という名のほぼフルスクラッチでファームウェアを書き直した)で稼いだ分がほとんど飛んだような・・・
スイッチの特性的にはゲーミング用途としても良いのかもしれませんが，極端な差は感じられません．赤軸とRealforceを比較して，戦績にどれくらい影響するかは未知の領域です．極端にこだわる人でなければCherry MXの赤軸か茶軸のメカニカルキーボードで十分だと思います．

ちなみに今，私が使用しているゲーム用のキーボードは赤軸のKEYCRAFTSのCR-210RD-BBLEです．このキーボードは製品HPの画像を見ると分かるように，全スイッチにLEDを搭載しているのに，キートップはクリアパーツではないので暗所では逆光でむしろキーの文字が見えないという大変に興味深い仕様なのですが，他に特徴はありません．テンキーレスなところは良いと思います．

描画遅延の基準点を調べてみる

半年ほど前にゲームのタイトル毎の描画遅延を測定する手法を紹介しました．

#LogicalGaming: ゲーム毎の描画遅延を測定してみる
今回はその測定手法を用いて，別のことを調べます．

今回は，「極限まで処理が簡略化されたゲームの描画遅延はどれくらいなのか？」という事を測ります．
これは，HIDデバイスの入力が，

PC内のUSBホスト → OS(CPU) → ゲーム → グラフィックカード → ディスプレイ

と処理されていく時の最短時間を知ることが出来ます．
この最短時間は，ゲームエンジンを描画遅延を意識して書いた時，そのゲームエンジンが到達できる最も低遅延な時間とも言えます．また，ゲームエンジンを最適化しても，これ以下の描画遅延を実現するのは難しいということになります．

プログラム

極限まで処理が簡略化されたゲームとして用意したプログラムは，今年始めに用意した自作プログラムです．SDL(Simple DirectMedia Layer)というマルチメディアライブラリを使用してOpenGL APIを制御します．

このプログラムは，マウスカーソルの移動のX軸が右方向なら赤，左なら緑を画面全体に描画します．他にはフレームレートの計測と，ESCキーが押されたら終了する処理のみです．

1フレーム(1ループ)が20行程度で書かれており，初期化が終了すればノートPCで走らせても1000fps以上出る非常に軽いプログラムです．
時代遅れになりつつある私のリグでも6200fps程度出ます(Intel Core i7 2600，NVIDIA GTX 670)．
フレームレートが約6200fpsとすると，プログラム自体が持ちうる遅延は0.16ms程度ですので，遅延は非常に小さいとして無視できます．
つまり，上述の最短時間からゲームの項を削除して考える事が出来ます．

PC内のUSBホスト → OS(CPU) → ゲーム → グラフィックカード → ディスプレイ

USBホスト，OS，グラフィックカードあたりは生半可な手法では遅延を削減出来そうな設定は難しいですので，あとは「ディスプレイを遅延の少ない機種に買い換える」程度しかユーザーサイドで工夫できる場所がないということになります．

結果

右端のBaselineのラベルが付いたものが，今回紹介したプログラムの描画遅延時間です．

私の作成したプログラムは8.4msとなりました．私の環境では，入力デバイスが画面に反映されるまでに最低でも8.4msの時間が必要になると分かりました．120Hz駆動の液晶で換算すると，ちょうど1フレーム程度になります．これは，どんなに良いエンジンでも，PC側の都合で最低でも1フレーム程度の遅延は起きうるということを意味します．

また，一般的なFPSタイトルは演算や描画処理などで，さらに4～10ms程度の時間が必要になると分かります．この時間は，エンジン内の描画処理の順序の工夫等で縮められるのでしょうか．描画遅延の削減を売りにしたエンジンとか出れば面白そうですね．
ゲームエンジンは，フレームレートが特にフォーカスされることが多いですが，描画遅延に対してもより一層注目が集まると，この差は徐々に埋まっていくかも知れませんね．

G100sファーストインプレッション

「より軽量であること」がどれだけ有効なのかを確かめるために試用してみるテスト．

錘を外すために通電して全スイッチの動作を確認したら即分解．開封から5分程度でしょうか．

多分自己最速ですね ：D

ピストルサーバーをプレイしていて思ったのですが，このマウスは重量が軽いので慣性が小さく，ダイレクトに思考をマウスに伝えられる能力が高いと感じました．未だかつて無い一体感ですね．

G302の形状に慣れ，G100の形状にはすぐに適応出来たのでしばらくはG100sで行こうと思います．

初日でG100sに大きく傾いたので，AM010搭載の可能性が低いG300と，G100s選べと言われたらかなり微妙なライン・・・


ちょっと良いAIMだったので動画をアップロード ：D

CS:GOのFoV（視野角）を擬似的に下げてみる

超小ネタ更新．

Counter Strike Global Offensive では視野角(FoV, Field of View)は固定となっています．
垂直方向の視野角は一定で，モニタのアスペクト比に応じて水平方向の視野角が変化します．
CS:GOの日本語Wikiに大変分かりやすい図が乗っているので参照下さい．

アスペクト比に関しては，4：3+黒枠（Black Bars）の方が良いとか，4：3を16：9に引き伸ばすと敵の横幅が大きくなるので当てやすいとか，横方向の視野角が大きい16：9ワイドが強い等々の説ありますがプロですらこのあたりの設定はマチマチであり，「自分がやりやすいと思うものが一番良い」というのが一般的な意見のように感じます．

今回はいつも少し毛色の違った話で，簡単にFoVを下げる方法を考えようというトライです．

体感的にはこんな感じ．

やることは簡単で，

1.ディスプレイを物理的に近づける
2.HUDサイズを小さくする

この2点です．
2をやらないとレーダーやキルログなどの重要な情報が見れなくなってしまうので結構重要だなと思います．
HUDサイズはビデオ設定のHUDサイズから設定できます．

あとは下図の暗部を見ないようにするだけ ：D

CS1.6で大変有名なSionさんもこういう意図で画面と近いようなプレイスタイルでプレイされていたのかもしれませんね．

【ニコニコ動画】Counter-Strike1.6 Sion -all view-

レンズ距離とセンサの関係 ～ソール・オン・ソールにするとマウスに何が起きるのか？～

ゲーミング界隈では，いわゆる「純正ソール」の上に自分の好きなソールを重ね張りするというセッティングを使用している人がそれなりに居るようです．
詳しくはソール・オン・ソールの語源（？）ともなった下記事を参照下さい．
4Gamer.net ― DHARMAPOINTに聞く新型マウス「DRTCM37＆38」。これが「俺達のIE 3.0」だ!?

また，重ね張りでなくとも自前のソール（トスベールや各メーカがラインナップしているマウス用のソール）を使っている人は多いでしょう．この時，純正ソールと厚さが違えばレンズと滑走面の距離は変化します．また，純正ソールを使っていてもソールの摩耗によってレンズと滑走面の距離は変化します．

レンズと滑走面の距離はデータシートで指定されており，メーカは純正ソールを貼った時にデータシートの距離と等しくなるように筐体の設計を行っているはずです．基本的にはデータシートの指定値で最もパフォーマンスが高くなるはずです．また，レンズと滑走面の距離によってDPIが異なる事を述べましたが，DPIの設定値が真に"Dot Per Inch"を意味するのもこの距離になります．


そこで，
ソールを重ね張りした時マウスはトラッキング面をどのように見ているのか？
そして，逆に純正ソールを剥がして薄いソールに張り替えた場合にどのようにマウスはトラッキング面を見ているのか？
というのを先日作成したシステムを用いて視覚的に解き明かしていきたいと思います．

装置概要

下記事参照．
#LogicalGaming: マウスの光学センサが見ている世界を見てみる

今回はマウスパッドをSteelSeries QcKとして滑走面とレンズの距離を変化させます．
そして各距離でのピクセルアレイの様子を観察します．

高さを変化させるのに使用するのは一円玉で，一枚の厚さは約1.5mmです．
rafa様のようにすきまゲージがあれば良かったのですが．．．

今回は筺体を外して基板とレンズのみの構成にします．
これでデータシート通りの寸法で測ることが出来ます．

ADNS-5090 Low Power Optical Mouse Sensor Datasheet
Figure 5. Distance from lens reference plane to tracking surface (Z)

結果

0枚から4枚までの順に下に示します．

0枚（0mm）

1枚（1.5mm）

2枚（3.0mm）

3枚（4.5mm）

4枚（6mm）

この結果を見ると，もう少し詳細に調べたほうが良さそうにも思えますね．

1.5mmが一番良好な結果になりました．標準の距離は2.4mmなので，差が小さい3.0mmの方が良い結果になると思ったのですが．
これから考えると，ソールが多少薄くなる分には性能には大きく影響しない可能性が考えられます．
逆に厚めのソールを重ね張りする場合は性能に影響がありそうです．一時期ソールの重ね張りをしていた時，高速動作時のトラッキングエラーが頻発した経験の裏付けが取れた感じですね．

また4.5mm程度，つまり標準の距離から2.1mm程度で暗くなり始めます．6.0mm（標準の距離から3.6mm）程度では真っ暗になるという結果になりました．
これから考えると，前に示唆した通りLoDが長い機種は「特にカットオフのアルゴリズムは使用していない」という可能性が高いということが分かります．

サーバーのPingが高いので何とかしてもらった話

近頃のGO界隈で流行りのVPSサービスはFOREVER.NETですが，仙台からこのVPSに繋ごうとするとPingが140ms程度になっており中々困っていました．他の国内のサーバは10～15msなのですが．

「そのうちに治るかな」と1，2週間様子見していましたが変化がありません．
コマンドプロンプトにてサーバのIPでtracertしてみたところVPSの運営会社のノードまで到達した後100ms遅延しています．（何故かオーストラリアへ行っている模様？）

とりあえずサイトの問い合わせ欄からコマンドプロンプトでtracertしたログを添付してお願いした所，翌日には改善しておりPingが10msになっていました．


今回の場合，直接お願いして改善して頂きましたが，こういう時普通ならどうすれば良いのでしょう？とかネットワークの知識は全然ないので思ったりもしました．

マウスの光学センサが見ている世界を見てみる

1 概要

今回作成したのは，AVAGO製光学センサが有する機能の1つであるPixel Grabberの可視化システムです．
--------------------------------------------------------------------------------------
2014/11/25 初出
2015/01/25 COUGAR CONTROL Mouse Pad 追加
2015/05/20 Artisan 紫電改 MID 追加
2015/11/23 HORI EDGE 401 追加，レイアウトを調整
2016/01/24 DHARMAPOINT DRTCPWシリーズ 7種 追加
--------------------------------------------------------------------------------------

2 このシステムの意義

通常のマウスのセンサシステムでは単一光源(通常はLED)から光源用レンズを通して単色光が照射され，それをレンズを通してセンサは受け取っています．これは顕微鏡や虫眼鏡等の通常の光学機器での表面の観察と大きく異るので，マウスパッドの滑走面の状態がどのようにセンサ性能に影響するかについて評価する時にはあまり意味がありません．

本システムを用いることで，「マウスパッドの滑走面の状態がセンサの視点ではどのように見えているのか？」ということを直感的に理解することが出来ます．これによってセンサの性能を引き出すようなセッティングを模索する補助や，悪いセッティングであることを認識し校正する手段としての使用が期待できます．

3 マウスに搭載されている光学センサについて

マウスに搭載されているセンサを大まかに例えるとモノクロのデジタルカメラのようなものです．このカメラは解像度が19x19や30x30で，19x19の場合だとTwitterのアイコンにもならないくらいです．このように，普通のデジタルカメラと比較すると圧倒的に低解像度です．
今回使用するADNS-5090では画素数19x19のピクセルアレイを有するセンサです．

マウスが滑走面に覆いかぶさるように置いてあるので，何も照射しないままだと滑走面が暗くて何も見えません．なので，搭載されているLED（もしくはレーザ）をカメラのフラッシュ代わりにして滑走面を照らします．そして前の画像と現在の画像を比較して移動距離を算出します．移動量の算出は毎秒数千～数万枚の画像を撮影して行われます．そしてMCUと呼ばれる制御チップが適宜動いた距離を転送するように要請してくるのでそれに応じて移動距離を転送します．

4 Pixel Grabber

Pixel GrabberはAVAGOの光学センサに搭載されている機能の1つで，センサの保有するピクセルアレイの1ピクセル毎の値を読み出すことが出来ます．これによってセンサが現在どのような画像を見ているかを知ることが出来ます．

5 使用ツール

PC側で主に使用したものは以下になります．
• Python3.4
    • PySerial
    • matplotlib

MCU側では，いつものように以下の物を使用しました．
• PSOC Creator3.0 SP1
• PSoC4 4 Pioneer Kit
• 光学センサ ： ADNS-5090

6 動作

システムは大まかに分けてMCU側とPC側に分けられます．

MCU側では

1. センサへPixel Grabberの指令を出す
2. レジスタから1pixel毎に361 ( =19x19 ) 回読み出す
3. 読み出した値をUART通信でPCへ転送する

というステップを繰り返します．

対して，PC側では

1. UART通信で転送されてきたデータを読み出す
2. データを元に描画する（必要であれば動画・画像の保存を行う）

というステップを繰り返します．この時の"2"のステップ時に表示を拡大するのですが，今回は補間フィルタとしてガウシアンフィルタを使用しました．

7 結果 ： ピクセルアレイの様子

各マウスパッド上で撮影したピクセルアレイの様子の画像を以下に示します．
画像は原寸から10～20%程度へ縮小表示した方が見やすいです．

Steelseries QcK

Artisan 飛燕(Hien) VE MID

Artisan 紫電改(Shiden-Kai) MID

G-Pad 小間久商店(Koma-Q)

ROCCAT Tait (Taito)

Power Support AirPad ProIII

COUGAR CONTROL Mouse Pad ( 3D Texture Surface )

HORI EDGE 401

DHARMAPOINT DRTCPW30C

DHARMAPOINT DRTCPW30S

DHARMAPOINT DRTCPW35CS

DHARMAPOINT DRTCPW35GR

DHARMAPOINT DRTCPW35HB

DHARMAPOINT DRTCPW35RS

DHARMAPOINT DRTCPW35SD

Appendix. 滑走時の動画

Steelseries QcKの表面の様子を撮影した動画は以下のようになります．埋め込みサイズが小さいですが，小さい方がわかりやすいと思うのでこのままどうぞ．

動画を見ていただければ分かる通り，フレームレートは低めです．PC側ではなくマイコン側でデータの取得やら転送でかなり時間がかかっています．
前は速度を出すために色々やっていたのですが，ガリガリに最適化して書いていたらちょっと転けてしまって開発中断したので今回は手堅く行きました．


1-Day Projectにするつもりが丸々2日かかってしまいました．
最後にやったのが6月でソースコードや環境が散逸してしまい，それの回収と復旧の方にかなりの時間がかかった気がします XD

レビュー：G302 MOBA ゲーミングマウス - ロジクール ( Logitech )

Review ： G302 MOBA Gaming Mouse Logicool ( Logitech )

Logitechファンボーイ化が著しい昨今ですが，G302着弾からの即分解でレビューを行います．

Roccat Lua，G402，Perixx MX-2000Ⅱ等々，マウスパッドも含めると10発以上の弾はあるのですが，ブログ更新へのモチベーションは唐突なものです．
今回の場合，G300sへの期待が高まるばかりなのでG302で予行演習をしておこう的な ：D

--------------------------------------------------------------------------------------
2014/11/15 初出
2014/11/16 DPI設定等のスクリーンショットとコメントを追加
2014/11/23 1週間での使用感を追記
--------------------------------------------------------------------------------------

Overview

［JP］G302 MOBAゲーミングマウス - ロジクール
http://gaming.logicool.co.jp/ja-jp/product/moba-gaming-mouse-g302

［EN］Daedalus Prime G302-MOBA-Gaming Mouse-Logitech
http://gaming.logitech.com/en-us/product/moba-gaming-mouse-g302

特徴的なのは後部の蜂の巣状のイルミネーションでしょう．カタログ上ではG402の方が横幅が大きい（72mm）ですが最大幅の部分は底面付近のスカートの部分ですので，持つ部分の横幅はG302の方が大きいです．持つ部分の横幅は，おおよそG402が60mm，G302が65mmです．横幅に関して言えばG302の方が大きいと感じる方が多いと思います．

底面デザインはGx02系は六角形を基調としたデザイン統一されています．センサー周りのソールは理由が気になるところです．配置から推測すると埃の侵入防止なのかなと思います．
分解は先端（画像左）に2つと後端（画像右）1つの小さめのプラスネジを外せば上蓋が外れます．

Internal Structure

内観の全体像はこん感じになります．後部のLEDが目立ちますが，他は妙な部品が生えている訳でもなく極普通の構成と言った感じです．手前のボケている部分はサイドスイッチ用の小型基板です．

写真のLEDの光が当たっている部分がポイントで，上半分は半透明の樹脂て覆われています．これによって使用者には眩しくないように見せて，下半分は下の写真のようなマウスパッドへの照明効果を作っています．ユーザビリティを考慮したギミックですね．

ロゴと後部の光は細かく制御出来ます．ブリージング効果のON/OFF，周期と最大輝度を変更
出来ます．

ブリージング効果をOFFにすると双方の明るさを個別に設定できます．
輝度を最小にすれば点灯しなくなりますのでロゴのみを光らせる，とか全部消灯するみたいな設定も可能です．

光源の制御は約10ms周期のPWMのDuty比を変えるというスタンダードなもの．輝度が最大以外の場合，高速に振ると光が分身するのでPWM周期をもう少し短くしたほうが良いと思うんですけどね．


・新機構

巷で噂のスイッチ部．バネのおかげがスイッチ部の筐体のおかげか押した感じはカチカチ感が少なく，若干「しっとり」とした感じです．ストロークはG402やG300（r）と比較すると少し深め．
個人的にはこのスイッチの感触はかなり好みです．
G300rとG402とG302で連射速度を比較したのですが回数はほぼ同じでした．連写してる時のフィーリングはかなり良いです．

最近のLogitech製品でよく見かける謎の樹脂片は健在．
個人的な推察では表面を滑らかにしたいからだと思います．見ての通り，周囲のような通常の成形だと表面がザラザラしていたりヒケがあったりするので，別に専用の樹脂を取り付ける事でマイクロスイッチのキートップとの接触面の品質を安定させたいのではないかと思います．

 分解で注意したいのがこの絶縁パーツ．初めは製造で混入したゴミだと思ったのですがUSBコネクタ部の絶縁パーツです．
これがないとネジでUSBコネクタがショートしてマザーボードごと持っていかられるかもしれません．

LED部． G402もロゴ用のLEDって緑と青の2色のチップLEDが使われていた記憶がします．ロゴ色にこだわりがありそうです．
左の①～⑫まで印刷してあるシルクには③にチェックが入っていました．

Switch

メインはF2FC-F-7N(20M)で，OMRONの2000万回耐久モデルです．

中ボタンはいつものゴミタクトスイッチと思いきや・・・見た目は極普通のタクトスイッチですが押した感じがマイクロスイッチっぽいです．従来機種と比較して中ボタンの感触がかなり良くなりました．DPIサイクルがバインドされている背面中央のボタンはKailh製．

サイドボタンもKailh製．擦れていて微妙なのですがNF 16ZA（？）という印字があります．
基板裏面を見たらヤニの後があったのでサイドボタンは手半田みたいですね．

サイドも含め全て日本製OMRONのマイクロスイッチ搭載！みたいな謳い文句でPro版とか出ると面白いですよね．私は欲しいです．

Main Control Unit

いつも通りのSTMicroelectronicsのARM®-based Cortex®-M3搭載32ビットマイコン．
[PDF]STM32L100R8のデータシート
Ultra-low-power 32-bit MCU ARM®-based Cortex®-M3, 128KB Flash, 10KB SRAM, 2KB EEPROM, LCD, USB, ADC, DAC
L100なので超低消費電力モデルですが採用理由はローコストだからだと思います．
今年（2014年）の6月頃に製造されたもののようです．

これのポイントの高いところは2KBのEEPROM（いわゆる内部メモリ）がMCU内に搭載されていることですね．はじめから内臓されていればパーツ代や実装コストがカットが出来そうなので今後はこういったMCU内のEEPROMが主流になっていくような気がしますね．

下の水晶発振子はH8.000H4Cという印字がありますが詳細不明．
Internal Clockが搭載されているのに外部のものを用意する理由が気になります．基板に金属パーツが付いていると気合が入っている感じがしてすごく好きですが ：D

Sensor

噂通りのAM010です．データシートが無いので推測ですが，M1421TはサブコンがM，製造時期は2014年21週（5月頃），センサーダイのソースがTという意味だと思います．018はロットかな．

「A」のロゴがあるので純正レンズです．レンズにも印字があるんですがよく分からないんですよね．多分ロットなのかな・・・
LEDはおそらくG402と同じで直視すると少しだけ赤く見える程度の赤外線LEDです．普通に見るだけなら害はないですが光学機器で見てはいけません．

DPI / ボタン / ポーリングレートの設定はこんな感じです．いつもどおりのLGSですね．
噂（rafa様の記事参照）通り，1プロファイルのみです．前述のEEPROMが2KBが関係しているかもしれません．2KBも何書いているのかは謎ですが，マクロ機能で何が入力されるか分からないので多めに取っている感じかもしれません．

2000DPI以降は補間らしいので事実上2000DPI以下の運用が基本となります．補間のON/OFFに関わらず240～4000まで80刻みで設定可能です．
DPI設定は5つまで設定できますが自分は感度レベルの個数を1にして完全に固定DPIで運用しています．

メイン・ホイール・サイドの5ボタンを抜くと余っているボタンが1つなので，DPIを頻繁に変えたい人はDPIサイクルを割り当てるしか選択肢がなさそうです．

使用感

良いです．G402とG302のどちらかを選べと言われたらG302を選ぶでしょう．
なぜならそっちのほうが軽いから．以上．

持ち上げやすさ（ホールド感）では別系統の形状ですがどちらも支障がないレベルですね．G302は形状が特殊なので持ち方によってはかなり相性が出ると思います．
購入を検討している方は一度店頭で触ってみることを強く推奨します．
私の場合は横幅が一番太くなっている山の部分に親指と薬指を引っ掛ける感じでホールドしています（伝われ）．
今までラインナップされていた製品のホールド感とは別物です．G300でもないしG100でもないです．大まかな形状はどちらかと言えばG100に近いですが，大きく張り出した横の山と増量された重量があるので別物に感じるような気がします．前から見ると逆三角形になっていて持ち上げやすい形状はG300のコンセプトを意識しているとも言えるかも．

上述しましたが，スイッチの感触はかなり好みです．

G300と選べと言われたら，考える時間がもう一週間必要です：D
センサー性能はこちらのほうが良いですが，ホールド感や小ささではG300に軍配が上がります．重量差は気になりません．

※個人の感想であり，個人差があります．

しばらく使ってみようと思います．Logitechが過剰に広い横幅に設計した意図を自分なりに見つけたいので．
なにはともあれG300sへの期待が高まりますね．


・一週間使ってみて
ちょっと早いですが，「自分の場合に限っては」G300の方がベターという結論が出たので試用終了．

最終的に，左の山は親指の先に，右の山は薬指の第一関節付近に引っ掛ける感じでのホールドとなりました．小指は薬指の更に後ろで筐体側面に軽く触れる程度です．
手のサイズ的には親指と薬指で大きな物を持っている感じではあるのですが「一応可」というレベルでしたが，センサー性能とマウスを大きく感じるホールド感，重量を勘案した結果G300の方が良さそうだという感じでした．

要するに，「性能も質感も上位互換な感じなのだけれど，G300より大きくて少し重いのでG300の方が良いよね」という感じです．G300にも不満がないわけではないのですがあの軽さと小ささに慣れると戻れないものがあります．

こだわりがある人でなければオススメ出来そうですが，問題は価格でしょうか．全体的な実装・性能・質感やクリックの新機構などを考えると軽量級マウスの中では高いレベルにあると思います．筐体サイズに関しては間違いなく大型機ではないですが小型だと思えるかどうかは持ち方とオペレータの感覚に大きく依ると言えます．個人的には形状は大きく違いますがG402と同等クラスのサイズ感のように思われます．

これで更新は終了予定です．

おまけ：

・軽量化

DPIサイクルとロゴへのクリアパーツは簡単に外せるので軽量化出来ます．ボタンがひとつ使えなくなりますが，さらなる高みへを目指す方は是非．


・クイックスタートガイド

 

↓

 

Unboxで笑ったのは始めてです．

・基板の画像
個人的メモとして基板の画像を貼り付けておきます．