とうとうマウスを交換することに

数年間愛用していたマウスですが、とうとう動作不良を起こし始めたので気になっていたあれに乗り換えてみることにしました。

 

今まで使っていたマウスは…

というと、このblogでも何回か記事にしていますので過去の記事を遡ってもらえばわかると思いますが、

M570tです。かなり長い間愛用しておりまして、表面に書いてあるロゴの印刷が使っているうちにはげていってしまって何が書いてあるのかわからない状態となるほどでした。ちなみに動作不良というのは左ボタンのチャタリングです。いわゆる一回しか押していないのに二回以上入力が認識されてしまい勝手にダブルクリックや二回のクリックと見なされてしまう、という現象です。スイッチ部分を取り替えることができれば直せるのかもしれませんが…。

なお、通常どのマウスも使い込んでいくとボタン部分のチャタリングによるボタン認識問題は出てくるものなので私の使っているマウスの耐久性が悪かったわけではないと思います。ゲーム開発でかなり酷使していた時期もあったので…

 

ということで、これにしてみた

なんとなくわかると思いますが、

MX EGROです。いや~。発表されたときからかなり気になっていて、一度は使ってみようかと思っていたので思い切って買ってみました。しかしまあ今までの用途から考えるとどうやってもFlowは使わないしゲーム用のマウスでもないのにかなりの金額をするものだな、とは思ってはいましたが。

なお、購入金額についてはほぼ定価購入だと思います。購入したいのであれば通販で店を探した方が安いと思います。通常の家電量販店だと高すぎるのか扱っておらず販売している実店舗を探し出すのに少し苦労しました。

 

肝心の使い勝手は…

まだ使い始めたばかりなのでなんともいえません。が、前のマウスと違うところとして親指トラックボールのそばにあるボタンがデフォルトで「精密モード」というものに割り当てられていて、このボタンを押すと入力解像度を一時的に引き上げる?ものらしく、画像をPhotoShopやGIMPなどで加工する場合によく使えそうです。ただ逆に言うならマウスの移動量が減ってしまい、マウスの移動が遅くなります。それをどう生かすかは各自の考え方次第、というところでしょうか。個人的には精密モードがあるなら通常のマウスカーソルの移動量は多少大きくてもかまわないのでは?と考えて設定で少しあげています。それ以外はデフォルトのままで使っていきたいと思います。

あと最大の売り(だと思います)である手首の角度については、0度状態にするとM570tよりもマウスが大きいためか手首が浮いているように感じられ少し心許ないです。20度状態だとマウスの置き場所を間違えないのであれば使いやすい可能性が大きいかな、と感じる状態でした。というところでしばらくは20度の状態で試してみたいと思います。

最後にM570tは単三電池で動くのに対してMX ERGOは内蔵の充電池で動くタイプなのでこれがほぼ完全に充電されてから警告が出るまでどのくらい持つのか、が興味を引かれるポイントだと思います。これがよければもう一つ別の場所でもM570tを使っているのでそちらも交換してみたいかな~と思います。

もしかするとしばらくしてさらに追加で使い勝手について書くかもしれませんが…それはそのときということで。とりあえず暇な時間を見つけてはプログラムは書くようにしています。さすがにエミュレーションする部分が大きいので時間がかかっています。

 

しばらくWindowModePatchの機能向上に取り組む予定

この手の情報は基本的にTwitterに書くのですが、今回はblog側にも書いておこうかと思います。

 

やはりDirectDraw周りのエミュレーションがあまい

特にDirectDraw+Direct3Dの組み合わせになるとかなり微妙なようです。DirectDrawをそのまま使うタイプの解像度処理だと色深度によって問題が出ることもあるらしく・・・というところで、Direct3D9を使ったエミュレーションだとその辺が完全に実装できていないのでエラーを返される場合も多々あるようです。

 

ということでその辺の処理を追加実装する予定に

一応どう実装するかは決めているので後はコツコツとエミュレーションを書いていくだけです。例えばDirect3DをDirect3D9を使ってエミュレーションするクラスの出だしは

 

