ケイトホルマンとザックバートは、ゲームスタジオザックトロニクスの開発者です。 25歳のコンピューター向けのゲーム作成に関する複雑な技術記事がお好きなら、 SpaceChem 、 Infinifactory 、 TIS-100、およびSHENZHEN I / Oの パズルゲームをお勧めします 。

降りる

ギガバイトのRAMとフルカラーHDディスプレイを備えた最新のコンピューター用のゲームを作成することに慣れている2人のプログラマーは、ゲームをMS-DOSに移植できますか？私たちの誰もそのような古い機器の開発経験はありませんでしたが、人工的に制限されたシステムでの作業はZachtronicsゲームデザインの基礎であるため、試さなければなりませんでした！

このプロジェクトは、ZackがSHENZHEN I / Oゲーム（スタンドアロンゲームとしても販売）のソリティアミニゲームであるSHENZHEN SOLITAIREレイアウトを作成することから始まりました。 256色VGAディスプレイでソリティアがどのように見えるかを次に示します。

90年代初期のPC画面で見ることができるゲームのように見えます！これで、コードを作成するだけです。

開発環境

最初に、古代のDOSコンピューターで実行できるプログラムの書き方を理解する必要があります。ターゲット機器は、ZachコレクションのビンテージIBM互換PCです。

周波数20 MHzのIntel 80386SXプロセッサ
5 MBのRAM
VGAカード
3.5インチドライブ
シリアルマウス
MS-DOSバージョン6.22

その時代のマシンのプログラミング言語の唯一の妥当なバージョンはCです。ゲーム全体をx86アセンブリ言語で書くつもりはありませんでした！作業ツールのさまざまなオプションについて考えた後、1992年にリリースされたBorland C ++ 3.1に決めました。 DOSBoxで起動Borland C ++は、ターゲットマシンの便利で正確なエミュレーションを提供しました。

グラフィックス

VGAグラフィックスを搭載したコンピューターには、いくつかのレンダリングモードがありました。人気のあるシンプルなオプションは、モード13hでした。解像度320 x 200ピクセル、256色。より難しいオプションは、非公式のMode Xモードで、解像度は320 x 240ピクセルでした。インターネットのモード13hには多くのマニュアルがあり、そのプログラミングは非常に簡単です。320x200ピクセルは64,000バイトの配列で表され、各バイトは1ピクセルを表します。モードXはより不思議で使いにくいですが、明らかな利点があります。320x 240の解像度、正方形ピクセルの数少ないVGA解像度の1つです。また、パレットから選択された256色でのレンダリングもサポートしています。ほとんどの色は、どのVGAモードでも使用できます。私たちはグラフィックスをより良くし、仕事を複雑にしたかったのです。なぜなら、それが大好きだからです。したがって、モードXを使用することにしました。

そのため、多くのピクセルと色のグラフィックモードがあります（当時のコンピューター用）。何を描画しますか？最も重要な要素は次のとおりです。

フルスクリーンの背景（デスクトップの壁紙、グリーンカードテーブル）
カード（地図アイコンと3色のカード上の数字を含む）
テキスト（ボタンとラベル用）

オリジナルのSHENZHEN SOLITAIREバージョンからこれらすべてのリソースの高解像度フルカラーバージョンが既にありましたが、はるかに低い解像度に変換し、合計で256色以下で使用する必要があります。いくつかのトリックによって、このような変換は不可能でした。Photoshopでのマップ、シンボル、インターフェイス要素の手動再描画、解像度のスケーリング、および背景のカラーパレットを使用して数時間作業するだけでした。

ここで、モードXの主な欠点が重要になります。320x 240ピクセルを表現するには、76 800バイトが必要です。 VGAカードには合計256キロバイトのビデオメモリがありますが、それぞれ64 kBの4つの「プレーン」に分割されています。一度にアクセスできるのはそのうちの1つだけです*。これは、64,000バイトしか必要としないモード13hに非常に適していますが、モードXでは、ビデオデータを複数のプレーンに分割する必要があります。

