ゲームプログラミング/画面出力
Windowsでゲームをつくる際、マイクロソフト社の提供する開発ツールを使ってゲーム開発する場合には、画像レイヤー表現のための描画機能の都合により、実質的に DirectX プログラミングだけに開発ツールが限られます。
なぜなら、PNGやJPEGなどビットマップ以外の画像形式のダブルバッファリングをしようとしても、DirectX 以外の GDI+ や CImage などのWindows標準の画像開発ツールでは不可能だからです。ダブルバッファ用画面を作成するときに必要になるハンドル HBITMAP には透明色がないので、原理的に絶対、GDI+ や CImage では透明化をできないのです。
重要な点としては、作成しようとしているゲームがたとえ3次元ポリゴンを駆使したゲームでなくても、たとえファミコン的な平面的グラフィックのゲームであっても、DirectXのレイヤー表現の機能が必要になってしまうという事です。
なお、DirectX の文法は Visual C++ の文法に則して書かれるので、Visual C++ の知識自体は、無駄にならず、再活用できます。
さて、参考リンク先のサイト(『教えて!goo』の質問掲示板)がいつまでも存続するとは限らないので当wikiでリンク先の説明内容の概要を述べておきます。
まず、ゲーム制作では画面のチラツキを押さえるために、ほとんどのゲームで「ダブルバッファリング」という手法が必要になります。なお、このダブルバッファリングはDirectXまたはDXライブラリを使うと、ほぼ自動的に画像表示の際にダブルバッファリングの設定を行ってくれるので、これらのライブラリを用いる場合なら普段はダブルバッファリングを意識する必要は無いです。
そして、ゲーム開発では、PNGなどの背景の透過のある画像が必要です。なぜなら、もし背景を透過させないと、たとえばマップ上を歩くキャラクター画像を背景上に表示したい場合でも、キャラの周囲の画像ファイル幅の四角い枠ごと表示されてしまうからです。そのせいで、背景の一部が、キャラ周囲の四角い枠で塗りつぶされてしまいます。
つまり、ファミコンのスーパーマリオ1やドラクエ1のようなゲームですら、Windowsでは、キャラクター画像の周囲を透過させないと、そういうシステムのゲームは作成できないのです。
なお、実はDXライブラリによる透明の機能は、PNGなどの透明部分を黒色 (R,G,B)=(0,0,0) に変換しています。そして(0,0,0)のドット部分だけ描画をしないという仕組みで、DXライブラリでは透明を実装しています。なので、DXライブラリ用の画像には、(0,0,0)を色としては使用できません。むりやり使用しても(0,0,0)のドット部分が描画されないので下の画像が見えてしまいます。なのでゲーム用のイラストを描く場合などは色(0,0,0)の使用を避けなければなりません。なお、たとえ色が(20,20,20)くらいでも人間の目では充分に黒色に見えます。(1,1,1)だと保存などの際に色情報が変化した場合に(0,0,0)になって透明化してしまいかねないので、もし黒色を使うなら余裕をもって(20,20,20)くらいにしておきましょう。裏を返すと、実は2Dゲームでは、完全な黒色を再現するのは基本的に無理です。もし仮に透明色を変更したとしても、今度はその色が使えなくなります。
なお参考ですが、これはゲームだけなく、実写映像の合成(w:クロマキー合成)なども同じような仕組みです。実写撮影では青色がよく透明色に使われます(w:ブルーバック撮影)。だからよく、テレビの合成シーンの撮影では、青色の背景ボードの前で役者が演技してたりします。テレビ番組の収録映像などで、そういう撮影シーンを見たことある人もいるでしょう。(おそらく、当然ですが、そういう合成シーンの撮影では、役者の服などでは青色を使えなくなるハズです。) ただし、若干の違いとして、クロマキー撮影ではキー色と似たような色まで透過してしまいま。しかしゲームのデジタル画像の場合、似たような色は透過せず、キー色と全く同じ色だけが透過するので、なのでゲームでは(0,0,0)は透過するけど見た目が黒っぽくても(20,20,20)は透過しないわけです。」
実を言うと、上述のようなDXライブラリの透明色の仕組みは、DXライブラリを使わない場合のwindows標準の透明の実装方法と原理的には同じです。つまり、windowsAPIには特定の一色を描画しない機能によって、透明機能を実装する機能があります。そして実はDXライブラリの透明機能は、windowsAPIのその機能を流用しています。
なので原理的にはPNG画像を使わなくてもwindowsAPIだけでも透明の機能は実装できるのですが、まあ、せっかくPNGという規格があるのでそれを活用したほうがラクだし、ゲーム処理速度などの都合でDXライブラリを使うほうが効率的でしょう。
さて参考知識を述べるなら、 DirectX以外の GDI や CImage の提供する関数群(たとえば CImage の Draw 関数など)を使うことで、チラツキはありますが、とりあえず、マップ上にキャラクターチップのPNG画像の背景部を透過させる事だけなら可能です。
しかし、Windows標準の GDI+ や CImage の提供する関数群は、ダブルバッファリングに対応していないのです。一方、Windowsが標準で提供するダブルバッファ用のBitBlt などの関数は ビットマップ用に作成されているので、その際に HBITMAP ハンドルを定義して画像をそのハンドルに代入しなければいけないのですが、そのHBIMTMAPへの代入の際に(元のPNG画像には存在していた)透過情報が失われてしまい背景が塗りつぶされているビットマップ画像に変換されてしまうので、もはやキャラクター周囲が透過しなくなり、せっかくPNG画像を使っていた意味が無くなってしまいます。
このため、GDI+やCImageによる、提供されたAPIをそのまま利用するような標準的な方法では(あくまで「標準的な」との条件付きですが)、標準の方法では絶対にPNG画像のダブルバッファができないのです。
非標準な方法なら、可能です。ビットマップ関連の関数には、画像を1ドットずつ読み取って特定の一色を透過させる機能があるので(Win2000以降なら「TransparentBlt」という関数があります)、そういった関数を利用する方法もあります。ですが、それだと、
などの欠点があり、大変に不便です。
あるいは、透過機能をもった独自の画像形式などを作って、それを読み書きする関数を使えば、透過自体は可能ですが、しかし労力が多すぎて、実質的な意味がないです。また、独自機能なので、ハードウェアの支援なども受けられず、処理速度が低下する可能性が高くあり、そういう理由からも実質的な意味がないです。
なので、透過画像のダブルバッファ対応のため、Windwosゲームプログラミングでは開発ツールの画像ライブラリが、DirectXまたはその互換ライブラリ(たとえば『DXライブラリ』という日本人の作成した無料ライブラリがある)に、事実上の選択肢は限られてきます。
原理的には OpneGL など別の画像ライブラリでもレイヤー表現は可能かもしれませんが、せっかく DirectX というゲ-ム用の画像ライブラリがあるのだから、 Windowsゲーム制作では DirectX を用いるほうが合理的でしょう。
なお、DirectXは、仕様がコロコロと変わっています。最新の商業ゲームのような作品をより高速で処理するため、それに最適化させたDirectXの開発方針がwindows開発元のマイクロソフトでは採用されています。
このため、dirextXのコードの互換性は、DXライブラリよりもやや劣る可能性があります。 なので、ちょっとした入門的なゲームプログラムの練習では、DirectXよりもDXライブラリを使うほうが安全かもしれません。
なお、実はDXライブラリでPNG画像を使用した場合、DXライブラリの説明書の指示にある下記の支持のように、libpngおよびzlibのライセンス表記が必要です。
このように、自作の説明書にも、ライセンスの項目に
のような表記で、libpngおよびzlibを使用したということを書かなければなりません。
さて、ゲーム以外の話題になりますが、実はよく鉄道駅やバス交通機関など公共交通機関にある液晶モニター(デジタルサイネージ)に表示されている動画は、Windowsで作成・表示されている動画だったりします。日本だけでなく世界各地で、そのような傾向です。なので、ときどきWindowsアップデートなどで画面が動画からWindowsメイン画面に切り替わるシーンがみられる場合があります(時々ネット上で、その交通機関の利用客などからSNSなどでそういう画面が報告されたりします)。おそらくWindowsの全画面モードにて、DirextXを用いて動画表示をしていると思われます。DirectXには、こういったゲーム以外の用途もありますので、操作の際など御参考に。
RPGのマップレイヤー

