T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« 作者環境に適用 | トップページ | トランスポータの変更を開始 »

Mirror-DTCのβ1版を公開

今は、Mirror-DTC Ver1.4.4の開発フェーズで、今日、公開していたβ版をβ1版に差し替えた。Ver1.4.4は、より様々な環境で快適に使える様な更新を行なっているので、Ver1.4.3で十分、という人には有り難みは少ないのだが。

このブログをずっと見ている人は、Mirror-DTCの次のバージョンはVer1.5.0で、Webブラウザをクライアントにできる機能を追加する予定! という話は何度か見た筈だ。

にも関わらず、Ver1.4.3の次にVer1.4.4を開発しているのは、基本的な所をもう少し改良しておく必要を感じたからだ。

具体的には、作者的には、去年の秋頃に、Mac mini M2 Pro + 4kモニターを購入して使い始めたのだが、それ以前に使っていたフルHDモニターを捨てるのも勿体無いので、Mac mini M2 Proは4kモニター + フルHDモニターのデュアルモニター構成で使い始めた。

そうすると、作者的にも、すぐに気がついたのだが、ディスプレイの配置を横に並べる格好にして、別マシンから、Mac mini M2 ProをMirror-DTC接続で操作しようとすると、合成ディスプレイ表示時には、マウスポインターが右端まで移動しなかった。

その理由は、Mirror-DTCのプロトコル的に、データ転送量をケチっていたので、マウス座標はx,y共に12ビットで表現していたからだ。

つまり、12*2 = 24ビットで、+8ビットのフラグ領域を持たせる事にすると、32ビットで、ひとつのマウス移動コマンドデータを構成できるので、高速かつデータ転送量が少ないネットワーク転送が可能! という感じだった訳だ。

Mirror-DTCの初版を開発していた2009年頃の作者環境は、MasterReversiのFFOテスト結果 (Ver1.0.2)を見ていると、メインマシンがCore2Quad Q6600のGateway製デスクトップPCである事が分かるのだが、使用していた液晶モニターは、1280x1024のスクエアタイプの17インチ液晶モニターだった筈だ。

当時、ブロードバンドルーターの横には、Pentium4 640 (Prescott)を搭載したGateway製のデスクトップPCを置いていて、MasterReversiユーザー向けに、MasterReversi Serverなんかを公開していた。

で、当初、このPentium4マシンは、マイクロソフトのリモートデスクトップ接続を使って操作していたのだが、少なくとも当時のリモートデスクトップ接続は、画像転送がイマイチだった、みたいな事もあって、作者的には、自前でMirror-DTCを開発して、それを使って、操作する様になった。

なので、初版の頃のMirror-DTCが扱っていたサーバーの解像度は1280x1024ピクセルのシングルモニター構成だった訳だ。

で、Mirror-DTCのReadme.txtを参照してみた所、初版リリースは2009年10月6日なのだが、その10日後の2009年10月16日にはVer1.01をリリースしていて、その変更項目のトップが「デュアルモニタ対応機能の追加」だった。

それ以降、Mirror-DTCが扱えるモニター数は最大2モニターだったのだが、今回、15年ぶりに、扱えるモニター数の最大が8モニターに増やされた。

シングルモニターからデュアルモニター対応に改良するのに10日しかかからなかったにも関わらず、デュアルモニターから8モニター対応に改良するのには15年を要した! というのは不思議な話なのだが、これは、少なくとも作者的には、トリプルモニター環境というモノの必要性を感じていなかったからに過ぎない。

つまり、技術的には、デュアルモニターから8モニター対応に改良するのは、シングルモニターからデュアルモニター対応に改良するよりも、よっぽど簡単だったのだが、作者的には、そうする事で、必要でもない、というか、ユーザー的には絶対に利用できない機能を、Mirror-DTCに実装してしまう事を嫌った訳だ。

と、いう事で、Mirror-DTCがデュアルモニターまでしか対応していなかったのは、ある意味、ミニマリズムに近い話だった訳だ。

しかし、流石に、15年も経過すると、巷の状況は変わってきた。

具体的には、一般ユーザーでも、モニターの解像度的にはフルHD = 1920x1080ピクセルくらいは使う様になったし、特にMacユーザーの場合、4k = 3840 x 2160ピクセルくらいは使う様になった。

そして、15年の歳月を経過しても、トリプルモニター環境が一般的になる事は無かった筈なのだが、特にMacの場合、SideCarだとかAirPlayを使って、iPadだとか他のMacに接続されたモニターを仮想的に拡張モニターとしても使える様になった。

つまり、一時的に、それらを使ったトリプルモニター環境を構築する様な機会は増えたかもしれないので、作者的にも、4kモニターとトリプルモニター以上の環境に対応させる事にした訳だ。

ちなみに、そうすると、まず、問題になったのは、冒頭に書いたマウスポインターの移動距離が12ビット、つまり、4096までになっている基本仕様だったのだが、Mirror-DTC的には、新しいバージョンは古いバージョンに接続可能! という感じで開発してきたので、この基本仕様を変更する事はリスキーだった。

なので、Ver1.4.4以降のサーバーに対してのみ、Ver1.4.4以降のクライアントは、4096を超えるマウス移動を可能にしているのだが、これは、従来とは異なる新しいコマンドを追加する形式で実装した。

対応モニター数を増やす変更については、基本的には、従来コマンドを継承しているのだが、従来は、パラメータで指定可能なモニター番号なんかが3までだったのを9までに増やした。

従来は、0:メインモニター/1:ディスプレイ1/2:ディスプレイ2/3:合成ディスプレイを示していたので、Ver1.4.4の9:は合成ディスプレイを示す事になったのだが、Ver1.4.4の3:はディスプレイ3を示している。

つまり、合成モニターのモニター番号を対応可能なモニター数の次にしたのが仕様的には宜しくなくて、作者的には、この問題があったから、ユーザーからのトリプルモニター対応要請に応じなかった! みたいな所もなきにしも非だ。

まあ、この問題については、クライアント的には、サーバーがVer1.4.4未満の場合、従来通りのモニター番号、つまり、合成ディスプレイを表示したい場合にはディスプレイ番号3を指定するし、サーバーは、Ver1.4.4未満のクライアントからの指定時には、モニター番号3を合成ディスプレイと判断するので、仕様変更を行なっても、互換性は保てている。

つまり、仕様的には、あまり綺麗ではなかったのだが、どの道、仕様を変更すれば、従来版は特別扱いしないと、互換性問題が発生する事を鑑みれば、上記の様な、一見、美しくない仕様も、大問題、という事でもなかった訳だ。

もっとも、実際の所、4kモニターを8台も横に並べた場合、合成ディスプレイの解像度は3840*8x2160=30720x2160ピクセルにもなってしまい、1ピクセルを32Bitで保存するとすると、256MB程度のデータバッファが必要になる、というのは、大問題だ。

その結果として、マシンによっては、画面キャプチャー用のGPUバッファが確保できなくなり、合成ディスプレイを表示できない! なんて大問題も発生する事になった。

なので、Ver1.4.4 β1では、合成ディスプレイの画面キャプチャーについては、GPUベースで動作するDesktop Duplication APIではなく、より基本的な、BitBltで画面キャプチャーする様に変更した今日この頃だ。

« 作者環境に適用 | トップページ | トランスポータの変更を開始 »

2024年5月
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。

    ポリシーと規約 - Google