*すべてが少し複雑です。モード13hを含む一部のVGAモードでは、複数のプレーンに同時にアクセスできますが、このアプローチには欠点があります。モードXでは、プログラマは一度に1つのプレーンにしかアクセスできません。

この時点で、グラフィックコードは複雑に見え始めたため、VGAに関する最高の知識源であるMichael Abrashのグラフィックプログラミングブラックブックに目を向けました。 Black Bookが説明しているように、モードXはピクセルデータを4つのプレーンに分割します。各プレーンには、ピクセルの4分の1が交互のパターンで格納されます。プレーン0では、ピクセル0、4、8、12などが格納されます。プレーン1には、ピクセル1、5、9、13などが格納されます。

これはゲームプログラミングの古典的な状況です。作成する必要がある出力がわかっているため、入力データ（この場合は画像）の構造化方法の選択は、レンダリングコードの複雑さと速度に大きな影響を与えます。幸いなことに、Abrashの本には、モードXでの効率的なレンダリングのための便利なヒントがたくさんあります。画面全体が4つのプレーンに分割されているため、プレーン間の切り替えは比較的遅く、最も便利です（そして高速です！）オプション-各画像を4つのデータブロックに分割し、各プレーンのデータ部分が1つの隣接するフラグメントに含まれるようにします。これにより、コードは信じられないほどシンプルで、可能な限り高速になります。以下は、フルスクリーン（320 x 240）画像をVGAメモリにレンダリングするコードです。

//  :     VGA void far *vgaMemory = MAKE_FAR_POINTER(0xA000, 0x0000); short bytesPerPlane = (320 / 4) * 240; for (plane = 0; plane < 4; plane++) { SetCurrentVgaPlane(plane); _fmemcpy(vgaMemory, imageData, bytesPerPlane); imageData += bytesPerPlane; }

このコードは、16ビットDOSプログラムを作成する際に対処しなければならない奇妙な点もいくつか示しています。 16ビットポインターを使用すると、64 KBのメモリのみに直接アクセスできます。（これらは「近くの」ポインターです。）ただし、ほとんどのDOSベースのコンピューターにはさらに多くのメモリがあり、VGAメモリに関連するアドレスは既に64 kBを占有しています。アセンブラでは、この問題はセグメントレジスタを使用して処理されます。 Cは通常、「ファーポインター」、つまり1メガバイトへのアクセスを許可する32ビットタイプのポインターを使用します。（32ビットプロセッサの登場により、セグメントレジスタを気にせずに4 GBのメモリにアクセスできるようになったため、人生はずっと楽になりました。）

幸いなことに、64 kBは非常に多く、ゲーム全体のほとんどがこのフレームワークに適合しています。長いポインタの使用が必要なコードは2つだけです。最初に述べたとおり、VGAメモリはアドレス0xA0000から64キロバイトの範囲全体にあります。 2番目のフラグメントは画像データです。すべてのグラフィックスを1ピクセルあたり1バイトで低解像度に変換すると、1つの大きなファイルに約250 KBの画像データが保存されます。これは64 kBを超えるため、長いポインターも必要でした。さらに、この部分は、動的メモリ割り当てを使用したコード内の唯一の部分でした。

メモリ管理

多くのCプログラムのエラーと複雑さの主な原因は、動的に割り当てられたメモリ管理です。深Shenzhenソリティアでは、すべてをシンプルにしました。追跡する必要があるカードの数を正確に知っていたため、事前にメモリを割り当てました。コードにエラーを引き起こす可能性のあるmalloc()

呼び出しはありません。また、忘れることのできるfree()

