■さっそうと重ね合わせ処理

APIのBitBlt関数を知ったからには、具体的な用途に触れるのは必然の流れ。いっぽう、ゲーム制作を目標に掲げた以上、キャラクタパターンの重ね合わせ処理も逃げて通るわけにはいかない必修コースである。となれば、BitBlt関数を使っての重ね合わせ処理は実に自然な展開といえそうだ。

@マスクパターン(背景表示部=黒)

Aキャラクタパターン(背景表示部=白)

これは、すでに「素材グラフィックスの作成」で披露した、おなじみ『おたすけ忍風伝』の主人公である。とりあえず、ピクチャボックスのPicture1に@とAが横並びに並んでいると思ってもらいたい。もちろん、これらは「Visible=False」で隠されている。各パターンのサイズは48×48ドットで、画面表示用のピクチャボックスはPicture2としておこう。

背景には、すでに何かが描かれているという前提だが、イメージがわかなければ一面真っ赤でもよい。とにかく、Aを単に転送したのではキャラクタの周囲の白を含んだ四角形となることだけは、誰でも容易に想像がつくだろう。そこで、最初に@のマスクパターンと画面とのORを取る。これで、@の白い部分だけが画面に合成される。次いで、AのキャラクタパターンをAND合成すると、相互に白い部分にある画像だけが残る……というわけだ。

つまり、最初に白抜きした部分にはキャラクタパターンが、Aの白い部分には背景画面が残ることになり、結果としてキャラクタパターンの重ね合わせ処理が完了するのである。このプロセスを実際のプログラムで示すと次のようになる。




表示位置は、とりあえず(0,0)としたが、これを変更するのは「お茶の子さいさい!」もいいところだ。それよりも、最後に忘れちゃいけないことがある。それは、表示画面への描画が完了したら、必ず更新(本例ならば …… Picture2.Refresh)をしなければならないということ。これを怠ると、いくら画面に手を加えても何の変化も起こらない。

逆にいうと、更新をするまでは「加工プロセスが見えない」ということになる。例えば、重ね合わせ処理で加工プロセスが見えたら、瞬間的に白抜き画像が表示され、チカッとフラッシュが焚かれたようになってしまうのだ。1回だけなら見逃せても、これが連続して発生したらたまったものではない。

これとは逆に加工処理に時間がかかる場合は、こまめに更新することで状態を把握することができる。長時間の待機は、プログラムが実行中なのか暴走してしまったのかわからないため、こうした配慮が不可欠なのだ。いずれにしても、画面に手を加えたらリフレッシュを忘れてはならない……のだが、やっぱり忘れてしまうことがあるんだよなァ。実際、そのためにどれほどの時間を費やしたことか……。その度に、人間とは間違いをする動物だと思い知らされるのである。