久しぶりにWindowModePatchの大規模改良の予感です。
掲示板にあったゲームがOpenGLだったので「対応していない」と返したところからちょっと調べてみて微妙なことが発覚。
OpenGLもDLLだったのね・・・
とてつもない思い込みでした・・・。
というのも、私が初めに「OpenGLで動かしているADVゲーム」を見たのが2004年のことで、そのときに調べたことが思い込みになっていて、このことがわかるまで丸9年、というわけです。その思い込みの原因となったADVゲーム名は・・・と。この段階で出すのはちょっとまずいので伏せます。なお、私が「OpenGLを使って動かしてるADVシステム」として確認しているのはこのゲームだけだったような気がします。OpenGLはクロスプラットフォームとしては優秀なのですが、ADVゲームはほとんどがWindows専門(いまではスマートフォンで動くシステムもあるが)というのと、WindowsのゲームではDirectXを使うのが簡単、というのがあるのでそれはまあ見ないですよね・・・。
で、DLLだったことに気がつかなかった理由が「Direct3DとOpenGLを選ぶためにゲームがランチャーと本体実行ファイルに分割されていて、DLLのリンク状態を調べていたのがランチャーだったために「DLLではなくスタティックリンクだろう」と考えてしまったこと」にあります。今になって再度見てみると本体実行ファイル側にはちゃんとDLLがリンクされていたのでもう何とも・・・。
ちなみにOpenGLの「基本ランタイム」はopengl32.dllというシステムDLLで、これはWindowsに付属しているものです。そのため、各WindowsのバージョンごとにDLLがちがいますので間違ったバージョンのものをコピーしてもまともに動きません。で、そのDLLから各グラフィックドライバに指示を飛ばすという構造になっています。さらにいうと、OpenGLを使うときによく「GLUTを使う」という話が出てきますが、このライブラリの本体ファイル(glut32.dll)もopengl32.dllをリンクしてそちら側に処理を委譲していることに注意が必要です。
ただ、常にopengl32.dllを使っているのか？と聞かれると半信半疑だったりしているのですが、使っているなら・・・
そうなるとWindowModePatchでも対応は不可能ではない
そもそもWindowModePatchの動作原理は「描画処理を一部上書きすることで表示される画像の大きさを変更する」ことにあり、スタティックリンク(=処理が埋め込まれているため処理コードの検索がほぼ不可能)ではなくDLL(=各処理ポイントが明確になっている)であれば対応は不可能ではない、ということになります。少しやる気がわいてきますね。
ただ、対応はとてつもなく大変です。OpenGLにも内部的なバージョンがあるので各バージョンの動作がどうなるのか？といった問題やAPIのプロトタイプを今現在全く見たことがないのでどの部分を通過させてどの部分に処理を追加するのか？、さらにはOpenGLのプログラムの大半がglut32.dllなど別のライブラリを通して使っていると思われるのでこの場合どうすればよいか？といったことなど。問題点は山積みです。
暇ならばがんばってみますか・・・
できると言うことであれば対応を考えてみなくもないです。ただ、これはかなり大規模になりそうなので暇でないときはできないです。仕事がどうなるか、次第で。