呼び出しはありません。（ゲームの残りの状態にも同じ戦略が適用されます。）ソリティアエンジンの状態は次のようになります。

 //  :     struct CardOrCell { byte Suit; byte Value; byte CellType; struct CardOrCell *Parent; struct CardOrCell *Child; }; CardOrCell Cards[NUM_CARDS]; CardOrCell FreeCells[NUM_FREE_CELLS]; CardOrCell FoundationCells[NUM_FOUNDATION_CELLS]; CardOrCell TableauCells[NUM_TABLEAU_CELLS]; CardOrCell FlowerCell; CardOrCell *DraggedCard;

前述したように、この戦略を使用できなかったのは画像データのみです。64kBをはるかに超えていたためです。したがって、すべての画像を1つの大きなファイルに保存し（上記で説明したように、画像データは4つのプレーンに分割されました）、ゲームをロードするときにロードバーを表示してロードしました。

 //  :      //        , //  ,        . FILE *f = fopen("SHENZHEN.IMG", "rb"); assert(f); long size = GetSizeOfFile(f); ImageData = farmalloc(size); assert(ImageData); long loaded = 0; byte huge *dest = ImageData; while (loaded < size) { long result = fread(dest, 1, 1024, f); assert(result != 0); loaded += result; dest += result; // (  ) } fclose(f);

プログラム全体で使用するため、画像データに割り当てられたメモリは決して解放されません。

ブートコードには面白い詳細があります。ブートプロセスのバーの上にあるブート画面に、ブートロゴを描画します。ただし、画像データを読み込む前に読み込み画面を描画します！この循環依存に対処するために、特別なルールをイメージデータパッケージプログラムに追加しました。まず、ブートロゴのイメージデータを配置します。ゲーム開始後、最初の1〜2秒で読み込まれ、残りの起動プロセス中に表示されます。

 //  :     bool logoDrawn = false; while (loaded < size) { ... //       : if (!logoDrawn && loaded > ImageOffsets[IMG_BOOT_BACKGROUND + 1]) { Blit(IMG_BOOT_BACKGROUND, 101, 100); logoDrawn = true; } }

画像の前処理

レンダリング時に画像データを見つけて使用するにはどうすればよいですか？ゲームで使用されるすべての画像は、最新のソフトウェアで作成されたPNGファイルに保存されました。これらのPNGは、特別なコンテンツのベーキングプログラムで処理されました。コンテンツキャスターは、PNGを16ビットDOSプログラムで簡単に処理できる形式に変換しました。この場合、3つのファイルが作成されました：パレットインデックスの形式ですべてのピクセルデータを含む大きなバイナリファイル、すべての画像に共通の256色パレットを含む小さなバイナリファイル、および画像に名前を付けてデータを検出できるメタデータを含むCヘッダーファイル。メタデータは次のようになります。

 //  :  ,   //     #define IMG_BUTTON 112 #define IMG_BUTTON_HOVER 113 #define IMG_CARD_FRONT 114 // ID  ... long ImageOffsets[] = { 0L, 4464L, 4504L, 4544L, ... }; short ImageWidths[] = { 122, 5, 5, 5, ... }; short ImageHeights[] = { 36, 5, 5, 5, ... }; byte huge *ImageData = /*      */

コンテンツキャスターによって処理される各PNGファイルに対して、ID（IMG_CARD_FRONTなど）を割り当て、データの幅、高さ、および場所を記録します。画像を描画するには、たとえばBlit（IMG_CARD_FRONT、x、y）などの描画関数を呼び出します。次に、レンダリング関数はImageInfo（IMG_CARD_FRONT、...）を呼び出して、画像データとメタデータを取得します。

 //  :     void ImageInfo(short imageID, short *w, short *h, byte huge **image) { assert(imageID >= 0 && imageID < IMAGE_COUNT); *w = ImageWidths[imageID]; *h = ImageHeights[imageID]; *image = ImageData + ImageOffsets[imageID]; }

低レベルの最適化：少しのアセンブラー

