カテゴリー別アーカイブ: WindowModePatch

4Kモニタだと解像度がいろいろと大変なことに

C94の感想をとりあえず置いておいて、こっちの話題を書いてみたいと思います。今回、4Kモニタが大分安くなってきたのでメインPCのメインモニタを4Kのものに交換してみたわけです。今まで使っていたモニタはサブモニタとなり、なかなか豪華な構成になったのですが、モニタの物理的なサイズが大分小さいために・・・

 

4Kの素の状態だと文字が細かすぎてやばい

ブラウザとかに書いてある文字がほとんど読めない…という現象に。モニタ本体もそこまで大きいものではないので細かさが半端ないです。この状態で常用するのにはかなりの視力が必要となることは先に書いておきます。で、ここからがWindowModePatchも関わる問題なわけで…

 

ゲーム画面が小さすぎて見えない。しかも表示スケール処理で解像度設定が間違える

という問題が起こるようです。前者は簡単でモニタの物理的なサイズが2倍になったわけでもないに画面の解像度だけが長さ比で2倍以上になり、ゲーム画面がかなり小さくなってしまった訳です。もちろん、ここで出てくるのが拙作のWindowModePatch。こいつでゲーム画面のサイズを4K用に変更してやればうまく使えるゲームであれば解像度変換ができるので困ることではなかったのが幸い。

で、もう一つの問題が、「文字が細かすぎてやばい」にからんでいて、さすがに素の4Kでは文字が読めないのでWindows側の設定でスケーリング処理を行うわけですが、それをするとどうもプログラム本体に伝わる画面の「本来の」サイズがWindowModePatchの処理の時のように変換されて伝わる、という現象があるようです。これ自身は何も間違いはないのですが、この設定は

  • すべてのプログラムに対して同一の設定がかかってしまう
  • スケーリングに内部的に対応しているプログラムであればその制約を受けないようにできる(様子)
  • WindowModePatch側は現段階のプログラム(Ver0.70Alpha)ではこれを知らないのでスケーリング処理を受けた状態の解像度を指定しないとサイズが間違える(4Kの状態ではなくで4K÷スケーリング倍率の状態での解像度を指定する必要がある)

ということで、影響をもろに受けることが発覚してちょっと大変に。この処理については内部的にごまかさないとだめですね…。

 

スケーリング倍率が大きくなるとマウスの移動が大変に

これもどうにかする必要があるかな~と思い始めた課題。マウスカーソルの移動量はどのWindowsだろうと変わらないのでスケーリングにより移動量が減ってしまったように見える、という現象です。FullHDのモニタだったらトラックボールマウスということでボール半回転をさせると画面の端から端まで移動できた(つまり、約1800pxの移動)ですが、4Kモニタになると端から画面中央までしか来ないわけです。するとスケーリングにより2倍表示された状態を考えると移動量が半減したように感じる、というわけです。マウスの移動量を上げると今度はほかのプログラムで本来の移動量に準拠した移動ができなくなるので設定の変更はしたくないのだが…というところです。まあ、そうなるとWindowModePatchがかかっているプログラムだけマウスの移動量を何らかの方法で調節できるような設定がほしいな~というところとなっています。

 

改良点が見えてきた…かな?

4Kになってプログラムを作るときのように膨大な量のテキストを表示させると便利な状態ではうれしい画面の広さが手に入ったので、ここは対応ソフトを増やすとともにWindowModePatchの次回改良点として考えてみたいと考えています。…改良の時間はどうなって作れば?

しばらく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が正常に取り込めないという問題にはまっていて抜け出せないのですね。はてさてどうするのがよいのでしょうか…。