第１０章　’８０年代アマグラマーと豆腐

２００６年９月２０日

タイトルでいきなり豆腐と書き出したのは、同世代の人達のみ思い出す、とある書物へのオマージュ。
判る人はこの後の展開も判って頂けると思うので、苦笑しててください。

さて、前章でグラフィックの為のスケルトンを作ってみたので、やっぱりクライアント領域に何か書き込みたいと考えるのが人情。
Win３２APIでは、このクライアント領域に対する描画手段が様々な形で提供されているが、ゲームと云えばキャラクター表示（？）なので、そこに絞って実験してみよう。
いやなに、遠回りするのが面倒臭いってことはここだけの話。

完成画像は以下のとおり。

先にばらせば、描画されている白い四角はビットマップである。
ソースをダウンロードして頂けば、そこに"WHITE_BOX.bmp"と云うファイルがあるので、手ごろな（？）ビュワーでご確認いただきたい。

つまり、今回のサンプルはビットマップをクライアント領域に出力するアプリケーションなのである。
これを応用することで、BMPファイル専用のビュワーが出来るなぁ、とか思ったが本筋とはずれていってしまうので、割愛。
あくまで私は、ゲームを作る為に実験を繰り返しているのだ。

と云ったところで今回のサンプルリスト。

今回の目玉は、なんと云っても"bit_map.rc"であろう。
ここに含まれるたった１行の宣言によって、"WHIT_BOX.bmp"は実行ファイルの中にリンクされる（！）。
まぁ、知っている人にとっては何のことは無い常識なのであろうが、画像データがこんな簡単にプログラムファイルにマージされてしまう現実は、私に少なからず衝撃を与えるものであった。

このようにマージされたデータは、プログラム内で"WHITE_BOX"の名前を与えられ、呼出される。
今回もWM_CREATEメッセージの処理として、読み込みとハンドルナンバーの割付を行おう。
この時、地味に（？）利用しているのが関数GetClassLong（）であるが、これはメインウィンドウのインスタンス取得に一躍買っている。
そもそも関数WinMain()でOSから与えられたインスタンスだから、どこかグローバルなところで変数に放り込んでやれば、わざわざこんなところでインスタンスの取得をしなくても良さそうなものだが、それをやってしまうと私のプログラミングスタイル（あったのか？）から外れてしまう。

ではそのスタイルの１つについて少し語らせて貰おう。
ここで時間があれば、全てのヘッダファイルをずらっと眺めて欲しい。
現在４つ存在するヘッダには、変数の宣言らしいものが一切無いことに気付いていただけるであろうか？
これは、完全にグローバルな変数の存在を許していないことを意味している（と思っている）。
なぜこのようなことをしているのかと云えば、変数の多重定義による混乱を防ぐ為、である。
実は私、変数の命名が非常に苦手で、グローバル変数がだいっきらいなのだ。
その結果、各ファイルから外へ開放されるグローバル変数は存在させないようにしているのである。
ネームスペース使えよ、なんて苦言が聞こえてきそうだが、その辺りはもう少し先の話題と考えているので、今はご容赦願いたい（って云うか判っているんですか？→私）。

ま、それはともかく、初期化が終わった白四角は、WM_PAINTメッセージ処理の一環として、画面に描画してやることにしよう。
ここでやっていることが（私にとっては）ややこしい。
順番に辿っていくと・・・

まず、メインウィンドウのクライアント領域のハンドルを取得しなければならない。
ここまでWindowｓOSのプログラミングをしてきて、全ての対象物にハンドルナンバーが割る振られていることにはなんとなく気が付いていたが、ここも例外ではないわけだ。
重ねて云うと、描画には、クライアント領域のデバイスコンテキストのハンドルを取得する必要がある。
デバイスコンテキストって云うのは、その名のとおりデバイスの状況を示すもの・・・ってますます難解だなぁ。
まぁ今回の場合、クライアント領域のグラフィックメモリを指している位の認識でいいんでは？（正しくありませんので誤解なきように）

次にクライアント領域のデバイスコンテキストとコンパチブルな（互換性のある）デバイスコンテキストを作ってやる。
コンパチブルって云うのはサイズや位置ではなくて、例えば１６bitカラーだとか３２ｂｉｔカラーだとかそんな属性が互換性をもっているってことらしい。

このコンパチブルなデバイスコンテキストに、白四角のデータをあてがってやるのが関数ＳｅｌｅｃｔＯｂｊｅｃｔ（）である。
私のイメージとしては、白四角のデータを専用に確保したメモリ領域に書き込んでやる感じ。
正確には間違っているが、把握しやすいのでこう考えることにしている。

そして次の関数BitBlt（）によって、このイメージをクライアント領域に貼り付けてやる。
白四角のデータが書き込まれたメモリの内容を、クライアント領域のメモリに転送してやる、と考えるとイメージしやすいのではなかろうか。

最後に、使ったデバイスコンテキストはOSに返してやろう。
この辺もメモリの開放に似ていて、ちょっと面白い（？）。

さて、今回はここまで、と思うわけだが、動きもしない白い四角は面白味がない。
次回は、なにか動きをつけてやることにしようか。
因みに、今回使った画像データはただのBMPファイルなので、他のデータを用意して差し替えてもらえば、その画像を表示させることが出来る。
え？サイズ？サイズはプログラム中に出てくる３２×３２でOK、って云うかそれ以上のサイズでもOK。
表示サイズと使うデータサイズが異なるって事は・・・結構面白いことに使えそうな匂いがするなぁ。