というわけで前回からの記事にもありましたとおりOpenGL対応版のテストを行いある程度できるとの判断で公開しました。いくつかテストをしましたが、まあまあと言うところだと思っています。
なお、組んでいる中でループで組めるのに処理を並べて書いていたりする部分も展開してコードもちょっとすっきりさせました。
OpenGL対応とは言っているけれども
確かに対応するためのルーチンを組み入れましたが、いろいろと細工をしています。
というか、OpenGLのプログラムを見ていたのですが、もしかして、と思っている項目が一つあります。それはDirect3D系には「変換済み座標系」を扱うための形式やらがあるのですが、どうもOpenGLにそのような定義がないように見受けています。そうすると、OpenGL上で3Dを扱うとき、常に「変換前座標系=ワールド座標系」を使わざるを得ないのでは？というものです。それにヒントを得てOpenGL系の内部処理を使うパターンを組んでいます。そのため、もし変換済み座標系をOpenGLで扱うものがあると内部処理パターンは見事な状態になると思います。
一応失敗したときにそれに対応するため、昨日の記事で「動作が遅すぎる」と書いた動作系も使えるようにしてあります。そちらの方はもう少し丁寧な処理をしているので遅くても良いのであればそちらを使う手もある、ということはblogに記述しておきたいと思います。おそらく迷ったときにはこの記事を見ることになるような気がしますので。
OpenGLは外部ライブラリを使うことが多くて・・・
プログラム本体が完全にOpenGLを組み入れていることってあまりないような気がします。たとえばGLUTやSDLなど。これを使っている場合はかなりむちゃくちゃなことをしないと動作しません。本体にパッチを行う以外にもたとえばGLUTの場合だとGLUTのDLLをWindowsのシステムディレクトリから拾ってきて一度WindowModePatchのパッチ処理を行った後、できたDLLを動作させるプログラムと同じ場所に放り込むというように。SDLを使っている場合はさらに悲惨です。ほとんどの場合、OpenGLのロードがLoadLibrary経由で実行されているのでそちらもどうにかしないとうまくいきません。
なお、その手の判定にはWindowsプログラマの小道具の一つですがDependency Walkerというユーティリティを使うと判定できます。これはDLLやEXEで使用されている外部ライブラリおよびその中で使用される処理を列挙するためのもので、これでGLUT(glut.dll)やSDL(SDL.dll)が使われているかどうかを見ることができます。普通にフリープログラムなので持っておくとちょっと楽しいかもしれません。ただし、基本的に英語環境を想定しているためか、プログラム名までのパスに日本語文字がはいるとロードに失敗します。そのため、ロードしてみるときはパス名およびファイル名はすべて半角文字にしましょう。
これでさらに汎用性アップ？
GDI系、DirectX系、OpenGL系とWindowsで使用されている描画処理であればそれなりに対応できるようになったような気がします。個別に見ればうまくいかないパターンはいっぱいありますが、古いゲームであればウィンドウサイズの変更ができるものがたくさんあると思います。新しいものだとDirectX11とかになるとグラフィックカードが対応していないと動くゲームがないので組み込みができる状態ではないのが悲しいです。
こういうものを作っているとちょっと気になっているのは「WindowsのADVシステムの中で初めてウィンドウサイズを変更することができ、かつ線形補間ができるもの何か？」という疑問だったりします。もしかするとOpenGLのテストで使っていたプログラムがそれなのでは？という思いさえあります。ちょっとしたトリビアになりそうな気がすることですね。似たような疑問としてはたとえば「初めて音のコーデックとしてOggVorbisを採用したADVシステムは？」とか。ADVシステムWikiでも作ったらこういう話題も集まるのでしょうかね。私の場合はプログラマとしての単なる興味ですので意味はほとんど無いとは思いますが。
