素材としてのグラフィックスを作成するとき、プログラムとの連携を考慮しておくのは当然だが、それ以外にも注意しなければならないことがある。それは、最終的に「ターゲットマシンは自分の使っているマシンではない」ということ。これを忘れると、思わぬ欠陥が表面化することになる。

すなわち、文字フォントのサイズ指定と同様に、カラーグラフィックスの場合には各マシンの表示能力の違いが問題となる。厳密には、搭載しているビデオメモリや画面設定の違いなのだが、True Color(32ビット)で開発したグラフィックスを、256色モードで再現しようとすれば必然的にカラー不足で色化けが発生してしまう。では、グラフィックスを256色以下で作成すれば問題解決かというと、そうは問屋が卸さない。

というのは、実際のゲーム画面では同時に複数のグラフィックスが素材として使われることが多いからだ。例えば、キャラクタパターンを集めたグラフィックス（256色）と、背景パターンを集めたグラフィックス（256色）のカラーパレットが異なっていたら、同時使用によって色化けが発生することは容易に想像がつくだろう。つまり、こうした状況を避けるためには、すべてのグラフィックスを共通のパレットにしておく必要があるのだ。

具体的には、各グラフィックスを作成するときにカラーパレットを一元化しておく。使用する色数は、ユーザー側のマシンを限定しないためには256色以下が望ましい。グラフィックスの都合で「256色以下では無理！」という場合には、きちんと使用条件を明示すること。要するに、制作時点でターゲットマシンへの配慮があればよいのだ。

さて、こうして作成したグラフィックスがビットマップファイル(.bmp)として保存されたとしよう。これをプログラムで利用するためには、ピクチャボックスにロードしなければならない。このときのロード方法には、次の２通りがある。

�@ 開発時にPictureプロパティとして読み込んでおく。
�A プログラム実行時にLoadPicture関数を使って読み込む。

どちらでもよさそうな気がするかもしれないが、開発時にPictureプロパティにファイルを指定して読み込むと、その瞬間にピクチャボックスのPictureプロパティに画像が貼り付くということを自覚しておかなければならない。つまり、グラフィックスの修正などでファイル内容に変更があったときは、改めてPictureプロパティのほうも指定し直す必要があるのだ。したがって、開発中は�Aのほうが手間がかからない分だけ気楽でいられる。

しかし、ピクチャボックスが使い回しのない単一用途であるなら、最終的にはPictureプロパティに貼り付けておくほうがよいだろう。なぜなら、画像もろとも実行ファイル(.exe)に組み込まれるので、結果的にファイル数が少なくなる。このことは、画像ソースを隠すという意味も含まれている。制作側にすれば、こういった裏側はできるだけ見せたくないのが心情なのだ。両者を使い分ける価値は、見かけ以上に高いといえるだろう。