DXライブラリはvisual stuio プロジェクト作成時のセットアップに手間が掛かります。
RPGのマップレイヤー

なので、セットアップしたら、プログラミングをする前にまず、たとえばフォルダ名「DXセットアップ直後」とでも名づけたフォルダでも作って、 そこにセットアップ直後の作成したプロジェクト一式を保管しておくと良いと思います。
RPGのマップレイヤー

さて、 DXライブラリはプログラミング開始直後は、白紙です。 つまり、あえてコード例を書けば、初期状態ではコードは下記のような空白の画面です。
RPGのマップレイヤー

(※空白なのは仕様です。)
RPGのマップレイヤー

なので、コードを書き足していくのです。
RPGのマップレイヤー

まず、DXライブラリ公式サイトには、下記のようなコードがあります。
RPGのマップレイヤー

しかし、これだけだと、起動して点をひとつ打って終了するだけなので、ゲームになりません。また、点が見えづらいので、点を1pxずつズラして幾つも追加するなどして確認することになるでしょう。
RPGのマップレイヤー

しかも上記コードだけでは、ループもしません。DXライブラリはそういう仕様なのです。
RPGのマップレイヤー

ループさせるには、後述のコードのようにwhile文を1つだけ加えます。(while文を加えてもフリーズしません。そういう仕様です。つまり、素のwindows API のようなイベントオリブン型のパラダイムとはDXライブラリは異なります。)
RPGのマップレイヤー

ともかく公式サイトのコード例だけではループもせずにゲームにならないので、ともかく、参考サイト新・C言語 ~ゲームプログラミングの館~ DXライブラリ (『1.7章 裏画面処理をして画像を動かす』) のコードのように変えます。
RPGのマップレイヤー

画像ファイル名(「画像/キャラクタ01.png」)などは参考先サイトでの一例にすぎませんので、私たちが実際に作るゲームではファイル名は変わります。
RPGのマップレイヤー

で、実際の各自のゲームではおおむね、下記のような骨格
RPGのマップレイヤー

のような構成になるでしょう。
RPGのマップレイヤー

上記コードが、DXライブラリでゲームプログラミングする場合の基本例になるでしょう。
RPGのマップレイヤー

上記コードで用意されている関数は、DXライブラリまたはwindows APIが用意している関数ですので、
RPGのマップレイヤー

誰がコード記述しても、このようなプログラミングになるのが普通でしょう。
RPGのマップレイヤー

さて、もしプログラミング中に誤って{ や} を消したり追加してしまったりして、 元のブロック構造が不明になってしまった場合には、上記の基本例に戻ればいいだけです。
RPGのマップレイヤー

なお、参考サイトの別ページにキー入力のコード例
RPGのマップレイヤー

というコードがありますが、これはあくまで参考先サイトの方のゲーム用でのキー処理コードですので、 別にこれが無くてもキー入力の処理は可能です。
RPGのマップレイヤー

実際、DXライブラリに用意されているキー読み取り関数 CheckHitKey(KEY_INPUT_キー名) </cpde>を使用し、たとえばzボタンを読み取るなら、
RPGのマップレイヤー

if文などの条件式で CheckHitKey(KEY_INPUT_Z) == 1</cpde> を記述すればキー処理が可能です。
RPGのマップレイヤー

もちろん、1秒間に60回ループが回っているので、そのままだとzボタンに対応するコマンドを60連発してしまうので、
RPGのマップレイヤー

何らかの対応は必要です。
RPGのマップレイヤー

実際のコード例のヒナガタは、DXライブラリ公式サイトのコード例と参考サイト『ゲームオウログラミングの館』などのコード例などを合わせて、さらに作成したいゲーム用に必要なヘッダなどをincludeしたりするので、たとえば下記のようになるかもしれない。
RPGのマップレイヤー

DXライブラリの画像読み込み命令 LoadGraph で読み込める画像の合計枚数には、制限個数があります。
RPGのマップレイヤー

ネット検索しても特に出典は見当たりませんが、しかし後述のように実際にプログラミングで LoadGraph の実行を繰り返しするプログラムを書けば簡単に制限個数の減少を確認できますので、疑うなら、ご確認ください。
RPGのマップレイヤー

このセクションの元の文を書いた編集者が実験でいちど試したところ、制限個数は3万数千個の程度でした。
RPGのマップレイヤー

後日、条件を少し変えて試したら、
RPGのマップレイヤー

とVisual Studio の出力欄(エディタ画面右下にある)に出ました。
RPGのマップレイヤー

なお、編集者のプロセス環境では、このときプロセスメモリは約 236MB でした。
RPGのマップレイヤー

画像のサイズは、キャラチップ用に作成した、横 32×縦 64 の画像です。
RPGのマップレイヤー

もしかしたらパソコンのスペックなどによって、制限個数は変わるかもしれません。
RPGのマップレイヤー

