カートリッジベースのゲームはどのようにプログラムされましたか？[閉まっている]

私はSNES、N64、Atariのようなものを考えています...今日のDSでさえ、私は推測しています。

SNESゲームは通常4 MB以上のスペースを占有せず、N64ゲームは通常32〜64 MB相当のデータでした。

最近では、「hello world！」をほとんどコンパイルできません。1.21ギガバイトを生成するコンパイル結果のないプログラム!! データの。（冗談はさておき、今日のファイルは、当時のテクノロジーのいくつかと比較して、何トンものスペースを必要とします。）

それで...彼らはどうやってそれをしたのですか？

• 彼らはこれらのゲームを何でプログラムしましたか？ASM？ASMの全体は？！
• グラフィックはどのように作成されましたか？スプライトシート、場合によっては（N64など）3Dモデルを作成するために、どのテクノロジーが必要でしたか？
• これらのカートリッジに、これほど多くのレベル、キャラクター、クエスト、アイテムがどのように収まったのでしょうか？つまり、スーパーマリオワールドのSNESクロックは約1 MBであり、96の出口があります！Ocarina of Time、Banjo-Kazooie、DK64、およびその他のいくつかのゲームは、64 MB未満のサイズで、巨大な世界、膨大なコンテンツ、3Dモデルを備えていました。

私の質問が少し外れているように思える場合は申し訳ありませんが、たくさんの素晴らしいタイトルがこのような小さなストレージスペースに収まることに驚いています。

最も小さくて些細なファイルやゲームでさえ、少なくとも数MBを占有するため、GoldenEye 007のような巨大なレベルではほとんどデータをまったく取得できないと想像するのは驚くべきことです。

スペースを占有するのはアートとオーディオのリソースです。プログラミング言語の選択は、ハードウェアを最大限に活用することでした。

N64を例にとると、サードパーティゲームのほとんどは8、12、または16Mbでした。32メガバイトと64メガバイトのゲームは主に任天堂のものでした。カートに入れて出荷するのは非常に高く、他の人にとっては大きなものでした。それは小さいように思えますが、アートアセットと最終的なビジュアル出力もそうでした。ほとんどのN64ゲームは、今日の1280x760以上ではなく、320x240でレンダリングされることを覚えておく必要があります。出力解像度が非常に小さいため、テクスチャとスプライトは現在よりもはるかに小さくなりました。

N64の小さなテクスチャキャッシュのため、ほとんどのテクスチャは4/8ビットパレット（16/256色とも呼ばれます）の32x64ピクセルでした。余分な色のディテールは、テクスチャと頂点の色を混合することによってしばしば行われました。バンジョーゲームはこの良い例です。

今日、Unrealエンジンゲームの1つの岩には、複数の512x512x24bppまたは32bppさえあります。さらに、単一の拡散テクスチャの代わりに、法線マップ、鏡面マスク、反射マスク、反射キューブマップなどがあります。そのため、4Kbのテクスチャを使用していたオブジェクトは、数MBのデータでカバーされるようになりました。

古いゲームにもアートの再利用が大量にあります。スーパーマリオブラザーズの茂みは雲と同じスプライトであり、丘はキノコと同じです。異なるキャラクターは、同じアートリソースのカラーシフトバージョンです。このすべてが、カートにある各テクスチャまたはスプライトの使用量を増やしました。

オーディオは、現代のゲームのもう1つの大きな違いです。昔のほとんどすべてはシーケンスされたトラックで行われていました。現在、音楽トラック、音声、効果音の両方がさまざまな圧縮オーディオ形式で保存されています。圧縮されていないデータよりは確かに小さいですが、シーケンスされた同等のデータよりもかなり大きくなっています。

NES（およびほとんどのSNES）については、基本的な概要を以下に示します。私はNESゲームを作成しませんでしたが、NESエミュレーター（Graybox）を作成し、古いカートのかなりの回転工学を行いました。

プログラミング言語について：はい、すべてアセンブリでした。NESのプログラミングは、ハードウェア割り込み、DMAポート、バンク切り替えなどを直接操作することを意味しました。幸いなことに、6502（または2A03）のプログラミングは非常に簡単です[1]。

