Brynhildr

KeroRemote

リモートデスクトップエンジニアのブログ。

マウスの遠隔操作:マウスの加速




「Verethragna(ウルスラグナ) 0.10.2」で実装された新機能について。

さて、先日リリースしました「Verethragna 0.10.2」でマウスの移動周りの不具合を修正しました。「0.10.1」ではマウスの遠隔操作の際にサーバーのマウスカーソルがビューンって変なとこに動いてしまう不具合がありました。これについてお話していこうかと。

まず、BrynhildrもVerethragnaも「SendInput」とゆーAPIでサーバー側のマウスを動かしています。BrynhildrやVerethragnaの「0.10.0」以前ではこのSenInputのパラメータとしてMOUSEEVENTF_ABSOLUTEによる絶対座標を指定していたわけです。

ここで1つ懸念点が。ご存じの方もいらっしゃるでしょうが、絶対座標の場合は単位は「ピクセル(ドット)」ではありません。「ミッキー」です。マウスだけに。1ミッキーは0.25mmですのでピクセルに座標変換する際に単位が違うので当然ながら割り切れず端数が出ます。もうこの時点でワシイヤイヤです。0~65535の正規化された座標とか誰が考えたんだと問い詰めたい。将来に解像度が65536x65536を超えた時にどうするんだと。

とは言え、相対移動よりも絶対座標の方が使い勝手が良いのでVerethragnaでもしぶしぶ使っていたのですが、ふとVerethragnaの映像周りのチェックで「Apex Legends」を試していたところ、マウスがまるでゆーことを聞きません。カメラがぐるんぐるん回りっぱなしです。まー、ゲームですのでチートっぽい扱いになってゲームメーカーに怒られてもイヤですしあまり個別に対応しないとゆースタンスでしたが、ふと気になってMOUSEEVENTF_ABSOLUTEを外して相対座標にしてみたんですけど。そしたら、

ちょっと改善したんですよね。

全然まともではないですけど動かせないこともなかったですし、このくらいであれば個別対応でもないですし、何よりウェブブラウザ接続機能(仮)のこともあったので相対移動にした方が将来的に良いかもなと。加えて先ほどのミッキーとゆー単位からも脱したい気持ちもあり。

んで「0.10.1」では相対移動でいこうかと考えて実装しました。んでリリースもしました。この時点で設定のマウスの加速については認識はしていたもののあまり考慮できていませんでした。

いざリリースしてみると何人のユーザーの方からまともにマウスの遠隔操作ができない旨のご報告を受けてしまいます。私も調査の段階でマウスの加速の設定が原因であることを突き止めました。

んじゃこのマウスの加速の設定に対応してみようと。マウスを右に100ピクセル動かした時に、マウスの加速が有効だった際に、どのくらいの加速度だと右に何ピクセル動くのかを計算式で出していこうかと。結果、

無理。

できないこともないのかもしれないですけどいつできるか分からんレベル。計算式とゆーか条件式とゆーか設定による影響が強く、レジストリの値やら加速曲線やらも登場してきて、しかも様々な環境(ハードやソフトや)やら将来的な担保などなどを考慮すると、式で対応するのはあまりにリスキーとゆー結論で。

しかもこの辺の情報があまり出ていないんですよね。まああまり関わることが少ないよーな領域ではあると思うんですがちょっとあまりにも情報が少なすぎるって印象でございやした。

ちなみにChatGPTによる回答は以下の通りで。

「マウスカーソルの移動距離 = マウスの実際の移動距離 * (1 + 加速度 * (マウスの実際の移動距離 - 1))」

うーん、加速度の算出方法が分からんので続けて算出方法を聞いてみると、

「Windowsにおけるマウスの加速度の算出方法は、通常、ユーザーが直接設定する数値ではなく、システムが内部的に使用している計算式です。この式はマウスの実際の移動距離に基づいて、カーソルの移動距離を変化させるためのものです。

具体的な加速度の値は、Windowsのレジストリ内に保存されており、通常はレジストリエディタを使用して変更します。以下は一般的な加速度の計算方法ですが、Windows自体が内部的に使用している計算方法かどうかは確証がありません。

式では、マウスの実際の移動距離に応じて、カーソルの移動距離が変化します。加速度の値が大きいほど、マウスを速く動かした際のカーソルの移動距離が増加します。

しかし、Windowsが具体的にどのような式やアルゴリズムを使用しているかについては、正確な情報が公開されていないため、一般的な理解に基づく推測です。Windowsのマウスの挙動やパラメータは、バージョンやアップデートによって変更される可能性もあります。」


うーむ、正しい気がする・・・。つまりお前も分からんと。

さてんじゃどーするかとゆーことで、試行錯誤した結果の今のところベストいやベターであろう「とある処理方式」を見出して実装して「0.10.2」としてリリースしました。これが新機能でございやす。たぶん恐らくいけてるんじゃないかと思ってますが自信がないので大丈夫になったらまたどんな仕組みなのかをお話しやす。

そうそう、絶対座標の場合はマウスの加速の影響を何ら受けません、Snedinputは。ですのでマウスの加速を考慮すべきはMOUSEEVENTF_ABSOLUTEを指定しない相対移動だけなんですよね、悲しいかな。

その相対移動にしたことでミッキーではなく念願のピクセルになったわけですが、このマウスの加速の影響ですんなり実装とはいきませんでした。でもまーとりあえずはApex Legendsで動かせないこともなくなったのでまーヨシとしませう。ただ、試行錯誤がまだしきれていない可能性もあり、正解かどーかもまだ分かりませんのですぐ変えるかもしれませんけど。ですので、もし動かないとゆーことがありましたらご報告を頂ければ幸いでございますー。

ただ、同じくたまにテストで利用する「FINAL FANTASY XIV(FF14)」では相対移動にしてもマウスの動作が改善しない現象がありまして。こちらも調べてみたら分かったことがありましたが、長くなりましたのでこの話は次回に続きます。

つづく。


コメントはまだありません ... ( 管理人承認制 )





... 不具合報告の際は、アプリのバージョンやOS等の動作環境の記載を御願い致します。

表記されている会社名・製品名・システム名などは、各社の商標、または登録商標です。
当サイトはAmazon.co.jpアソシエイトプログラムに参加しています。
© 2010-2023 KANEKO