昨日グラフィックとテキストの重ねあわせ処理を調べていたのだけれど、最初はなんでこんな処理が必要なのかなとすこし考えてしまった。
::BitBlt(fOffScreenDC, x,y,w,h, fGraphicsWindowDC[fCurrentGraphics], x,y, SRCCOPY);
::BitBlt(fOffScreenDC, x,y,w,h, fTextMaskDC, x,y, SRCPAINT);
::BitBlt(fOffScreenDC, x,y,w,h, fTextDC, x,y, SRCAND);
2つ目のBitBltでグラフィックのテキスト部分の背景を抜いて、3つ目のBitBltでテキストをハメ込むのだ。 これは十数年前当たり前に語られていたテクニックなのだ。下記ページを見るとよくわかる。
BitBlt(応用編)
http://tgws.fromc.jp/prog/prog02.html
透過処理
http://zahyou.6.ql.bz/cgame/transparent.htm
指定された色を透明色にして描画する(低速)
http://www14.big.or.jp/~ken1/tech/tech9.html
画像の透過転送とマスクの自動生成
http://homepage1.nifty.com/CavalierLab/lab/win/transparent.html
けれど、もう重ね合わせなんて意識しなくともハードが勝手にやってくれるのですっかり忘れてしまっていた。
このテクニックはソフトウェアスプライトとしての使われ方がもっとも多いのではないだろうか。DirectXが誕生し、カラーキーによる透過転送ができるようになったくらいから廃れたのかもしれない。カラーキーも過去のものになってしまったようだが。
透明色（カラーキー）の指定
http://rina.jpn.ph/~rance/directx7/directx7study/ddraw/p033.htm
今となってはアルファブレンドもハードでできてしまうんだからね。
利用者はアルファ値を用意するだけで良い。
----
すごい古い話(25年くらい前）だけど、重ねあわせ処理で私が最初にすごいと思ったのは「アルフォス」というゲームの地上面と空中キャラクターの重ねあわせ処理である。こんなのはPC8801では不可能だと思っていたけど、森田さんと言う人が実現してしまった。
PC8801は8色グラフィックでRed・Blue・Greenがそれぞれ独立したビットマップを持っていた。そのうちの１つを地上面にあて、他の２つで空中キャラクターを表現するというアイデアだった。こうすれば重ねあわせはハードに任せることができる。表現できる色数は少なくなる（地上2色・空中4色）が、そこはパレットと中間色表現でカバーしていた。
もちろんこのソフトウェアはそういうアイデアだけでなく、当時考えうる最高の高速化テクニックが使用されていたのでゲームとして成立するに充分な処理速度も有していた。ゲーム自体はあんまり面白くなかったが。
森田さんは雑誌でZ80の機械語講座なども執筆しており、私はこの講座で実に多くのことを学んだ。当時はプリフェッチやらパイプラインやら投機的実行やら分岐予測やらスーパースケーラやらマルチコアとかはもちろんなくて、命令にかかるクロック数の足し算で処理速度が測れたのだ。「処理にかけるクロック数を削る=速くなる」なので、普通に実装するとかなり処理時間のかかる処理をクロック数を削るテクニックを使って如何に高速化するかという記事であった。たとえば、push命令による画面クリアとかループアンローリングを使った高速画面描画とか。
その技術は今となってはあまり役に立たないが、ソフトウェアは創意・工夫によって高速化できるのだということを学んだことは大きかった。