class CDirect3DOnDirect3D9 : public CUnknownBase, public CDirectDraw7OnDirect3D9Holder, public IDirect3D, public IDirect3D2, public IDirect3D3{

 

となります。なんじゃ、こりゃ?といいたくなるプログラムコードです。しかし本当にこういうコードを内部的に書いています。特にひどいのがIDirect3DとIDirect3D2とIDirect3D3を同時に実装するというところ。もう少し各クラスに互換性があれば上位だけを実装して強制型キャストですむのですが、この3つにはその手の関係が微妙にないのでこんな実装をするしかないようです。ちなみにIDirect3D7だとIDirect3D3以前とはまた違った実装をしているのでこれは単独で組んでいます。おそらく残りの実装も面倒なのでしょうね。まあ、暇な時間を見つけて作っていきたいと思います。

WindowModePatch 0.70 Alphaを公開

WindowModePatchの更新情報です。0.69Alphaは欠番ではなく更新してもしそのまま何も書かないとどうなるのか?を実験してみたのですが対して変わらなかったので0.70Alphaでは更新情報を記事にします。

 

0.69Alphaは入力系の更新

念のためにスタブとしてDirectInputに関する入力変換は実装していたのですがいろいろと調べてみるとなんとなくこれが理由のような事象があったのでDirectInputも対象にして処理するようになっています。おそらくそれほど問題にはならない更新だと思います。バリバリにDirectXを使うようなゲームなら影響がある可能性はあるかもしれませんがこちらはADVゲームがメインですのでDirectInputをまともに使っている物は余り見ませんので。

 

0.70Alphaは初期ウィンドウサイズに関する更新

通常は自動的に内部からウィンドウサイズ変更命令を行ってサイズ調整をするのですがなぜかサイズ調整の部分だけ無視するプログラムもあるようで。いろいろと調べたのですがなぜサイズ調整のルーチンが無視されているのかがさっぱりわからず、仕方がないので初期ウィンドウのサイズを直接設定できるように変更してみました。こちらは通常この機能を使う必要は全くありません。さらにいうなら自動認識でうまくいっている状態ならなおさら使う必要はないと思います。あるとするならウィンドウ検知に失敗するために描画サイズの固定を行っていてかつ外側のウィンドウサイズだけなぜか変更されない、こういう状態だけで有効です。また、設定は設定ファイルからのみ変更可能ですのでもしそんなゲームを対象にしたいのであればこの機能を使うとうまくいく「かもしれない」というものです。どうしてもこの手の記述って多くなってしまいますよね・・・

 

やっぱりまともに更新する暇がない

というのが現状ですか。0.70Alphaにかんしても調べて実装するまでは実効一日で終わってしまいましたし。単に思いついた後準備に手間取ったり都合がつかなくなってほったらかしになってしまったが故にTwitterに更新開始を書いてから今までかかってしまったわけですし。そうなると本当にコード公開やら何かを考えないと(これが宝かどうかは別として)宝の持ち腐れのようになるのかもしれませんね。

 

WindowModePatchのページに英語版を追加してみた

でも書いている記事は日本語な訳ですが…。

 

日本語ができない人の訪問が増えたようなので英訳してみた

頑張ってみました…といいたいところですがこちらも簡易です。やり方は簡単で適当な長さで区切った日本語の文を翻訳サイトで一度英語に訳した後再度自分が日本語に翻訳したときにある程度正しいか?をチェックして正しいならばそのまま、間違っているならば自分の知識内で修正を行って翻訳サイトにて再度日本語に翻訳して文法的な誤りがないかをチェックする、という手順で行っています。この頃のGoogle翻訳などの翻訳サイトは本当に質が向上しているので致命的な誤りが出ることがほとんどない状態となってきました。逆に言うなら翻訳結果が微妙となった場合であれば自分の日本語表現を多少変えてやることでそれなりの英文が出てくる、ということでもあります。

もちろん、この方法を使うためにはある程度自分に英語から日本語への翻訳ができる、という条件が必要です。一応英語の技術文書であればMSDNなどのプログラムのヘルプで読み込んでいるので単語の意味が調べられるのであれば問題ないレベルにはなっています。もちろんこの力がないと翻訳サイトを二回使う、という状態となりチェックが微妙になるのでは?と思います。さすがに二回の翻訳を行うと原文と離れた文となることも多くなるのでその辺はうまくやりましょう。

 

WindowModePatchで別方向の進展がありそうな感じ

忙しい合間を縫って動いています。まあ、これのために英語版のサイトを作ってみたというのが実情だったりします。一応ゲームの対象は日本語だけではないですし、WindowModePatchのフロントエンド側には日本語版のWindows以外で起動した場合には英語でメニューなどを表示するように仕掛けがしてあるのでいろいろな人と協力してやっていくのにはこういうことが必要になるのでしょうね。あとはトップページとか更新履歴なんかも英語になればもっといろいろな人に広がるなど情報が得られるのではないか?とも考えています。

また、Twitterやニコニコ動画などからのリンクがあったりといくつか確認している限りではWindowModePatchはある程度役には立っているようですのでうれしいです。こちらの方向も進展していくと面白いと考えています。忙しいので更新は難しいかもしれませんが動作情報などは受け付けていますので。

 

WindowModePatch 0.68 Alphaを公開

実はこの記事を書く時点で公開してからすでに一週間経過していたりするのですがそれはおいておきましょう。前回の更新から半年前後経過していて忘れ去られていたのかといえばさにあらず。いまだけ時間を作ることができる状態だったことと気になったプログラムが残ったままになっていたので自分でサンプルを作って仮想マシン上で動作をテストすることで修正点を見いだすというマッチポンプではないけれども似ているようなことを二週間前くらいから行って更新にこぎ着けました。

 

主な更新は二つ

基本的には以下になります。

