[マウス]入力装置ForPCActionGamer[キーボード]9

復刻版でもずれるんやろか

それは一緒だとみんな言ってるね、ずれ（殆どがネガティブアクセル）を認識してる人は。
復刻版もセンサーの種類が少し違うってだけで決して新しくはなく、やはり99年ぐらいのものらしい。

まぁでもそれをプロが普通に使ってるんだから
マウスは形が命と言うことだな

今まさに、そのネガティブアクセルのデータ作ってたのに、
とっくにやってた人がいたとは。。

と思って、データ見てみたけど、このデータは明らかにインチキしてるっぽいな。
もうちょっと読み込んでみる

>>954
確かに。形7割、他3割くらいだろうね。重要度は。

形でいったらもうIE3.0やIMOでもう完成しちゃった感じだな

>>954
慣れジャマイカ？
ズレも含めてマウスの特性が身に染みついてるから、今更変えたくないだけかと

http://www.gizmodo.jp/2006/07/wolfking_fps_keyboard_gamepad.html
左利きの俺が↑見て興味もったんだけど、これって右利き用だよね
普通利き手にマウスなんだからさ・・・

どうみても右利き用です本当にありがとうございました。
Gizmodo japanは適当な記事が多すぎで困る。
Engadget Japaneseを無理に真似ようとして変な文章になってるし。

mx300はもっとしょぼい。
思い切り動かすと反応しない。
この記事胡散くさくね？

MX300までは8bitデータパスだから、125hzだとそこで性能が頭打ちになるよ。
+/-128 * 125hz 分のピクセルしか一秒間に送れないから、
1000hzの値はすごいけど125hzでの値は全然駄目。

MX510から12bitデータパスで、MX518からは16bitデータパス。

>>962
なるほど。だから1000hzだと性能が飛躍的に上がるのね。

habuのドライバでポインター速度を最大にして
感度を下げるとポインタのうごきがカクカクになるんだけど
こういうもんなの？

そういうもの。

レジストリエディタで
HKEY_CURRENT_USER\Control Panel\Mouse\MouseSensitivity
の欄を見てみろ。
ここが10より大きい値になってると原理的にどんなマウスでもカクカクする。
おそらく速度設定のちょうど中央で10になるはず。

Habuのレビュー張るまえに、例のマウス速度特性を検証しておく。

と思ったら、またアップローダ動いてないし。もう！

>>965
おおサンキューです。

http://www.esreality.com/?a=post&id=1265679

この記事を検証する

この記事の一番おかしいところは、マウスの最大解像度で測定していること。
たとえば、Creative Fatal1ty 1010とCreative Fatal1ty 2020の特性を見てみる。