DXライブラリ開発者の意図は知りませんが、一般にプログラミングにおいてこのようなハンドル作成命令の制限個数の必要性は、メモリーを保護する役目もあります。
RPGのマップレイヤー

なぜなら、たとえば、もしバグにより、メインループ1周ごとに新規に画像ハンドルを作成するプログラムが組まれてしまった場合、
RPGのマップレイヤー

60FPSなら1秒間に60周するわけですから、60個ぶんの画像ハンドルのメモリが使用されてしまいます。
RPGのマップレイヤー

秒数が経つたびにどんどんと画像ハンドルが新規作成されてしまうので、しまいにはメモリが不足してしまいます。
RPGのマップレイヤー

画像に限らず、メモリの使用量がどんどんと上がっていくバグのことをメモリーリークといいます。
RPGのマップレイヤー

こういった事が分かってくると、DXライブラリはあまり大規模なゲームの開発には向かないことが分かってきます。
RPGのマップレイヤー

一応、画像ハンドルを破棄する命令を書けば可能ですが(関数 DeleteGraph で画像ハンドルを破棄できます)、管理が面倒ですし、破棄のタイミングを間違えればバグの原因にもなります。
RPGのマップレイヤー

上述のようなメモリーリーク対策のため、プログラミング時は原則、けっしてメイン while ループ内では LoadGraph 命令は使用しないのが基本スタイルになります。
RPGのマップレイヤー

つまり、アプリ起動時に一度だけ、それぞれの画像の LoadGraph 命令を読み込むことになります(そういう命令を記述する箇所があるので、そこに書く)。
RPGのマップレイヤー

の次のあたりが、アプリ起動時に1度しか実行されない箇所なので、そういう場所だけでメモリー確保の命令を使うことになります。
RPGのマップレイヤー

この技術はアプリ開発開始の時点では覚えていても、しかし開発の中盤以降になると忘れやすいので(そしてメモリーリークのバグを踏んで思い出す)、教訓にしておきましょう。
RPGのマップレイヤー

このバグを追試するのは意外と難しく、なぜかリークしているハンドル画像が1個だけだと、うまくリークしない場合があります。
RPGのマップレイヤー

なので、たとえば、下記のようにひとつのハンドルの画像を書き換えるなどする必要があります。
RPGのマップレイヤー

しかもこのバグの嫌な点として、アプリを終了するのにも時間が掛かります(おそらく、メモリを掃除するのに時間が掛かっている)。
RPGのマップレイヤー

なお、出力メッセージの「Graphハンドル」の文言から分かるように、どうやらwindowsプログラミングの「ハンドル」機能を用いてDXライブラリでは画像のロードを実装しているようです。
RPGのマップレイヤー

ともかく、なんらかの事情で、本来ならリークするはずのコードがリークしない場合があるので、そのためバグの発見が遅れることがあります。
RPGのマップレイヤー

なので、私たちはルール「メインwhileループ内では画像ロードしない」を徹底させることを原則にしましょう。
RPGのマップレイヤー

画面中、半透明部分が増えると、じつは処理速度が低下します。半透明処理というのは、やや描画に時間が掛かるのです。
RPGのマップレイヤー

Windwosだけでなくプレステ2も同様、半透明よりも完全透明のほうが処理が軽いです。専門用語で「1bit抜き」とか「パンチスルー」と言って、半透明の無い完全透明方式のほうが処理が軽いのです。
RPGのマップレイヤー

また、ボカシ処理は、もしリアルタイム3Dレンダリングで行っているなら、それはプレステでは半透明処理として扱われます。
RPGのマップレイヤー

RPGにかぎらず、このため古いゲームで半透明部分のあるゲームでも、半透明の画像の下側にある画像は静止画像だったりします(静止画像なら、描画を使いまわしで演算省略できるので、高速化しやすい)。
RPGのマップレイヤー

不透明の場合なら単に上書きすればいいだけですが、完全透明の部分のある画像の場合なら下地の画像を転写すればイイだけすが、
RPGのマップレイヤー

しかし半透明の場合だと上書き画像と下地画像の両方を読み取らないといけないので時間が掛かるのです。
RPGのマップレイヤー

だから昔のスーファミ時代のドラクエやファイナルファンタジーでの不透明処理の多さや、ツクール2000あたりが標準的な設定ではウィンドウなどを透過処理をしないのには、それなりに理由があるのです。(実は1990年代前半のPCエンジン作品やメガドライブ作品などの時点で、ゲーム中に半透明ウィンドウを用いている作品はあります(たとえばPCエンジン版のパトレイバー)。)
RPGのマップレイヤー

しかし、「半透明をさけるため」といって、ドットを1点ずつ打つ命令によって大きな半透明画像を作るのは、もっと処理速度が悪いので(CPUへのアクセス回数が多くなるので処理速度がかなり悪い)、「ドット1点ずつ」方式はやめるべきだというのが、ゲームにかぎらない画像プログラミングの常識です。
RPGのマップレイヤー

これはつまり、現代のパソコンのハードウェア基盤には、なんらかのICチップなどで、半透明などを効率的に良い速度で処理できるようなチップが基盤に組み込まれているととになります。そういうハードウェアによる画像描画の支援があるので、なるべくそのようなハードウェア支援を受けやすい命令を用いて描画するのが、画像プログラミングのコツです。
RPGのマップレイヤー

あるいは、もしそういう特別なチップが無いハードウェアの場合でも、OSメーカー企業がとても効率的な描画プログラムをシステム内に搭載していたりするので、あらかじめ容易されている半透明処理などの命令を使ったほうが、そういう効率的プログラムを活用できます。
RPGのマップレイヤー

もし自前で「ドット1点ずつ打つ」プログラムを作る方式だと、ハードウェア支援やOS支援の機能をあまり活用できないのです。よって、半透明の機能についての開発方針としては「処理速度のリスクを意識しながら、演出的にどうしても必要なら半透明の処理郡も使う」ということになるでしょうか。
RPGのマップレイヤー

こういうハードウェア的な事情の歴史的な変化があるので、半透明処理や3D処理などの現代的な描画に関しては、メガドライブやPCエンジンの時代の古い手法は、あいにく21世紀の現代ではやや通じないでしょう。現代的にアレンジして活用していくことになるでしょう。
RPGのマップレイヤー

なお、昔のゲームだと、不透明で隠れている部分は描画を省略するなどして、処理を高速化したりしています。なので、90年代ぐらいの古いゲームだと、そもそも半透明部分がなかったりとか、あるいは半透明部分のサイズが小さかったりするわけです。
RPGのマップレイヤー