グラフィックスを使用した作業の実装を完了した後、ソリティアゲームプレイのロジックを迅速に完了し、非常に遅いものの、すべてが美しく見えました。いつものように、効果的に最適化する唯一の方法はコードのプロファイリングです。 Borland C ++には、25歳であることを考えると、非常に便利なプロファイラーであるTurbo Debuggerが含まれています。

私たちの場合、プロファイリングの結果は驚くことではありませんでした。このプログラムはほとんどすべての時間をレンダリング手順に費やし、画像データをVGAメモリにコピーしました。 20 MHzの周波数で毎秒数十万ピクセルを386にコピーするのは非常に困難なプロセスです！ Borlandコンパイラによって生成されたアセンブラコードを調べると、レンダリングプロシージャの内部サイクルを遅くする多くのオーバーヘッドがあることが明らかになりました。

Cを最大限に使用しようとしましたが、アセンブリ言語がレンダリングプロシージャの重要な内部サイクルを最適化しないとできないことは明らかでした。アセンブリ言語は、プロセッサが遅く、コンパイラの最適化がそれほど効率的ではなかった90年代のプログラミングゲームでよく使用されていました。したがって、組み込みアセンブラコードのレンダリング関数の内部部分のみを書き直しました。これは、ほとんどのゲームレンダリングプロセスで使用されるBlit（）関数内の組み込みアセンブラコードです。

 //  :     byte far *vgaPtr = /*   VGA */; byte far *imgPtr = /*     */; asm PUSHA asm PUSH DS asm LES DI, vgaPtr asm LDS SI, imgPtr asm MOV BX, h asm CLD each_row: asm MOV CX, lineWidth asm REP MOVSB //     ! asm ADD DI, dstSkip asm ADD SI, srcSkip asm DEC BX asm JNZ each_row asm POP DS asm POPA

このアセンブラコードの前には、描画する場所、画像データの読み取り元、描画された画像を表示領域に挿入する方法を計算するCコードがたくさんありますが、実行時間の大部分はREP MOVSBコマンドに費やされます。このコマンドはCのmemcpy（）に似ていますが、x86プロセッサでネイティブにサポートされており、386などの以前のx86プロセッサでメモリをコピーする最速の方法です。memcpy（）と同様（レジスター内）。その後、プロセッサーは必要な量のデータをループで自動的にコピーします。

MS-DOS用の深センソリティアは、組み込みのアセンブラー言語を3つのコードだけで使用し、これらはすべてこのコードに非常に似ています。これらの重要なレンダリング関数で組み込みアセンブラを使用すると、これらの関数の速度が5〜10倍になりました。ゲーム内で実行されるカスタマイズコードやその他のコードの多くの行にもかかわらず、ほとんどのCPU時間は単純にバイトのコピーに費やされました。

*実際、REP MOVSWまたはREP MOVSDは、1つではなく、一度に2または4バイトをコピーするため、さらに高速になります。ただし、Borland C ++のバージョンでは16ビットコマンドのみがサポートされていたため、MOVSDを使用できませんでした。 MOVSWを使用しようとしましたが、その正しい操作に問題がありました。 REP MOVSWがレンダリングプロセスを半分に加速したとしても、これは、高レベルのパフォーマンスの問題を解決するのに十分ではありません。

ダブルバッファリング

次に解決すべき問題はちらつきでした。

モードXモードでは、フルスクリーングラフィックスを記述するために75 kBのVGAメモリが必要です。しかし、256 KBのVGAメモリは、同時に3つの「スクリーン」を保存するのに十分でした。コードでは、これらをメンタル的にScreen 0、Screen 1、およびScreen 2と呼びました。これまでは、Screen 0のみを使用しました。ダブルバッファリングを実装するには、Screen 0および1を使用しました。 2つ目は「バックバッファー」として使用されました。これは、ゲームが新しい要素または変更された要素を描画する領域です。グラフィックの新しいフレームを表示する準備ができたら、メモリの表示された部分を即座に変更するVGA機能である「ページリフレクション」を実行します。