特性を見ると、
Creative Fatal1ty 1010
Perfect Control: 0.67 m/s (26.5"/s)
Malfunction Speed: 2.70 m/s (106"/s)

Creative Fatal1ty 2020
Perfect Control: 1.17 m/s (46"/s)
Malfunction Speed: 1.60 m/s (63"/s)

となっており、一見Creative Fatal1ty 2020の方が高く見える
ここでCreative Fatal1ty 1010は1600dpi設定で測定していることに注目する
1600dpi、USB Rate: 93 Hzで測定すれば、データが早く飽和するのは当然である。
400dpi設定で測定すれば、Perfect Control: 2.7[m/s]となるはずなのだ。
おまけに、このマウスはもっとUSBレートが上がるのに、そのデータがない。
さらに高い値になることは推測できる。
邪推するなら、故意に、Creative Fatal1ty 2020を高く見せている、とる事も出来る。

USBレートを上げても変わらない、と書いてあるマウスが多いが、
実測してみると、そんなことはない。より高い値まで上昇するものがある。

幸い、レーザーマウスはセンサー自体の性能が頭打ちになっているデータが多く
そのままデータを信用して良さそうだ。

そもそも、対速度特性を向上させるためには、
解像度を下げてデータが飽和しないようにすることが有効である。
USBレートを上げる方法もあるが、弊害がある（wiki参照）。

このことより、飽和しているマウスを400dpiに設定すると、
こんなデータになるはずである。
http://up.mugitya.com/img/Lv.1_up66908.gif

自分の実測とほぼ一致するので、間違いないだろう。
ちなみに、持っていないマウスは分からないので除外した。
G-3とDiamodbackは4.5[m/s]以上になるはずだが、記事のMAX値である4.5としておいた。

一見して分かるとおり、レーザーマウスが上位に来ることはない。
古い設計のIME3.0と比較しても、動作限界が低く、
あっという間にカーソルが暴れるのである。

特に特性が良いのは、AvagoのADNS-3080を使ったマウスだろう。
Fatal1ty 1010が若干低くなっているが、これは測定時のマウスレートがおかしいせい。
まあ、このマウス好きじゃないのでどうでもいいや。

というわけで、Habuのレビュー書いてくる
せっかく自分でデータとってたのに、やられたわあ。

http://gadget.tm.land.to/pukiwiki/index.php?uploader
あぷろだ設置してみました。
1MB制限は小さすぎるようであれば外します

光学G3欲しいんだけど、ドライバがクソみたいですね。
ドライバなくても全部のボタンって使えるの？

センサーのスキャン面積って
各マウスでどれぐらい違うんだろう？
大きい程、対速度に強く成るよね？

>>971
いつも乙です。

次スレ立てました。
[マウス]入力装置ForPCActionGamer[キーボード]10
http://game9.2ch.net/test/read.cgi/gamef/1165935876/

>>973
レーザーマウスの速度性能が悪いのは、それが原因？

>>969-970
これ，面白いですね。
高解像度，低レートでの測定のために，センサーの性能以前に，
システム上頭打ちになってしまっているってことですか。
ここでのデータ飽和というのは，>962さんのいうような，データパスを
超えてしまっているという意味でしょうか？

しかし，400dpiでの再計算の結果は，割と差が出るもんですね。
だいたい感覚に近いですが，ADNS-6010系がこんなに低い結果とは…。

ところで，恥ずかしながら動作限界と線形動作maxの違いが，
よく分からないのですが…。

>>972
ｋｗｓｋ

RazerのDeathadderっての仕様と外観みる限りではかなり期待してるんだが･･･

特にマウス持ち上げて移動させるときのラグを解消云々は興味深い

>>976
動作限界と線形動作maxについて、
余計な言い換えをしなければ良かったですね。

線形動作maxは、マウス移動距離と、カーソル移動距離が一致する速度の最大
グラフで言うと、最初の直線部分です。

動作限界は、それ以上早く動かすと、逆方向に動いたり、カーソルが暴れ出す速度。
グラフで言うと、最後に下向きに折れる部分です

たとえば、IME3.0などは、8bitのため線形動作maxは厳しい値になりますが、
動作限界が高いので、ある程度は動くし、カーソルが暴れ出すことは少ない、と読むことが出来ます。

＞USBレートを上げる方法もあるが、弊害がある（wiki参照）。

これ書いたの実は自分なんだけど、比較的無責任に書いたのであれから更に色々調べてみたよ。

例えばQuake3のソースではボタン入力にはDirectInputのバッファリングデータを取得してるけど、
移動データはDirectInputの直接データを取得していて、絶対に入力を取りこぼさないのが分かりました。
逆にQuake4ではソースは見えないけど500hzで取りこぼします。（明らかに体感で）
Doom3ではQuake3並に快適だったので、Q4はRavenが改悪したのかも。

整理すると、アプリケーションの実装としてありうるのは（経験上全どれもありうる）
1)移動情報の取得に直接データを使う
2)移動情報の取得にバッファリングデータを使う（バッファが充分に用意されている）
3)移動情報の取得にバッファリングデータを使う（バッファが充分に用意されていない）

の3パターンに分ける事が出来て、上の2つのケースでは取りこぼしが起きない事になります。
自分は今まで1の方法で実装されているゲームも、2のケースなんだと勘違いしていました。

何故かというと、ソースが公開されているといえばやっぱりQuake系なんだけど、
Quake1は元々DirectInputに対応してなくて、有志が改造してDirectInputを組み込んだ物が結構あって
恐らく最初に組み込んだのがfuhquakeというQuake1ではかなり有名な改造版なんだけど
それが2のケースだったからです。DirectInputに対応した改造Quakeエンジンは結構ありふてるんだけど、
みんなfuhquakeからソースをパクったと見えて全部2のケースでした。

Quake2エンジンの改造版のR1Q2というやつはオリジナルの実装だったけど
それも2のケースでした。直接データを使う設定にも出来るんだけど、
それをするとボタン入力まで直接データを使うようになって
今度はボタン入力のほうを頻繁に取りこぼすようになる筈。
Quake3みたいに移動データは直接データ、ボタン入力はバッファリングデータというのが絶妙。

長々と書いてしまって申し訳ないけど、今までのを総合的にまとめると、
500hzや1000hzとかでも、本当に入力を取りこぼしてないかきちんとテストして
問題ないと確認出来れば使って大丈夫だと思います。
絶対に自分が遊んでるゲームを一本一本慎重にテストしないと駄目だけど。
Quake3みたいな優良な実装をしているケースは稀だと思うので（流石id softwareといったところ）

>>978
Diamondback Plasmaの改善版と見るべき物なんだと思う。
あれは空中に浮かしても動いてしまったから、
DeathAdderでは浮かした時に即動作が無効化されるってことみたいね。

海外ではセンサーやレンズの設置が規定どおりではないから浮かした時も動いちゃうんだろ
なんて疑いも掛けられていたんだけど、同センサーを使ったKraitでも同じだったので
センサーか赤外線LEDか、もしくはその組み合わせ特有の問題と判明。
DeathAdderはそれが直ったって事らしいので、すげー欲しいです。

>>979
丁寧な説明，ありがとうございます。
動作限界はセンサーの性能による限界で，線形動作maxはレートや
データフォーマットなど接続システム的な限界という感じですかね。
しかし，>980さんといい，スレ終盤にえらく話題が専門的になりましたね（笑）。


DeathAdder，3G Infrared Sensorについてのページが出来てたとは。
確かに"disables surface tracking immediately when the mouse is lifted off"って
なってますね。う〜む，これは欲しくなってきたぞ。

あと書き忘れたけど、非DirectInputのゲームの取りこぼしは画面解像度に依存します。
画面の中心に非表示のマウスカーソルがあって、そこからマウスポインタがどれだけ動いたかで
移動量を検知してます。（毎フレーム毎にポインタの位置を画面中心にリセットしてます）

この方法は画面の端っこまで（非表示の）ポインタが到達すると、
それ以上ポインタが進めないという状態が起きて、それ以降が取りこぼしになります。
解決する方法は解像度を上げるか、DPIの低いマウスを使うのみです。

自分はCSはもう卒業してやってないんだけど、確かCS1.6は非DirectInputだったはず。
でもってあえて800x600でやるとかが流行ってたと思うんだけど、それは取りこぼしの危険性があります。
特にハイDPIマウスで、ローセンシで遊んでる人は注意。

どのくらいで取りこぼすかの具体的な数値は各自の環境に合わせて計算してみるといいと思います。

>>980
いや、直接データだから絶対に入力を取りこぼさないって話はないでしょう
むしろ、取りこぼさないための、バッファリングデータじゃないのかな

http://msdn.microsoft.com/library/ja/DirectX9_c/directx/input/using/devicedata/bufferedimmediatedata.asp?frame=true

>>984
言いたい事は分かります。自分も長い間そう考えてたくらいだから。

例えばボタンのON/OFFの話でいえば、ボタンを連打しまくった場合に
それらの情報がスポイルされて最終的な現在の情報だけしか取得できないのが直接データですよね。
だからボタンデータに直説データを使うのは大問題です。

でも移動データに関しては前回の直接データ要求との差分が取れるようなので、全く問題ないと思います。
そのMSDNドキュメントも何度も読んだけど、どこか他のページで目的別の使い分けを推奨してたと思います。
マウスでいえばそれ（移動＝直接　ボタン＝バッファ）が理想の使い分けだと思ってます。

あと、例えば直接データも数兆ピクセル分の入力をとりこぼさないのか？
となれば？？ですが、少なくとも16とか32フレーム分のバッファリングよりは
マシなんじゃないかなーと思います。連投すまんす。

>>985
そっかー。なるほど。マウス内バッファが溢れるまでは取りこぼさないのね。
オハズカシイ

てすてす
http://gadget.tm.land.to/pukiwiki/index.php?plugin=attach&refer=uploader&openfile=habu01.jpg

アップローダ良好っす。
でも、削除出来ないし、wikiに記事が移行したときなどに重複するし、どうしたもんですかね。

自分もWikiに間違いが載っていてもっと恥ずかしいです。

確かに
＞絶対に入力を取りこぼさないのが分かりました。
の「絶対｣は消して、ほぼ　にしてもらった方が良さそうです。（もしWiki更新してもらえる場合）

＞マウス内バッファが溢れるまでは取りこぼさないのね。

マウス内バッファじゃなくて、たぶんDirectInput(COM)の
｢直接データ保持用バッファ｣（ややこしい　汗）だと思います。

いや、ほぼはまずいか。ほぼ絶対に　のがいいかな。
眠くて訳わからなくなってます。すみません990あたりなのに無駄に生めてしまって。
寝ますすいませんでした

>>991
ものすごく助かる情報だと思うんで，ぜひwikiに書き込むぞ…と思ったのですが，
何分専門的な内容なので，素人の自分では思わぬ間違いをしそうです。
よろしければ，従来の内容含めてwikiに（引用の形でなく）直接まとめていただけると，
今後のためにも大変助かります。

wikiの編集が面倒なら，まとめてくださった文章を書いていただければ，そのまま
転載します。

マニアックすぎて理解不能の領域にｗ
できるだけ分かりやすい言葉でまとめもお願いしたいなー。

形状云々は別にして、技術的にみてのベストな機種をズバッとお願いします。

>>977
ttp://www.amazon.co.jp/LOGICOOL-Logicool-G3-オプティカルマウス/dp/B000BPWWD2/ref=pd_sbs_e_1/250-7054616-4967449

>>992>>993
挑戦してみます。実生活もあるので、しばし時間をください。

毎スレ終盤は専門的で保存しておきたい内容が多いな。
感想うめ。

FSPとはもう何の関係もない感じだけどなｗ

うめええええええええええええ

1OOOならhabu購入

このスレッドは１０００を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。