■ビットマップのダミーアクセス

めったに気になる場面に出くわすことはないが、いったん気になり出すとどうしても我慢できないということがある。例えば、Windows用のプログラムを組んで、ピクチャボックスにビットマップファイルをロードしたとしよう。


Picture1.Picture = LoadPicture(App.Path + "TestPic.bmp")
感覚的には、これでPicture1と定義されたメモリエリアに、TestPic.bmpのデータがロードされたことになる。もちろん、画面表示がオン(Visible=True)となっていれば、何度テストをしても即座に表示されるに違いない。しかし、厳密にはロード後にRefreshメソッドが実行されるか、もしくはそのイベント処理が完了するまでは表示されていない。こんな微妙な時差でさえ、知っていればこそコントロール可能なのだ。

では、このPicture1が表示オフ(Visible=False)の場合はどうだろう。さらに、こういったピクチャボックスを画像データとして複数用意したら……。実は、とっくにご存知かもしれないが、Windowsではメモリの有効利用を図るために、ハードディスクを仮想メモリとして勝手に利用している。そのため、こちらの気持ちとは裏腹に本体メモリにロードされていないことがある。

もちろん、そうした画像データをアクセスすると自動的に本体メモリに入るのだが、そこで問題になるのがアクセスによって生じるタイムラグ。つまり、瞬間的にせよ停止状態に陥ってしまうのだ。リアルタイムで動かしているゲームにとって、これが気にならないわけがない。実際、あの『おたすけ忍風伝』では剣の最初の一振りにこの症状があった。正確には剣の一振りというより特定ビットマップへのアクセスによる遅延なのだが、因果関係はわかってもどうにもなかなか直らない!

結局、試行錯誤の末にたどり着いたのが「ダミーアクセスをする」という、どちらかというと不本意な方法だった。具体的には、BitBlt関数を使って小さな画像を別のビットマップに転送しただけ。簡単が一番……ということであれば優秀な解決策だが、見るからにエレガントさに欠ける無骨なやり方といえる。しかし、とにかく結果オーライなのだから、頭の片隅に覚えておいて決して損はないだろう。