  • DirectDrawをDirect3Dでエミュレーションを行う場合に8bitパレット処理における互換性の向上
  • パッチ対象の拡張子がexe,dll以外である場合に処理が行うことが非常に困難であったので修正

サンプルプログラムを作ってテストしていたのは前者で特に文字列描画で文字色が本来白色にならなければならない場合での互換性が向上しているはずです。検証プログラムを詳細に書いてみて初めてわかる仕様というのもあるのですね…。後者は特に外部モジュールを読み込んで動作するタイプの場合に本体に非推奨の完全パッチ処理を行いライブラリのロード時に強制的にWindowModePatchを読み込ませるか外部モジュールそのものにパッチ処理を行うか…という選択肢で外部モジュールの拡張子がdllではなかった場合にリネームしないとパッチ処理ができないのが面倒ということで処理を変えました。元々パッチ処理では対象が実行ファイル系かどうかの判別が入っているので問題はないのですが、実際にそういうことが必要になるゲームに出会うとさすがに変えたくなるということだったりします。

 

付け加えようとしていた機能はなんだろう?

機能の追加については数ヶ月前に思い立ったことなのでどうしようとしたか今の自分には理解できない…じゃなくて。おそらく途中で解像度を切り替える機能とかのはずなのですが機能が中途半端に実装されているので今回の更新では対象としていません。というか数ヶ月前の私は最終的にどの形にして実装をするつもりだったのか、について今の私にはわからない、という状態だったり。おそらくは対象のゲームと関係のないキーの組み合わせを入れると別のダイアログが表示されて画面の解像度をリストから選ぶか入力するか、という感じだと思うのですが…。まあ、余裕があれば適当に実装してみたいと考えてはいます。

 

自分一人での更新も難しくなってくるのかな

フリープログラマというのも自分で宣伝できなかったり仕事を受ける人脈がない場合はフリーターより悪い状況と見えるので真面目に職に就こうかと思い活動しています。そうするとこのWindowModePatchのメンテナンスも全くできなくなる、ということになる予感がしておりもったいないような気がしているのでいろいろと方策を考えています。信頼できるほかの人にソースコードを更新できる権限を持ってもらって対応できるゲームを増やしていったり情報を集めたり、などですね。

なお、WindowModePatchに関するWikiもこのサーバー内に設置してあり、容量制限もつけたのでデザインが整ったら…と思っていたのですが使っているWiki(MediaWiki)が昔に記事を書いたときから見るとかなり更新されてしまったためにどうしても情報を書くときに使おうと思っているWikipediaのテンプレートであるInfoboxが正常に取り込めないという問題にはまっていて抜け出せないのですね。はてさてどうするのがよいのでしょうか…。