昨今のゲームでは、パソコン/ゲーム機のハードウェア性能が上がったので、半透明部分の大きい画像などが動いたりしますが、ああいう事がノートパソコンでも気軽にできるようになったのは2010年くらいからです(ツクールVXやウディタの登場時期のあたり)。それ以前は、パソコンではノートパソコンでは、大きな半透明部分のある動画などは、処理が困難だったわけです(2001年ころなら、半透明&動画などの高度な映像処理あるゲームをプレイしたいなら、ゲーミングPCなどの高値の筐体PCを買う必要があったわけです)。
RPGのマップレイヤー

現在の最新のツクールやウディタの半透明&動画の画像描画ばかりに見慣れると、あたかも昔からそういう表現がノートパソコンやタブレットPCなどで気軽にできたかのように見えますが、しかし実はなかなか半透明の描画は、2001年ころの過去には困難だったわけです。
RPGのマップレイヤー

半導体の性能向上は2010年以降、頭打ちです。このため、あまりにも処理速度を今よりもさらに高く要求するUIは、実装に問題が生じます。
RPGのマップレイヤー

スマホゲームの流行について、
RPGのマップレイヤー

だから、スマホのおかげでゲームがまた日常に戻ってきたとも感じいて」と述べています。
RPGのマップレイヤー

宮本「たとえば「ファミコンの頃のほうがよかったよね」というゲームを今作っても遊んでくれる方はいるし、」 と続けています。
RPGのマップレイヤー

このページではマップチップのことを便宜上「背景」と言ったりもします。しかしキャラクターチップよりも前側に存在するマップチップもあり、たとえば木々の上部の葉のおいしげっている部分は、その生い茂り(おいしげり)の後ろ側にいるキャラを隠さなければなりません。
RPGのマップレイヤー

つまり、キャラと樹木が、下記マップのようにそれぞれ2マス使用している場合の、描画の問題です。()
RPGのマップレイヤー

キャラが木の後ろに立っているときは、下記のようにキャラも足は隠れて、頭だけ見えるわけです。
RPGのマップレイヤー

一方で、キャラクターが木々よりも前に立っている場合には、けっしてキャラクターは隠れてはいけません。つまり、下記のようにキャラの頭も足も両方とも表示しなければなりません。
RPGのマップレイヤー

このため、もしキャラが木よりも前に立っているときは、木々の下側の幹はキャラチップよりも後ろの層に配置し(便宜上「後景」と本ページでは呼びます)、一方で、木々の上側の葉の生い茂りは、キャラよりも前に配置(便宜的に「前景」とする)しなければならないのです。
RPGのマップレイヤー

樹木に限らず、たとえばアーチ上の構造物のアーチの下をくぐる場合なども、その構造物の柱とアーチとキャラとの柱前後関係を、適切に設定しなければならないわけです。面倒です。
RPGのマップレイヤー

これらの問題の解決策として、下記のような幾つかの方法があるでしょう。
RPGのマップレイヤー

一番ラクな方法は、キャラチップの縦方向の長さを制限した上で、キャラ位置と樹木位置とで場合わけのプログラムを書くことです。
RPGのマップレイヤー

キャラが樹木の手前にいるときに、キャラの頭が樹木の葉の生い茂る部分に届かない長さにすれば、何も悩むことはありません。
RPGのマップレイヤー

ただしこの場合、ドラクエ2以降のような隊列を組んでパーティが複数人表示される方式は、困難になります。ドラクエ1のようにキャラ1しか表示されないなら可能な方式です。また、マップ中の通行人ごとにプログラム判定するのは面倒なので、通行人は全員、立ち止まっていなければなりません。なので、この方式は(実装だけならラクですが)実用性は乏しいです。
RPGのマップレイヤー

y方向の一番上の行ごとに、マップ背景、キャラ&樹木を書いていって、その行が書き終わったら、一個下の次の行を書いていく方式です。
RPGのマップレイヤー

イメージ的にコードを書くと、だいたい下記コードのようなイメージです。(DrawGraphなどDXライブラリの命令などについては解説しません。)
RPGのマップレイヤー

本当は、さらにキャラクターチップの描画があるのですが、向き4方向ぶんの処理を書くためにコードが長くなるので、省略しました。
RPGのマップレイヤー

これは、「画像プログラミングでは、あとから描画されたものが、まえに描画してあったものを覆い隠す」という仕組みを利用する方法ですので、手前にいるキャラの頭が自然に後ろの樹木を隠したりできます。同様に、手前に樹木があれば、自然に後ろのキャラを隠せます。
RPGのマップレイヤー

なお、3Dグラフィックのzバッファ法はこの方式に近いです。とはいえ、2Dゲームなので「yバッファ」と言うのが正確かもしれませんが。
RPGのマップレイヤー

ただし、この方式の場合、y方向に移動するときの描画処理が、少し面倒です(あと、処理速度がやや低下する可能性もありますが説明を省略)。キャラが下に移動する場合には、描画の処理を変えないといけません。
RPGのマップレイヤー

なぜそうしないといけないかというと、もしキャラが下に移動する場合、先に移動先である1行下の地面を移動処理をしておかないと、キャラが描画先の地面で上書きされてうのでキャラ表示が消えてしまうからです。(一方、(移動前マス基準ではなく)もし移動先のマスを基準に描画タイミングを指定しても、今度は上方向に移動するときにキャラ画上書きされてしまいます。だから移動前マスを基準にしても、移動後マスを基準にしても、どちらにせよif文での場合によって上書きの上から描画するようにタイミングを1行ぶんだけズラしてコードを書かなければなければなりません。 )
RPGのマップレイヤー

だから、(マップ描画でfor文を使いますが)もしキャラの移動方向が下方向のときだけ、for文での1マス下の行の地面を書くタイミングでキャラを書かないといけないのです。
RPGのマップレイヤー

しかも、さらにややこしい事に、この方式のプログラミングでの注意事項としては、下方向のマス移動中だけはif文により描画タイミングを区別する必要がありますが、しかしマス移動前と移動後の下向き画像は区別しないままで右向き・上向き・左向きと一緒のタイミングで描画する必要があります。もし下移動中と下移動後の描画を同じタイミングで描画してしまうと、移動後にそのキャラ表示が消えてしまいます(なぜなら、そうすると現在の y段 の描画タイミング時に、下向きの画像だけ描画がなくなってしまっているので)。
RPGのマップレイヤー

だから、描画タイミングを区別するシーンは、下向きでさらに移動中のシーンだけです。それ以外の移動の前後のシーンは、たとえキャラ画像の向きが下向きであっても、描画タイミングは他の上向き・横向きのタイミングと一緒にしなければなりません。
RPGのマップレイヤー

