加速理論とその周辺

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本あげたいところですね．

#LogicalGamingGlobal

グローバルへオフェンシブに行きましょう．

#LogicalGamingGlobal というブログを作りました．
弊ブログの英語版という位置づけになります．

このブログのアクセス解析をしていると，翻訳して見てくださっている方が結構いるようで，折角なら英語版を作れば良いのではないかと思いました．
ちょっとコアな内容の記事だと，国内だと「俺得」だと思ってくださる方が数える程しか居ないような気がしていて，もう少し裾野を広げれば面白いことになるのではないかと期待しています．

全記事を翻訳して出すわけではなく，去年の総集記事に書かれるくらいのクオリティをもつ記事だけ要約・翻訳して書いていこうと思います．"ゲーミングを定量化する"系のネタは，海外は海外で各々やっているので出す必要はあまりないと考えていて，デバイス系メインになる予定です．
要するに#LogicalGamingの要約版なので，日本人の方は特に見る必要はないものになるでしょう．


グローバルでフルスタックなπ型人材の需要が高いようなので，英作文の練習も兼ねていたりもします：D
圧倒的成長をしなければいけない時期になりましたので，とりあえず趣味と実益を兼ねる所から攻めてみようかと・・・なにかレアスキルとかあれば良かったのですが：(

私の英語力的にすごく恥ずかしかったりしますが，うまく内容が伝わるように頑張りたいです．

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

先日，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程度の時間が必要になると分かります．この時間は，エンジン内の描画処理の順序の工夫等で縮められるのでしょうか．描画遅延の削減を売りにしたエンジンとか出れば面白そうですね．
ゲームエンジンは，フレームレートが特にフォーカスされることが多いですが，描画遅延に対してもより一層注目が集まると，この差は徐々に埋まっていくかも知れませんね．

一段落

したはずなのですが．．．
色々後回しにしていた事を片付けるので3月中は終わりそうです．

2月と3月前半はブログ更新はおろか，シューターすらプレイできない日が大半でした：(
デバイス勢の方々のブログは欠かさず見ていましたが，私自身のアウトプットが少なかったです．
来年度は，「時間をうまく使う」ことを重要視していきましょう．

ゲーミング・ゲーミングデバイスへのモチベーション的には去年の今頃より高いですし，
ネタ自体はちょくちょく作っているのでボチボチ更新していきたいと思います．

マウスが見ている視界はどれくらいの大きさなのか？

以前マウスが見ている景色について調べたという記事を書きました．

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

マウスのセンサはマウスパッドをカメラのようなもので撮影して，そこから動かした距離を測定しています．

そのセンサの仕組みの中で，「マウスがどのような写真を撮影しているのか」という事を調べました．

今回はマウスのセンサがマウスパッドの表面でどれくらいの範囲を見ているのかを明らかにしていきます．

範囲が分かることにより，マウスが読み取れるような凹凸パターンのサイズに検討がつきます．

例えば，凹凸のサイズが非常に大きい面ですとマウスは小さい範囲しか見えないので変化がないように見えます．逆にマウスからは滑らかに見えるくらい小さい凹凸しかなければそれも変化を読み取ることが出来ません．どちらの場合も良好なトラッキング結果は得られないでしょう．

それではいくつか撮影してみましょう．撮影環境は前回と同じです．

まず最初はどこのご家庭にもあるノギスです．目盛の部分を撮影しました．

ノギスの目盛部分

目盛の黒い線がくっきり写っています．

"目盛の太さ"は目測ですが0.1～0.07mmくらいだと思います．

次はレシートに印刷してあったQRコードを撮影しました．

レシートのQRコード

こちらも綺麗に写っています．

このQRコードは12.2x12.2mmの範囲に33x33ピクセルで印刷されています．

この2つの画像から考えると，ADNS-5090が見ている範囲は0.8x0.8mm程度であることが分かります．ADNS-5090は19x19ピクセルの画素数ですので，1ピクセルが表す範囲は0.04mm程度であると分かります．

補足 ： レンズ倍率について

レンズの倍率を低くしてDPIを犠牲にしつつ最大トラッキングIPSを上げたりするようなこともあるらしいです．

参考 ： rafalog: 光学式センサー用レンズいろいろ

倍率を変更すると見える範囲も変化するので適切なパターンのサイズも変化します．

例えば低倍率にすると見える範囲が大きくなり最大トラッキング速度は上昇しますが，その分小さな凹凸は見えなくなります．その場合は表面の凹凸パターンが大きめのマウスパッドの方がより良いと考えられます．

生存報告も兼ねて．

2015年

あけましておめでとうございます．
今年も#LogicalGamingと@systema_，（CG/計算機な人は@aaax3001も）をよろしくお願いします．

・2014年を振り返って

ブログを立ち上げたのが2014/01/10なので，ちょうど一年程になります．
1-3月はあまり更新していませんでしたが，4月にrafa様のブログで取り上げて頂いてから本格的に活動を始めたような気もします．そういった中で様々な人から反応を頂きまして，更新のモチベーションになりました．
書きたいと思った記事はその時その時でタイトルだけ書いて全部下書きにしているのですが，下書きの個数は減るどころか増えています．ブログの更新するネタがないなんて言っている人が羨ましい・・・ ：D

3月の終わりにこんなツイートをしたのが懐かしいです．

本格的にLogical Gamingの活動開始します。主な活動内容はゲーミンググレードのデバイス開発を目標とした試験と解析です。
— aaax (@aaax3001) 2014, 3月 29

宣言通り「ゲーミンググレードのデバイス開発を目標とした試験と解析」はしていたのでよしとしましょう．センサ・スイッチの制御とUSB関係の基礎的な知識がついたのが良いですね．


ついでに去年の記事の中で印象深いものを幾つか紹介．

・USB HIDデバイスのクリックの最速応答を考える
USB HIDが制御出来たのが嬉しくて突発的に書いた記事です．
私でも比較的容易にクリックレスポンスの速い実装が出来ました．つまり，クリックの応答速度が速いメーカーが秘伝のタレを持っているのではなく，速度が遅いメーカーが何らかの理由で遅くしているという事でもあります．理由に関してはマーケティングやサポートであったり，優先度の低さなどもあると思います．
そういう意味でも良いゲーミングのためには，ユーザ自身が明確なデータを測定して公開するというのは大事なのだと思います．


・マウスの光学センサが見ている世界を見てみる 
ADNS系センサの制御は組み込み方面ではそこそこ見かけるのですが，PixelGrabberについてはちょこっと動画があっただけであまり使われていません．
そういった中で，ゲーミングマウスパッドがマウスの光学センサからはどのように見えているのかを示しました．解像度が低いのでもっと意味不明な感じだと想像していたのですが，思ったより顕微鏡画像っぽく見えたのがナイスですね．
今後の私のマウスパッドレビューではPixelGrabberで取得したマウスパッドの表面画像がつくようになるでしょう．泡沫ブログなのでレビューに個性が出すいいツールになるかもしれません．
光学・レーザーにおける差異を見てみたいのでレーザセンサもやるべきなのですが・・・今年の課題ということで．


どの記事も内容的に「訳わからん」と言われがちなのでもう少しわかりやすくしたいです．
このブログを訪れるユーザが「rafalogの過去の記事を全て読んでいる」という前提で話を進めているのが問題なので，もう少し導入部分に力を入れていきたいです．


次は"ゲーミングを定量化する"という，このブログ本来のテーマに基づいたものです．

・ゲーム毎の描画遅延を測定してみる
「ゲームのタイトルによって入力が画面に反映される時間に差異がある」という現象事態は多くのゲーマーが感覚的に認識しつつも公表はあまりされていません．「遅延というパラメータがゲーミングのパフォーマンスに影響する」という事自体が，ここ数年でやっとメジャーになってきたというのが私としての認識です．
その"遅延の差"の存在を証明し，ミリ秒単位で定量的に測定できる手法について示しました．
遅延の差の存在を証明することと，タイトル毎の優劣を明確に測定・公開することによって，ハードウェアの遅延だけではなくゲームエンジンや実装における遅延低減がフォーカスされると良いですね．


・Reaction Time (反射神経)とAimの関係
Reaction TimeがAimとどう関係するのか？Reaction Timeを縮める為に効果的な物はあるのか？
こういったことをゲーミングを指向して調査しました．結論として，人間も含めて全てを「システム」として捉えると，ハードウェアやOSに起因する遅延を出来るだけ低減するようにセッティングするべきだということと，人間のReaction Timeに関してはばらつきが大きく明確に改善する方法はないという事を示しました．
人間においては「集中力」というのがかなり重要な要素になっているのが分かったので，暗示（条件付け）についてもう少しフォーカス出来ると面白いと思います．


・FPSにおける武器の精度について考えてみる
この記事で最も言いたかったのは，精度が高い武器を使用すると許容される誤差が大きくなるという点です．あまり反響がなくて残念ですが ：（
私はシューターにおいて初弾の精度はかなり重要なパラメータだと考えているのですが，世間一般ではそうでもないのでしょうか．

・最近

年末年始は描画遅延の調査に必要になったためOpenGLを触っていました．
極端にシンプル（数ステップ）なルーチンを持つOpenGLアプリケーションを作成して，入力→ディスプレイへの描画における遅延時間の基準点を調べる予定です．
とりあえず実行ファイルは出来たので後は撮影とデータ整理ですね．ハイスピード撮影で動画は撮ったもののコマ数を数えるのが面倒でやっていない，という事態がここ2ヶ月程度続いているので・・・作って満足してしまうタイプなのかもしれません．

また，あのページ自体も「とりあえず測る環境は出来たので記事にする」という感じで公開した物なので，もうより体系的・定量的にまとめる必要があります．


あと，私はFPSでもスペースキーで射撃するという結構独特なスタイルだったのですが，レイテンシが気になってきたので構成を変えました．射撃はキーボードの下に置いたG302でやることにします．
こうすればクリック中に右手の筋肉の動きは制約を受けないし，レスポンスも最速クラスです．
マウスはアレ以来ずっとG100sを使っています．


もう一つ，COUGAR Gaming Mouse Pad - CONTROL series買いました．
このシリーズ，ControlタイプとSpeedタイプという2種類がラインナップされていて，Speedタイプは巨匠ことMysticSiva様がレビューされています．
Cougar SPEED gaming mouse pad | Chocolate Device

このマウスパッド，中々いい感じなのと，Controlタイプは3次元形状を持つ滑走面が売りらしいのでそのうちレビューしたいです．



と言いつつ・・・1，2月は相当忙しくなりそうであまり更新出来ない予定です．