• レジスタはほとんどありません：主にA、X、Y、後者の2つはインデックス付けと反復にのみ使用可能です
• 命令セットは小さく、ほとんど簡単です
• 多くのメモリではありません。メインRAMは2KBで、オプションのバッテリバックアップ付き8KB拡張があります。その2KBのうち、256バイトはスタック用に予約されており、ページ0（最初の256バイト）は、いくつかの特別なアドレス指定モードのために最もよく使用されるポインターと値を格納する場所です。

これら3つのことを組み合わせることで、作業中に暗記するのに十分簡単な環境が実現します。はい、すべてのメモリを自分で管理しますが、本質的には、すべてが先に進む完全なマップを作成することを意味し、2Kについて心配するだけでよいのでそのマップはそれほど大きくありません。グラフ用紙。少し計画を立てて、変数と定数をRAMおよびROM（カートリッジ上）の場所に静的に割り当てる必要がありました。

カートリッジのデータがCPUのアドレス可能な制限を超えると、少し巧妙になります。これは64KBで、そのうちの下位32KBは石で設定され、あらゆる種類のハードウェアポートとRAMにマップされます。これは、バンク切り替えが機能する場所です。つまり、ROMのセクションを上位32KBアドレス空間（の一部）にマッピングします。

これはプログラマーが望む方法で使用できますが、使用例としては、3レベルのゲームがあり、各レベルのすべてのレベルデータ、メタデータ、コードがカートリッジの個別の8 KBのメモリ領域に詰め込まれている場合があります。レベルには、初期化、フレームごとの更新などのコールバックが含まれる場合があります。レベルの「ロード」とは、メモリの8KBチャンクを、たとえば0xC000にマッピングすることを意味します。次に、initルーチンが常に0xC000に、フレーム更新ルーチンが0xC200に、レベルデータが0xC800に開始するように指定できます。別のメモリチャンクに格納されたゲームのメインコードは、適切なチャンクにスワップし、適切なタイミングで絶対アドレス0xC000および0xC200にジャンプするだけで、レベルの変更を制御します。

WRTグラフィカルデータ：NESのタイルデータは2ビットの8x8ピクセルマップです。背景については、1/4解像度の2ビットレイヤーと組み合わされます。これらの4ビット値は、16エントリパレットにインデックス付けされ、53の効果的な一意の色が利用できると思います。スプライトは2ビットピクセルデータも使用し、各スプライトは独自の2ビットグループインデックスを指定して、再び4ビットpalインデックスを形成しました。画面上のBG画像は、タイルインデックス番号の32x30配列です。

基本的に、大量の繰り返しとインデックスへのインデックスを作成することで、データを非常に小さく保つことができます。レベルデータは多くの場合、タイルインデックスの垂直バーとして保存されていました。これらの垂直バーも再利用されるため、インデックスも作成され、カートリッジに一度だけ保存されました。単純なデータ圧縮技術も同様に機能します。これにより、マリオ1は32KBのデータ（余裕がある）と8KBのビットマップデータになりました。

開発環境に関しては、仕事のためにEEPROMバーナーに接続された証明可能な古代のコンピューターで作業した人々の写真を見ました。ツールを使用したデバッグは、実際にはSNESの時代の後まで可能性がありませんでした[2]。これが、多くの古いゲームに「明らかな」バグがある主な理由であり、Gamesharkのようなものが何をすることができるのかという理由です。プレイヤーの体力は常にmem-location Xにあるため、常に100になるように強制できます。

これらのことがおもしろい場合は、たとえばhttp://wiki.nesdev.com/w/index.php/Nesdev_Wikiをご覧になることをお勧めします 。NESのプログラミングコースもオンラインで見つけることができます。

この簡略化された概要により、80年代のゲーム開発に関する洞察が得られることを願っています。

[1]比較的話す。また、約85％のPowerPCアセンブリでGraybox自体を作成したため、偏見があります。[2] FF6の作成に関する記事をご覧ください：http ://www.edge-online.com/features/the-making-of-final-fantasy-vi/

あなたが尋ねている質問のほとんどすべてには、多くのサブトピックがあります。最適化はそれ自体が巨大な分野であり、探求すべきことがたくさんあります。

この種の最適化に興味がある場合、検討する可能性のあるものの1つはdemosceneです。デモシーンとそれに関連するアートカルチャーのいくつかは、可能な限りスペースをとらないコンピューター用の複雑なアートを作成しようとすることに不思議を抱いています。それらの多くは、彼らの「トリック」の一部またはすべてをどのように行ったかについての情報を持っています。

