OS/2 プログラミング実験

１．OS/2でゲーム・プログラミング(2001/03/18)

　OS/2ではアクションやシューティングのようなゲームは、作り難いと言われています。原因はPM環境の速度の不足とか。その速度を補う為にDIVEと呼ばれる画面の高速書き換え用 APIもサポートされました。
　しかし、本当にPM環境は速度不足なのでしょうか？PCのハードウェアそのものは、ちょっと前と比較しても格段に高速化されているのに？
　最近の3Dのリアルタイム・アクション系のゲームには、確かに、速度が不足しているかもしれません。このような複雑な表示を行うゲームでは、高速なビデオボードへの対応が進められているように描画速度が十分という事はないのかもしれません。しかし、では実際にどの程度の遅さなのでしょう。アクションゲーム等は全く無理な程遅いのでしょうか？
　実際に試してみると、そんな事は無いようです。他のOSのGUIの画面更新の速度も、見た目はそんなに早くありません。同じハードウェアを使い、ドライバが同程度の出来ならば、やはり、性能は同程度という事で納得できます。
　そこで、OS/2でのゲーム・プログラミングです。簡単なゲームを作成する事によって、OS/2でどの程度の事が可能なのか試してみようと思います。

　まずは、開発環境ですが、一般に売られているモノにしたい気持ちはありますが、実際の所、最近では店頭で簡単に入手はできなくなっています。
　そこで、誰でも入手可能でフリーな開発環境という事でemx/gccを開発環境とします。個人的には、Pascalも捨て難いものがありますが、手持ちの資料が全てCである事や、しばらくPascalを使っていない事からこれを使う事にします。
　今回はOMF形式を使用する為、別途OS/2付属のリソース・コンパイラとリンカーの導入が必要です。

　ここでのゲームはPMプログラムです。そこでウィンドウのオープンやイベントの取得などPMプログラムの基本的な骨格のみを記述したスケルトンプログラムを用意します。今回は書籍のサンプルなどをざっと見て最小限と思われるコードを作成しました。これに必要なコードを追加していきます。
　ウィンドウのサイズは、基本的にVGAサイズとします。640×480ですが、これ以上のサイズだとそれだけでデータが大きくなりますし、フルスクリーンのゲームでも実際には320×240か640×480が基本ですから特に問題は無いと思います。

　テストに作成するゲームですが、簡単という点でテニスゲームもどきを作ってみます。画面内で動作するのは、ボールとラケットが一個ずつで非常にシンプルです。

　最初にボールを追加してみます。GPI関数を使って、クライアント・ウィンドウに円を描画します。移動はタイマーを使う事にしましょう。処理が重くメッセージ・キューを圧迫してPMの動作に支障が出るようならば、スレッドを分けても良いのですが、取り敢えず最初は タイマーで様子を見ます。一定時間毎にボールの座標を変化させます。移動結果がクライアント・ウィンドウの外になるようなら座標の変化量をプラス・マイナス逆にする事でボールがウィンドウ外に出てしまう事はなくなるでしょう。
　次はラケットです。これもGPI関数を使って長方形を描画します。キー入力によって座標を変化させます。ボールとラケットの座標が重なるならば、ウィンドウ外に出る場合と同じく、ボールの座標の変化量のY成分をプラス・マイナス逆にします。これでラケットに当 たったボールは、上方に反射するハズです。

　さて、コンパイルして実行・・・。一応動作していますが、チラツキますね。

　チラツキを防ぐオーソドックスな方法としては、オフ・スクリーンを使う方法が良く知られています。これは、ボールやラケットの描画は仮想的な画面に行い、描画結果をまとめて表示するようにする方法です。本来はビデオの画面更新と同期を取らなければなりませんが、更新単位の制御だけでもある程度の効果が見込めると思います。
　オフ・スクリーンを実現する為に、仮想画面用のデバイス・コンテキストをメモリー上に作成し、プレゼンテーション空間のハンドルと関連付けます。描画をまず、このプレゼンテーション空間に行い、その結果を仮想画面単位でクライアント・ウィンドウにビット・ブリットします。

　さて、再度コンパイルして実行・・・。チラツキはマシになりましたが、妙に速度が遅くなりましたね。こんなものなのでしょうか？

　オフ・スクリーンを作成する時の設定を見ると1画素辺り8ビットになっています。一般的なゲームという事で256色を想定して8ビットとしていました。しかし、プログラム的には前景色と背景色の2色しか使っていませんからここは1ビットにできます。これで描画時のデータが少なくなるハズです。

　さて、実行・・・。今度はそれなりに満足出来る速度で動作しているように見えます。

　しかし、出来れば256色はサポートしたいところです。モノクロでもゲームのアイディアとデザインしだいで良いものは作れると思いますが、多色カラーが使えればそれだけで見栄えがしますし、表現の自由度が上がります。
　そうなると、高速に描画が行えるように何等かの方法を考えなければなりません。ここまでプログラムの実行は16万色のPM環境で行って来ました。では、他のモードではどうでしょうか？PM環境の色数を変化させて同じプログラムを実行して見ましょう。プログラムは8ビットカラーの設定に戻してあります。

　実行してみると、おっと、256色環境の時に思いがけず高速に動作するじゃないですか！これなら、ゲームを実行する時に256色環境にすれば、結構普通のプログラムで行けそう・・・。しかし、他のプログラムも動作している環境でゲームの為だけにわざわざ256色環境にするのはちょっとねぇ。残念ながら、現在のOS/2PM環境は動的に画面モードは切り替えられないので、必ずリセットが必要になってしまいます。ここはやはり、どのモードでもそれなりの速度を確保したいところです。

　8ビットカラーのデータを256色PM環境で使う場合が最も高速であったという事は、表示の際の色変換に速度低下の原因があるという事でしょうか？

　では、まず色変換をどの環境でも最小にする方法を考えてみます。

　まず、内部処理はどうなっているか判りませんが、パレットを統一する事からやって見ましょう。見かけ上は256色しか使いませんから、オフスクリーンも表示用のウィンドウも必要なカラーは256種類で良いハズです。256色のパレットを用意して使用する全てのプレゼンテーション空間にセットします。

　実行・・・。あまり変化があるようには見えませんね。単純にパレットを統一するだけでは駄目なのでしょうか？

　パレットの使い方が今ひとつ良く解っていないので、正しく設定出来ているかどうか判りませんが、簡単に速度は向上しないようです。DIVEを使用すると向上するかもしれませんが、これにはツールキットが必要です。

　実験では、モノクロなら満足できる速度になるらしい事が判りましたが、今回使用したシステムは、amd5x86 133MHzのモノで、Pen 200MHz位の環境に持って行くと８ビットカラーに設定していてもそれなりの速度で動作します。最近のシステムが軒並み500MHzオーバーで動作する事を考えると、あまり策を弄す必要は無いのかもしれません。

テニスもどき(12,394byte)