WindowModePatch」カテゴリーアーカイブ

WindowModePatchに最前面管理か…

なんかタイトルがおかしいですが、掲示板への返信ではなくこちらで書いてみたいと思います。

 

WindowModePatchをしばらく放置していたので少し修正してみた

掲示板の要望を見たから、というのもあるのですが、修正したものを作成してみました。一応最前面管理のような機能を追加して、アクティブウィンドウに関する処理を追加しています。処理を行わせた場合に不具合が出る、というわけではないのですが、そのオプションがないと不具合が出るプログラムがあれば詳細が詰められるのに…という状態で、まだ試作レベルとなってしまっています。今現在は設定には直接設定ファイルを書き換える必要があります。

 

ただし、まだ正式リリースはしない予定

WindowModePatchがWindowsDefenderによりウイルス扱いされた件があることもあり、様子見です。公開の準備はできている(Ver 0.72Alpha相当)のですが、このまま公開せずにスキップするかもしれません。いろいろと気に入らない点が見つかって、「直したいんだけれども…」といったところでしょうか。ここまで来るとプログラム上の処理の数が多すぎて追いかけるのが大変なんですよね…。まるでコンピュータウイルスの解析をしているような感覚に襲われたこの改良作業でした。

 

WindowModePatch 0.71 Alphaを公開

過去の記録を見てみると大体1年半ぶりの更新なんですね…。ちょっと感慨深いものが。とりあえずまだ生きていますよ~という意味とビルド環境の変化に対応するための試しという意味がかなり大きいバージョンとなっています。

 

開発環境をVisualStudio2017へと移行したためにいろいろと不具合が…

今回の大きな変化がこれです。一つ前まではVisualStudio2010だったのですが、今回は最新一つ手前のVisualStudio2017でビルドを行っています。というのも、昨年の段階でPCを組み直したときに環境をまっさらにした関係でVisualStudio2010の開発環境まで完全に吹っ飛んでしまったのが大きかったのと、その後開発環境を戻す余裕がなくなったためにどうせならとVisualStudio2017を購入したためにさらに開発環境の再構築に時間がかかってしまったのが大きかったです。実際にプロジェクトの更新だけではなくソースコードの漢字コードを変換していったり、ランタイムライブラリの動作が変更されているものがあったために対応する処理を書いたりするなどがあったためだったりします。

まあ、副産物としてWindowModePatchの設定ファイルの漢字コードをUTF-8に変更しております。もちろん、旧の設定ファイルであるShiftJIS形式でも読み込めますし、UNICODE形式で保存されても読み込めるようになっています。この「複数文字コードに対応したテキストファイルの読み込み処理」が作られたのがちょっと大きいです。こういうフリーソフト側に使うだけではなく仕事で作成するツール類にも使えるのが非常に大きかったりします。

 

一応DPIのスケーリング処理に「暫定的に」対応

といってもやっていることは「スケーリング処理をアプリケーション側で行うように見せかけているだけ」だったりします。実際、WindowModePatchは解像度変換機能がメインなので逆に現在のモニタの解像度に合わせた設定ができないと微妙に困るからですね。Win10の初期段階のものだと設定を正しくしないとマニフェストファイルにスケーリング処理対応の方法が書かれていない場合にWinAPI側で勝手にスケーリングされて設定の数字が誤ってしまう、という現象もありましたので。

一応この処理はWin10の1703(Creators Update)以降であれば(WindowModePatchが対応できれば)対応処理が入ると思います。問題はそれより古いバージョンでの動作。一応対応コードは書いておいたのでWin8.1以降であれば動いて「ほしい」コードなのですが、手元でやったいる段階では動かないことが多かったです。これについてはDPIAwarenessと呼ばれる部分の処理の説明をもう少し読み込んだ方がよいかもしれません。実際、はじめに思っていた設定値の役割が完全に逆になっていたことに気がついたのはかなり後だったりしますので。

 

対応したソフトが増えていないだろうとは思う

頑張ってDirectX5時代のDirect3Dに対応しようとした形跡が見えるコードは今のところ封印しておりますし、やりたいことも増えてきているながらやらなければならないことも増えてきていますので…。頑張って増やしていければな~と思いながら。

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に更新開始を書いてから今までかかってしまったわけですし。そうなると本当にコード公開やら何かを考えないと(これが宝かどうかは別として)宝の持ち腐れのようになるのかもしれませんね。