○地表のスクロール

EzGraphには画像をスクロールさせる機能はないので、
全体をずらして再描画することで実現するしかない。
しかし、これをEzPutの繰り返しで行うのは処理が重い。

そこで、地表をサイズ8x8のグラフィックパターン(以下タイルと呼ぶ)を
敷き詰めて表し、8ドット単位のスクロールを行う。
この場合、スクロール前後のタイルが同一の場合は再描画が不要になる。

たとえば、下の図で枠内の5x5が画面に表示されるとする。
1文字が森や木といった8x8のタイルなので、
実際は40x40ドットの表示となる。
左の状態で左に8ドットスクロールすると、右のようになる。

+----------+          +----------+
|森森森森森|森      森|森森森森森|
|道道道道道|道      道|道道道道道|
|道森森森海|海  →  道|森森森海海|
|道森森海海|海      道|森森海海海|
|道森森海海|海      道|森森海海海|
+----------+          +----------+

ここで、左右の枠内を見比べると、異なっているのは以下の部分だけである。

+----------+
|　　　　　|
|　　　　　|
|森　　海　|
|森　海　　|
|森　海　　|
+----------+

したがって、実際に再描画が必要なのはこの6か所のみであり、
「スクロール前後の差分をとって異なるタイルのみ描画」するようにすれば、
この例では25回のEzPutを6回に減らすことができる。

これは「テグザー」など8bit時代のパソコンゲームで使われた手法であり、
大幅に描画量を減らすことができる。ただし、以下のような弱点がある。

・敷き詰めたタイルの大きさ単位でしかスクロールできない。
　当然、1ドット単位でのスムーズなスクロールは不可能である。

・差分が小さいほど描画量が減るため、効率がマップのデザインに左右される。
　たとえば、2種類のタイルが市松模様状に敷き詰められているなら、
　スクロール時にすべて再描画が必要になる。

・EzGraphでこの手法を用いる場合、ダブルバッファリングは使えない。
　EzShowBuffer()を呼ぶたびに、画面全体を0から描きなおす必要があり、
　この手法のように現在の表示内容を部分的に描き変えることができないからである。


○ゲーム画面の表示方法

上記の手法でスクロールする地表や地上の敵を表示しても、
自機や敵機、両者の弾といった空中のオブジェクトを表示するために、
別途EzPutを多数呼び出す必要がある。
たとえば弾についてはEzFillBoxで小さい四角を描く、といった方法で処理を軽くする
方法も考えられる。

しかし、今回のような手法では画面全体を毎回描きなおさないため、
オブジェクトを新しい位置に表示するだけでなく、前回の位置に描かれているものを
消す必要がある。そのためには、オブジェクトの前回の位置にある
タイルを再描画すればよいが、任意の大きさのオブジェクトを
1ドット単位で動かす場合、複数のタイルにまたがる可能性がある。
したがって、描画処理がかなり重くなったり、
描画が必要なタイルの判定が複雑になったりする。

そこで、空中のオブジェクトもすべて8x8ドットの大きさとし、
8ドット単位で動かすことにする。そうすることで、これらも地表と同様にタイルで
表せる。

また、空中・地表のタイルは前者が後者の上に乗っているように見える必要がある。
透過色を使うことで、複数のXPM画像を重ねて描画できるが、
画像ごとにEzPutの呼び出しが必要となる。
そこで、あらかじめすべての組み合わせについて、重ねた画像を生成しておき、
空中・地表にあるものに応じて、対応する画像を表示する。

実際には、

敵弾                    1種   1bit
自機・敵機・自機の弾    63種   6bit
爆弾・爆発エフェクト     5種   3bit
地上物                 63種   6bit

の4階層にして、計16ビットで任意の組み合わせを表現している。

爆弾・爆発エフェクトを分けているのは、爆弾の周りや爆風の隙間から下の地上物を
見え、かつ爆風の上に重なった敵機なども見えるようにしたいため。
自機・敵機・自機の弾は互いに重なることがない
(自機で自弾は追い越せないし、自機と敵機・自弾と敵機はどちらかが破壊される。
敵機同士は重なって表示されたらどのみち見えない)ので、同じグループにしている。
敵弾だけ分けているのは、自弾や敵機に重なった敵弾を見失わないように、
重ねて表示できるようにするためである。

単純にすべての画像パターンを用意すると16bit=65536枚必要になるが、
実際は各層で実際に存在する数の積になるので、画像数を減らし、
2x32x6x32=12288枚程度に抑えている。
さらに、実際には必要ない組み合わせとして、
・自機と落下中の爆弾(重なることがない)
・落下中の爆弾と敵機(爆弾は完全に隠れる)
などを省略できるので、最終的に4000枚程度を生成している。

8x8の画像なのでデータ量的にはもっと多くてもよいが、一枚ごとに
Xlibに生成を要求するため、ゲームの初期化時間が長くなる。
また、一枚ごとにリソースを消費するので、むやみに増やすと環境によっては
動作しなくなる可能性がある。