ダブルバッファリングはちらつきの問題を解決しましたが、ゲームはまだ遅すぎました。低レベルのレンダリングコードを編集するだけでは不十分です。いつものように、アブラッシュはこれを予見しました。グラフィックプログラミングブラックブックの主なメッセージは、適切なアルゴリズムの選択と、低レベルのアセンブラートリックよりもパフォーマンスを向上させるプログラムの高レベルの設計です。

高レベルの最適化：静的バックグラウンド

最初に、画面のほとんどがほとんど常に同じままで、フレームごとに変化しないことに気付きました。

通常、マウスカーソルは画面上を動き、いくつかのカードがドラッグされることがありますが、背景とほとんどのカードは完全に変更されません。これを利用するために、最後のフルスクリーンVGAスクリーン2メモリを「静的背景」として指定しました。ほとんど変更されていないすべてのインターフェイス要素（つまり、マウスカーソルを除くほとんどすべて）を画面2に描画し始めました。つまり、各フレームをレンダリングする手順は通常次のようになりました。

静的背景をバックバッファーにコピーします。
マウス（およびすべてのドラッグ可能なカード）をバックバッファーに描画します。
バックバッファーを表示します。

これにより、ほとんどのフレームで作業の固体部分を取り除くことができましたが、静的な背景全体をコピーすることは依然として多くの作業でした。さらに悪いことには、静的な背景が変更されたとき、たとえばマウスで地図を持ち上げたとき、最初に別のフレームごとの作業に加えて静的な背景を完全に再描画する必要がありました。これは通常、ゲームがスムーズに機能することを意味していましたが、カードまたはボタンをクリックすると、目立って許容できないブレーキがかかりました。

開発のこの段階では、主に2つのパフォーマンスコストがありました。静的バックグラウンドの再描画（時々）と静的バックグラウンドのバックバッファーへのコピー（各フレーム）です。背景を再描画するコストを削減する簡単な解決策を見つけました。カードの各スタックには画面上に独自の領域があり、通常、フレームごとに1つまたは2つのスタックだけを再描画する必要があります。つまり、静的な背景の10〜20％を再描画するだけで済み、それに比例して時間がかかりません。

高レベルの最適化：汚れた長方形

ゲームが許容可能なフレームレートで動作することを妨げた最後の問題は、静的な背景をコピーすることでした。これはすべてのフレームで発生しました。私たちのソリューションは、ハードウェアグラフィックスアクセラレーションが登場する前の時代からのもう1つの古典的な手法であり、汚れた長方形の追跡です。 Windows 95では、プログラムがフリーズすると、このような状況が頻繁に発生する「ダーティな四角形」を覚えています。プログラムがクラッシュしたとき、ユーザーは、空になるかグラフィックのゴミで覆われるまで、ハングしたプログラムのウィンドウ上に別のウィンドウをドラッグできました。ユーザーがウィンドウをドラッグして再描画している領域は「ダーティ」でした。ハングしたプログラムは、ユーザーがフォアグラウンドでウィンドウを削除するとすぐに再描画する必要があります。

ダーティな長方形を同様の方法で使用しました。プレーヤーがマウスを動かしたり、静的な背景の一部を変更すると、この領域をダーティな四角形のリストに追加します。次に、静的背景全体をバックバッファーにコピーする代わりに、ダーティな四角形のみをコピーします。コピーするピクセル数を減らすと、フレームのレンダリングにかかる時間が短くなり、フレームレートが向上します。

この改善により、ゲームはようやくテストマシンでスムーズに動作するようになりました。 VGAカードを搭載したほとんどのコンピューターは、386プロセッサーを搭載した20 MHzのブレーキマシンよりも優れた仕様であると判断したため、ゲームのパフォーマンスはゲームをリリースするのに十分高いと確信しました。

入る