ナナメ下移動とかの実装も大変そうですが、入門の範囲を超えるので、もう説明は省略します。 2022年の現時点の編集では、このページを書いてる人自体、斜め移動の原理をまだ理解できていません。一方、キャラが上に移動する場合、特に工夫しないでも、キャラが消えたりしません。
RPGのマップレイヤー

さて、この方式の短所として、もはや「マップチップを描き終えてから、キャラチップを描く」ということが出来なくなります。
RPGのマップレイヤー

「各マスを描くごとに、このマスにキャラがいるかどうかを判定して、キャラが居ればマップチップの描画後にキャラチップを描く」というシステムにせざるをえません。
RPGのマップレイヤー

一般的に2DのRPGゲームでは、画面中のマップチップのマス個数の数十個に比べて、同じ画面中のキャラの人数は敵味方を含めて数人程度と少ないので、このため処理速度的には少し非効率です。もし(2Dゲームでなく)3Dグラフィックならグラフィックボードのハード支援を活用できたりして処理を効率化できるかもしれませんが、しかし2D-RPGのマップチップ描画のプログラムでは、グラフィックボードは3D認識をしないので、ハード支援は受けられず、CPUで1個ずつ描画処理していくことになってしまいます。
RPGのマップレイヤー

初心者レベルでは不要な方式ですが、3Dポリゴン用のハードウェア支援を受けるための手段として、 いっそ3Dポリゴンによって2D的な画像を再現する方式もあります。
RPGのマップレイヤー

任天堂DSだかPSPだのの携帯ゲーム機などで、目的は企業秘密なので不明ですが、このような3Dポリゴンで2D-RPGを再現する方式のゲームがあり、 プレイヤー視点だと2Dゲームですが、実は内部プログラムでは3Dポリゴンやそのテクスチャなどとして実装しているというゲームもあります。
RPGのマップレイヤー

ただし、この方式では、キャラチップが実は斜め45度に奥側に傾いていたりなどのテクニックが必要になったりします(たしか任天堂のゲームでそういうのがあります)。
RPGのマップレイヤー

果たして初心者はそこまでする必要あるかは疑問です。3Dポリゴンを使う方式は、プロの企業の人たちに任せましょう。
RPGのマップレイヤー

知識として、「3Dポリゴンによって2D-RPGを実装する方法もある」とだけ知っておけば、初心者レベルの知識としては十分でしょう。 それよりもプログラミングを実際に経験していくのが良いでしょう。
RPGのマップレイヤー

上記のように2D的なデフォルメを3Dポリゴンで再現しようとすると、どこかの段階で、人間の直感から離れたプログラミングの発想が必要になってしまうでしょう。なので、初心者には敷居が高いでしょう。
RPGのマップレイヤー

同人ゲームなどでは、キャラチップのゲーム読み込み用素材を作るとき、 けっして、いちいちキャラ前向きの画像で1ファイル、横向きの画像でまた別の1ファイル、みたいなことはしません。
RPGのマップレイヤー

そうではなく、その同じキャラクターなどの前向き画像、横向き画像、後ろ向き画像などをまとめて、1枚の画像ファイルにして管理しているのが一般的です。
RPGのマップレイヤー

こういったキャラチップの各向きがひとまとめになった画像ファイルのことを「タイル」または「タイルセット」などと言います。
RPGのマップレイヤー

ややこしいことに、製作ツール側の事情なのか、キャラチップのキャラ画像の1体ずつは16×16で正方形なのに、
RPGのマップレイヤー

しかしチップタイルだとタイル内の画像の感覚が等方向的ではなく、タテ18×ヨコ20のように、やや長方形で並んでいる場合もあります。
RPGのマップレイヤー

なので、手本のゲームを調べる場合は、実際のゲーム場面をスクリーンショットするなどして確認しましょう。
RPGのマップレイヤー

ゲーム制作ツールでは、キャラチップ素材は16×16なのに、しかしプレイされるゲーム側では2倍に拡大して32×32で表示している場合もあります。
RPGのマップレイヤー

これを確かめるには、比較のために手元で32×32の新規キャラチップを作成して自作ゲームエンジンで表示してみましょう。
RPGのマップレイヤー

パソコン上でそのアプリのウィンドウの横に、ゲーム製作ツールの画面を表示してみましょう。
RPGのマップレイヤー

すると、マップチップの大きさがピッタリと一致します。
RPGのマップレイヤー

さらに、念のためドットエディタで確認してみると、たしかにゲーム製作ツールのゲーム側の画面が32×32だったりします。 製作ツールと自作エンジンとでスクリーンショットを撮影してドットエディタで確認してみましょう。
RPGのマップレイヤー

こういうことは後述のことは、サンプルゲームをいくらよく見ても気づきません。ドットエディタでキャラチップ素材などのサイズを実際に確認しましょう。
RPGのマップレイヤー

さらに、ゲーム表示時には、キャラチップの表示位置をマップチップの表示位置よりもy方向に4ドットずらすという方法もあります(数え方によっては2ドット)。
RPGのマップレイヤー

こうすると、あたかもキャラチップがマップチップ2マスぶんを使用しているように見えるので、プレイヤー視点ではリッチに見えます。
RPGのマップレイヤー

キャラチップで黒色に見えるドットでも、画像ツールのスポイトで色確認してみるとRGB値が (20,20,20) だったりする場合もあります。
RPGのマップレイヤー

さらにキャラチップの周囲の黒い輪郭線(ただし RGB値が (20,20,20) だったりする )まで含めると、 もはやチップサイズが 16×16ではなく18×18だったりする場合もあります。
RPGのマップレイヤー

その製作ツールがどうやって表示しているか走りません。
RPGのマップレイヤー

あるゲーム制作ツールをドットエディタで調べると、輪郭線の抜きではサイズ規格が16×16だが、
RPGのマップレイヤー

しかし輪郭線まで含めるとサイズ規格が18×18だったりと(ゲーム中で2倍表示されるので 36×36 で輪郭線こみで表示)、
RPGのマップレイヤー

つまり輪郭線の有無によってサイズ規格が違っています。
RPGのマップレイヤー

なおチップタイルの各ドットの色情報を見ると、キャラの輪郭線を RGB値が (20,20,20) で描いていたりする場合もありますので、背景色(RGB が 0,0,0 )と区別できます。
RPGのマップレイヤー

それらのゲーム製作ツールでどう輪郭線を表示しているのかは知りません。
RPGのマップレイヤー