ゲームやジャンルに特有の「トリック」と「ハック」はありますが、常識の巧みな組み合わせがしばしばあります。多くの場合、少しの「運」が関係しており、チームは彼らが働いている制限を知っており（おそらくプロセス全体でそれらの制限で頭を常に突き合わせています）、利用可能なトレードオフを知っており、必要な取引の一部を喜んで行います-限界を満たすためのオフと犠牲。

チームがゲームをより小さなサイズにするのに役立つと私が考えることができるもののいくつかを以下に示します。

• できることの再利用：同じスプライトを再利用し、単一のスプライトイメージから簡単に作成できるバリエーション（反射、回転、パレットシフトなど）でスペースを節約できます。同じことは、コード、音楽、およびゲームの他のほぼすべてにも当てはまります。
• 圧縮できるもの：多くの圧縮スキームがあります。どのスキームを使用するかを知ることは、スペースを大幅に節約できます。ランレングスエンコーディングのような単純な圧縮スキームでさえ、驚くべき違いをもたらすことがあります。それだけでなく、個々のファイルタイプには、多くの場合品質のトレードオフを伴う圧縮方式（および厳密には圧縮ではない代替形式）があります。たとえば、wave / CDオーディオファイルは、わずかな情報の損失を伴いながらMP3ファイルに圧縮できます。また、MIDIやサンプラーベースのMODなどのファイル形式は、スペースを大幅に消費しない代替形式ですが、音楽をまったく異なる方法でエンコードし、音を良くするには異なるスキルが必要です。
• あなたが必要としないものを失う：あなたはそれを安くすることができますか？たとえば、より少ないピクセル（またはポリゴン）でキャラクターの「個性」を取得できますか？タイルの配置はデザイナーが正確に定義する必要がありますか、それともプログラムコードでランダムに生成できますか？
• コードの方が安くなることが多い：コードコンパイルに通常必要なスペースの量について冗談を言いましたが（この「プラットフォーム」が長年にわたって増加した理由と、どうしても必要なときに縮小する方法があります）、一般的に、アルゴリズム/手順/コード内で簡単に何かを行うことができれば、そのアプローチは調整が容易で、他の類似しているが異なるルック/フィーリングアセットに再利用することも容易になります。フラクタルは、特に見やすい例です。複雑なフラクタルのイメージを作成して、それを生成する数式と比較すると、多くのスペースを占有する可能性があります。さらに、数式には、似たような、しかし驚くほど異なる外観の画像を生成できるパラメータが含まれている場合があります。

とにかく、このような膨大な量の質問のセットについては、上記のトピックのいくつかがあなたがより多くを学ぶための良い出発点になることを願っています。

一つは、それがまだN64後の時代に残っているかどうかわからないが、SNESとN64はしばしば他の3Dオブジェクトのテクスチャを再利用し、しばしばかなりのスペースを節約し、背景が偽物であることが多いレンダリング済みのアートです。もう1つのトリックは、境界線の背景を作成することで、フォグを使用します。

サンフランシスコラッシュN64には常に霧がありましたが、サンフランシスコラッシュアーケードにはない密度を変更できるため、N64バージョンと比較してトラック1にゴールデンゲートブリッジが見えます。

また、ゲームはしばしばZelda Ocarina of Timeのような音楽を再利用しますが、Banjo Kazooie / DK64がテーマ内でテーマを持っている場合のようにより良い仕事をすることができたので、私はうんざりします。

ゼルダのオカリナは、ハイラルオーバーワールドを持ち、水中に行ったり、ショップテーマの楽器にコキリの森のショップやホーンにフルートやフィドルが使用される外側の領域を反映させたりする場合は、水中バージョンのテーマを使用できます。ハイラルキャッスルタウンショップのトランペットとゴロン村のドラムなど

PCの3Dモジュールはライブラリにコンパイルされており、プログラムを使用してすぐにアクセスできますが、任天堂のROMベースの場合はそうではありません。PCは、物事が常に想定される場所にとどまらず、コンピューターが起動しなくなるまで情報が上書きされる可能性のある乱雑な部屋に入るようなRAMです！

ゲームコンソールはすべてが割り当てられたスペースに格納されているROMであるため、ゲームをオンにするたびに、割り当てられたスペース内のファイルが検索され、そこに残ることが保証されます。