グラフィックと比較して、ゲームの他のすべての側面は非常にシンプルでした。 IBM互換コンピューターでは、必要な基本サービスのほとんどは、割り込みベースのAPIを使用してBIOSとDOSによって提供されます。これらのサービスには、キーボードとマウスのデータの読み取り、ディスクの読み取りと書き込み、ファイルのオープン、メモリの割り当てが含まれます。深Shenzhenソリティアで使用した割り込みの一部を次に示します。

INT 16h：キーボードAPI
INT 21h：DOSシステムコール
INT 33h：マウスAPI

これらのAPIは、次のようなアセンブリコードから使用する必要があります。

 //  :   BIOS    //  INT 16h, 1h     . mov AL, 16h mov AH, 01h int 16h //      . jnz no_key_pressed //   … no_key_pressed: //   ...

マウスの状態の読み取りは、同様の方法で実行されます。INT33h、3hを呼び出して、マウスの現在の位置とボタンの状態を取得します。ハードウェアへの直接アクセス、または最新のOSのAPIを使用する場合と比較しても、これは非常に簡単です。

音

効果音はゲームの重要な部分ですが、非常に古いPCで音楽とサウンドを再生するのは難しい作業です。すべてのIBM互換PCで利用できる最も単純なオプションは、PCスピーカーです。このスピーカーは、マザーボード上の単純なタイマーチップによって制御されます。つまり、スピーカーは、一定の周波数で音を連続的に再生するように設定するのが非常に簡単です。一部のPCには特殊なサウンドカードもありますが、使用するのがはるかに難しく、常にシステムにあるとは限りません。

PCスピーカーの制限により、ゲームの特定の時点（ゲームの開始時、終了時、および勝利後）で短い「音楽」フラグメントのみを再生しました。 386プロセッサのPC時代では、正確な時間測定の機会はほとんどなく、他のことをしながらPCスピーカーから単純な音楽を再生することは困難です。したがって、再び最も単純なオプションを選択しました。音楽の断片は非常に短いため、ゲームを1〜2秒、つまり音楽効果の持続時間だけ停止します。このようなフラグメントを設定および再生するためのコードは非常に簡単です。

 void PlayStartupMusic(void) { sound(73); delay(220); sound(110); delay(220); sound(165); delay(220); sound(98); delay(220); sound(110); delay(220); sound(147); delay(440); nosound(); }

音楽の断片に加えて、ゲームがより物理的に感じられるように、カードを取り、配置するサウンド効果を追加したかったのです。また、タイマーベースの自動サウンドジェネレーターを一時的に無効にし、手動でオンとオフを切り替えて短い「クリック」を作成することにより、PCスピーカーを介して実装されました。

ゲームをリリースします！

深センソリティアのMS-DOSへの移植は、予想よりも簡単で複雑なことがわかりました。ターゲット機器（周波数20 MHzのシングルコアIntel 80386SX）と通常の機器（周波数3500 MHzの4コアIntel Core i7-4770K）のプロセッサーの処理能力の大きな違いにもかかわらず、最適化されていないゲームプレイロジックは非常に高速で動作し、パフォーマンスにはほとんど影響しませんでした。しかし、欠点は、画面にすべてのピクセルを描画するのにほぼ150ミリ秒かかると、すべてが高速に見えることです！その過程で、コンピューターのアーキテクチャーについて多くのことを学びました。コンピューターのアーキテクチャーは、開始者だけが理解できると考えることができます。有益で興味深いプロセスにもかかわらず、将来のZachtronicsゲームでセグメントレジスタを使用することはほとんどありません。私たちはあまりサディスティックではありません！

深センソリティアの移植版をMS-DOSでプレイし、2017年9月12日までこの記事を読みたい場合は、Kickstarterでプロジェクトを評価し、フロッピーのみのリリースの一部としてゲームのコピーを注文してください。完全なソースコードが含まれています！

深センソリティアをMS-DOSに移植した方法（および理由）

降りる