(なお、一般にこの20,20,20を読み込まずとも、輪郭線を表示する方法はある。それは、まず輪郭線抜きのチップをもうあと4枚コピ-して色変換して20,20,20に塗りつぶすことでシルエット上の画像にしてから、そのシルエット画像をキャラの後ろに表示することで輪郭線っぽく見せるという技法もあるので。なお、この技法は、3Dゲームなどでも使われ、シルエットなんとか法と言われる(業界でも名前が細かくは定まってないっぽい。本wikiではシルエット法については『ゲームプログラミング/3Dグラフィック/手書きアニメ調の3D#黒コピー拡大背景の方法』で説明。)
RPGのマップレイヤー

なお、実際のコード例として、たとえばDXライブラリなら、読み込み画像(読み込みの時点では不透明だとする)を半透明化する描画は
RPGのマップレイヤー

のようなコードになります。
RPGのマップレイヤー

DXライブラリの組み込み関数である SetDrawBlendMode の第1引数の DX_BLENDMODE_ALPHA は予約語であり、これから透明モードを開始することを宣言しています。 第2引数の 128の部分はアルファ値です。不透明なら255であり、完全透明(見えなくなる)なら0です。
RPGのマップレイヤー

128だと、ちょうどぴったり半透明(0と255の中間の整数なので)です。
RPGのマップレイヤー

SetDrawBlendMode(DX_BLENDMODE_ALPHA, 128);だけだと、ソフト内で今後に描画する画像の全部が透明になってしまいますので、 透明モードを終了するために SetDrawBlendMode(DX_BLENDMODE_NOBLEND, 0); によって透明モードを終了します。
RPGのマップレイヤー

重要な点としては、半透明モードに限らず、負担のかかる特殊な描画モードを使い終えたら、すぐにその特殊な描画モードは終了して、通常の描画モードに戻るのがコツです。
RPGのマップレイヤー

なお、教育を兼ねてコード例を書きましたが、もうひとつの簡単な半透明の実装の方法として、あらかじめ画像製作ソフトなどで半透明のPNG画像を作成しておいて、それを読み込ませるという手法もあります。ただしこの場合、ゲーム中で不透明画像と半透明画像の両方を表示したい場合、画像を2枚(不透明画像を1枚、および半透明画像を1枚)を用意しなければならないので、用意する画像が増えます。
RPGのマップレイヤー

その他、微妙に処理速度などがそれぞれの方式で違う場合がありえますので、用途に応じて適切なほうの手法を使いましょう。
RPGのマップレイヤー

さて、DXライブラリで画像の読み込みは、
RPGのマップレイヤー

int ハンドル名 = LoadGraph("画像名.bmp");
RPGのマップレイヤー

で読み込めます。
RPGのマップレイヤー

たとえば
RPGのマップレイヤー

のようなコードになります。
RPGのマップレイヤー

int で宣言した変数(上記なら変数test)は実際に整数です。
RPGのマップレイヤー

なので、たとえば画像の読み込み結果は、整数配列などにも代入できます。
RPGのマップレイヤー

つまり
RPGのマップレイヤー

のようなコードも可能です。(ただし、変数宣言の以外の演算を伴うので、Visual C++なら WinMain 以降で定義する必要がある。)
RPGのマップレイヤー

RPGの場合、キュアラター画像やモンスター画像などを何種類も同種の画像を読み込むので、もし配列でコードを使いまわしできないのならば不便です。ですが上記のように配列の整数型に画像ハンドルを代入できるので安心しましょう。
RPGのマップレイヤー

技術的に上記の整数 int への画像ハンドル代入について考察するなら、整数型変数のメモリに大きな画像データそのものを代入するのは難しいので、 おそらく画像のアドレス変数などをポインタ的に記録していると思われます。
RPGのマップレイヤー

動作がポインタ的に振舞うので、てっきり「配列にできないかも?」と心配しがちですが、しかし平気で配列にできます。安心しましょう。
RPGのマップレイヤー

そもそもDXライブラリに限らず、C言語の通常の使用法でも、 ポインタ値やアドレス値を、単なる整数型変数に代入することは実は可能です。
RPGのマップレイヤー

せっかくなので、ポインタを復習的に理解しておきましょう。
RPGのマップレイヤー

下記コードの前半部分は、wikibooksのC言語の教科書にあった内容です。 後半が、このゲームプログラミングの節独自の検証内容です。
RPGのマップレイヤー

これを実行すると(windows上でgccで実験)、警告文は出ますがコンパイル可能です。
RPGのマップレイヤー

そして実行すると、表示結果として
RPGのマップレイヤー

結果をよく見ると、単なる整数変数 b は、ポインタ変数pと同じです。また、変数cでは、もとの数値を復元できています。
RPGのマップレイヤー

配列については説明の簡略化のため抜粋しましたが、上記コードのように単なる整数配列にもポインタ関連の内容を代入可能ですし、配列からもとの数も復元できています。
RPGのマップレイヤー

このように、ポインタ変数の値を整数に代入することができますので、同様に整数の配列にもポインタの結果を代入することが可能です。
RPGのマップレイヤー

下記コードを見てください。変数bは宣言時には全くポインタもアドレスも代入していません。ですが最終的に、変数bを仲介して得られた変数cを用いて、もとの変数iの数値を復元できています。
RPGのマップレイヤー

上記のように、ポインタ型でない整数を仲介しても、読み込んだアドレス元の変数をすること可能です。
RPGのマップレイヤー

配列変数でも同様にもとの変数を復元する処理が可能です。
RPGのマップレイヤー

下記の問題は、DXライブラリでは無関係です。なので初心者は、なるべくDXライブラリで開発するのが無難です。
RPGのマップレイヤー

DXライブラリでの開発には不要な知識ですが、将来的にもしWindowsAPIでゲーム制作する人が居たときの参考のため、ここに情報を残しておきます。
RPGのマップレイヤー

半透明レイヤー合成に限らず、Windowsではプログラマーが画面クリアの命令を書いてなくても、OSがなんらかの理由で強制的にいったん画面クリアする場合があります。
RPGのマップレイヤー

典型的なのが、アプリをウィンドウ右上の最小化ボタンを押してタスクバーに格納すると、いったん画面が消去されてから、WM_PAINTを実行するという再描画が始まります。
RPGのマップレイヤー

モードの管理方式だと、この際、前のモードの描画はすべて消えてしまいます。
RPGのマップレイヤー

たとえば、(ドラクエ1みたいに)戦闘モード中にマップ画面を背景で表示しようと思って、マップモードの画像を残していても、しかしWindowsの場合、なんらかの理由でWindowsが強制的に画面クリアすることがあり、そのあとにはマップモード時に描画された画像は、このままでは消去されてしまい再描画されません。
RPGのマップレイヤー

こういったWindowsによる強制消去の対策としては、戦闘画面モード側にもマップ背景の描画をコード記述するしか、方法はありません。(他の方法があるかどうかは、一般には知られていません。)
RPGのマップレイヤー

結局、それぞれのモードで、それぞれ別個に、同じ背景画面の描画を指定することになります。
RPGのマップレイヤー

なお、関数などを使えば、背景などの描画はコードの使いまわしが出来ます。
RPGのマップレイヤー

たとえば、戦闘画面モードで、マップ画面描画の関数を呼び出せば、追加する必要のあるコードはその呼出し命令だけで済むという事です。
RPGのマップレイヤー

バグが発生しやすいので非推奨な方法ですが、もし異なる関数どうしで、裏画面(ダブルバッファ)用の画像を受け渡しする場合、下記のような方法で画像の受け渡しが一応は出来ます。しかし、他の画像関連の関数の描画時に原因不明のバグ画像が発生する事が多く、あまりオススメできないです。
RPGのマップレイヤー

参考前に、下記の方法を紹介しておきます。
RPGのマップレイヤー

たとえば、戦闘画面の背景にマップ画面を書く場合、コード例として下記
RPGのマップレイヤー

のようにすれば、一応は、異なる関数どうしで裏画面のデバイスコンテキストの受け渡しが出来ます。
RPGのマップレイヤー

つまり、呼び出しの戦闘関数側で、引数をhdcだけでなく、裏画面用の hbackDC も引数として含めて、
RPGのマップレイヤー

のような2引数以上の関数にして呼び出す必要があります。
RPGのマップレイヤー

また、このため、呼び出されるマップ側にも、引数として
RPGのマップレイヤー

のように引数を増やす必要があります。
RPGのマップレイヤー

このため、既存のマップ描画関数では引数がhdcの一つだけなので、そのままでは使いまわし出来ないです。よって、戦闘画面の背景用に書き換える必要があるので、なので既存の map1_Draw(HDC hdc) をコピーペーストして新しく map2_Draw(HDC hdc,HDC hbackDC) 関数を作らなければなりません。
RPGのマップレイヤー

このため、この方式では、あまりコード行数は減らないし、むしろ行数が増えます。
RPGのマップレイヤー

しかも、せっかく作ったコードなのに、実際にテストプレイしてみると、街頭の戦闘シーンだけは画像は正常に表示されるのですが、上述のコード例の場合、なぜか戦闘後のマップ移動画面がバグりました。
RPGのマップレイヤー

このwikiを書いた著者の戦闘画面の描画プログラムが単に欠陥なのか、それともwindowsの仕様上の問題があるのかは当wiki著者には分かりません。
RPGのマップレイヤー

ですが、どちらにしろ、上記の方式では、たとえ異なる関数どうしの間で裏画面の受け渡しが出来たとしても、デバッグやメンテナンスがかなり難しくなると予想されるので、なるべくこの方式は避けるほうが安全でしょう。
RPGのマップレイヤー

ネットでさらっと検索して調べてみても、この問題の対処法は全然見当たりません。ネット上にいるゲームプログラマー志望の皆さん、どうもここまで実験してないようです。
RPGのマップレイヤー

なので、前の節で述べたように、マップ側で本画面に転写するなど、裏画面を作成した関数の側で、本画面にも転写してしまうのが、バグが発生しないで安全です。
RPGのマップレイヤー

上述のような問題が発生する背景として、windowsでは下記のような、機能不足の仕様があるという理由があります。
RPGのマップレイヤー

グローバル変数などで画像を保有する方法は、試みても、うまくいかないです。(標準c言語の文法どおりの仕様には、Windows APIの仕様は従っていないのです。)
RPGのマップレイヤー

たとえば、あらかじめグローバル変数として(コード冒頭の部分の)グローバル領域で
RPGのマップレイヤー

など、裏画面用の画面変数を宣言しておいて、ためしにローカル関数サイドでグローバル変数のhbitmapやHDCなどに代入コピーしようとしてイコール記号「=」でプログラム中で代入コピーしても、(コンパイルはできるのですが、)なぜかモード変更時にはコピー内容を残せない仕様になっています。(おそらく、メモリのオーバーブローを防ぐための仕様として、Winodowsが自動で勝手に、代入命令の意味をメモリ内容の複製ではなく(コピーではなく)、参照リンクにしていると思われます。)
RPGのマップレイヤー

(なお、HDCは型名である。Windowsではデバイスコンテキストの型名がこう決まっている。 hbackDCは単なる変数名なので、自由に命名できるし、別の変数名でも構わない。)
RPGのマップレイヤー

どうやらWindowsAPIにおけるhbitmapやHDCといった型のグローバル変数宣言は、実態は単に、各ローカル関数ごとに宣言をする手間を減らすために、一括でグローバル領域で宣言できるという仕様でしかないようです。
RPGのマップレイヤー

もし、上述の説明とは別のうまい方法があったとしても、つまり複数のローカル関数どうしでhbitmapやHDCの内容を共有できる方法があったとしても、その方法はけっして、上述のような直感的な方法ではないので(上述のような直感的な(標準C言語のような)方法では、共有不可能です)、メンテナンス上の理由であまり用いないほうが安全でしょう。
RPGのマップレイヤー

このようなWindowsAPIの非直感的な仕様のため、どうしても背景を複数のモードで使いまわしたい場合にはWindowsの場合、やむを得ず、CPUに負担は掛かってしまうのですが、結局は前の節で説明したように、関数などを用いて各モードごとに同じ描画をする方法しか、IT業界ですら、この関数の方法しか世間的にはよく知られていません。
RPGのマップレイヤー

静的変数 static としてグローバル変数として、
RPGのマップレイヤー

とグローバル領域で宣言しても、同様の結果です(共有できない)。なお、これとは別件で、ローカル関数側で static HDC と宣言しても、何も表示されなくなりますので、ローカルで static 宣言しても役立ちません。
RPGのマップレイヤー

画像の描画の際、グローバル変数でアドレス変数やポインタ変数を作成しても、通常変数の場合と同様に、異なるモード間では一行に画像を共有できないです。
RPGのマップレイヤー

たとえば、下記のようにポインタなどを使ったコードを書いてもコンパイルは出来るのですが、しかし画像がモード遷移時に消去され、複数のモード間では画像を共有できないです。
RPGのマップレイヤー

例えばグローバル変数としてグローバル領域で
RPGのマップレイヤー

と宣言してみて、
RPGのマップレイヤー

描画時に
RPGのマップレイヤー

などと宣言をしてみて、
RPGのマップレイヤー

BitBlt(hdc, 0, 0, 600, 400, *point_dc, 0, 0, SRCCOPY);
RPGのマップレイヤー

としても、単に普通に通常変数で描画した場合と同様のことが起きるだけで(つまり、宣言したモード内だけで描画が出来るだけ)、異なるモード間では何も画像は共有されません。
RPGのマップレイヤー

また、
RPGのマップレイヤー

で試しても、同様の結果です。
RPGのマップレイヤー

ツクールやウディタやその他の各種の日本産のゲーム制作ツールなどのゲームをプレイすると、実行ファイルかせいぜいあと1つのデータファイルしかなく、画像ファイルや音声ファイルなどのアイコンはゲームフォルダの中には見つかりません。
RPGのマップレイヤー

windowsの Visual Studio には、一応、実行ファイルに画像ファイルや音声ファイルなどの埋め込みをする機能がありますので、Visual Studio でゲーム制作する場合はそれを使えば済みます。
RPGのマップレイヤー

なので、この説明でこの章を終わりしてもいいのですが、しかしツクールやウディタが、C言語コンパイラの機能もないのに、どうやって何十枚や何百枚もある画像や、あるいは合計で何曲もある音声ファイルなどを埋め込んでいるのか、それはそれで読者は気になると思います。
RPGのマップレイヤー

なので、ツクールの方法かは分かりませんんが(ツクールの製作元企業の企業秘密なので)、画像などをファイルに埋め込む方法を調べてみて、まとめます。
RPGのマップレイヤー

調べた結果、下記のように、Visual Stduio 以外にも、幾つかの方法があるようです。
RPGのマップレイヤー

などの方式があるようです。
RPGのマップレイヤー

難易度的には、機械語を用いる方法が簡単なようです。しかし、そのような動作はマイクロソフトはそのような使い方を未保証にしていま。しかし、他のPEフォーマット方式や、独自フォーマットはとても難しいというとか、ほとんどOS開発に近いので、あまりオススメできないです。総合的に考えて、機械語が無難かと思います。
RPGのマップレイヤー

RPGのほかアクションゲームなどでも、無料のゲーム制作ツールを作って配布している人達は日本に数人ほどいますが、それらの無料ゲームエンジンはどれも、画像や音声などの埋め込み機能があります。
RPGのマップレイヤー

さすがに、そんなに多くの人達が、音声ファイルの独自フォーマットやら、PEフォーマットの仕様に精通しているとは思えませんので、おそらくは、ほとんどの無料ゲームエンジンの場合、画像などリソースの埋め込みは、機械語の方式だと思います。
RPGのマップレイヤー

ただし、暗号化のつもりなので機械語化などをしても、それでも第三者によって復号されるツールなどは出回っています。
RPGのマップレイヤー

かといって、たとえば画像ファイルを、プレイヤー視点では画像ファイルだとばれないように、ファイル冒頭の機械語にあるファイル形式の情報を書き換えると(たとえばビットマップファイルには冒頭にファイルヘッダを示す文字列「BM」がある)、windowsの画像用API関数では処理できなくなってしまうでしょう(処理時にヘッダファイルを読み取る必要があるので)。また仮に、ヘッダファイルを偽装したまま読み取らせる事がもし出来たとしても今度は、最悪の場合、外部のセキュリティセフトによってウイルス判定されるかもしれません。なぜならファイル偽装は、コンピュータウイルスによくある手口だからです。
RPGのマップレイヤー

あるいは、もし使用の瞬間にだけ画像ファイルを機械語リソース集などから取り出してファイル出力などで作成して読み込み終わったら消す方式にしたりする方式にすると、今度は頻繁に画像を作成・消去をする事になるので、処理速度が低下して、あまり好ましくありません。特に、SSDフラッシュメモリの普及している現代、頻繁にファイルの作成・消去することはSSDを消耗するので製品寿命を損なってしまいます。
RPGのマップレイヤー

実際にハードディスクに書き込まずにメモリ上で仮想のファイルやフォルダを作る方法については、この版のwikibooks著者が知りません。また、そのようなメモリ上の仮想化は、仮に出来たとしても、膨大な画像ファイルや音声ファイルをメモリ上に常駐させる事になるので、だいぶメモリに負担になるだろうし、処理速度なども低下させるのだろうから、あまり好ましくないと思います。
RPGのマップレイヤー

もしかしたら、リソースファイル集の機械語の文字列をC言語プログラムで1文字ずつ、各コンテンツの最後まで読み取って、プログラム側で、各種のメディア読み取り用のAPI関数でエンコードする事で、むりやりに画像や音声などをメモリに読み込ませる事が出来るのかもしれません(未確認)。ですが、そのためには、読み取り元のデータベース集ファイル側に、どこからどこまでが1つの画像コンテンツ単位(または1つの音楽コンテンツ単位)だとかの目次的な情報を、冒頭あたりに記録しておく必要があります。そのためには、各ファイルのサイズ数(つまりバイト文字数)なども正確に目次部分で管理する必要がったりと面倒そうです。目次の仕様も、自身で策定しなければならないでしょう。
RPGのマップレイヤー

なお、偶然に目次の情報の機械語と、画像コンテンツ側の機械語が一致してしまうと、読み取りミスになってしまいますので、そういう現象の発生しないように、充分に長い機械語文字列を使って、目次の位置を表示したりなどの工夫が必要かと思われます。
RPGのマップレイヤー

なお、windowsには、「tempフォルダ」がありますが、これはべつにメモリ上の仮想(ハードディスク上にはない「仮想」)のフォルダではないはずです(メモリ上ファイルだとは、聞いた事が無いし、ネット検索しても出て来ません)。単に、ウィンドウズが一時的に自動作成したファイルであるので、ガッツリとハードディスクなどのストレージに書き込まれているはずです。(そもそも、なるべくメモリの負担を減らす必要があります。)
RPGのマップレイヤー

なお、「仮想メモリ」は、上記とは意味が異なります。仮想メモリとは、ハードディスクなどストレージ領域をメモリとして使用する機能です。このため、「仮想メモリ」を使うと、頻繁にハードディスクに書き込まれることになります。
RPGのマップレイヤー

「仮想ディスクドライブ」というメモリ上の開き領域をドライブ化する技術やソフトウェアが存在しますが、それをどうゲームに組み込めるのか、知りません。また、当然ですが、残りのメモリ容量が圧迫されます。なお、「仮想フォルダ」とは、単に「マイコンピュータ」や「ごみ箱」のような、システム内でデータの実在する場所とは別の階層位置に表示されるアイコンやそのリンクの機能のことであり、「仮想ディスクドライブ」とは意味が異なります。