RAMは当時でも大きな問題でした。 PS1には2MBのRAMしかなく、ゲームに合わせてクレイジーなことをしなければなりませんでした。 10 MBを超える純粋なデータを含むレベルがあり、これらの10メガバイトは、プレーヤーの目に見える遅延なしに、30フレーム/秒のフレームレートで動的にロードおよびアンロードする必要がありました。
Andyは、クラッシュがレベルを通過したときにページを64Kメモリにロードおよびアンロードするはずの素晴らしいスワップシステムを作成したため、基本的に機能しました。 このシステムは、高レベルのメモリ管理からメモリの直接作業およびオペコードでのプログラミングまで、利用可能なツールの全範囲を含む実際の芸術作品でした。 Andyは、CD-ROM上のバイトの位置も制御する必要があったため、300KB / sの速度でさえ、PS1がクラッシュに到達するまでにすべてのレベルの詳細のデータをロードできました。
サウンド、アート、クリーチャーを管理するためのLispコードなど、ゲームのリソースを使用するパッカーを作成しました。 Andyが作成したスワップシステム用に64Kページにパックしました。 （ちなみに、固定サイズのページに任意のデータサイズのセットをパックするタスクはNP完全であり、多項式、つまり許容可能な時間で解決することはほとんど不可能です。 ナップザック問題。 ）
いくつかのレベルはほとんど適合せず、私のパッカーは、アルゴリズムのセット全体（ファーストフィット、ベストフィットなど）を使用して、シミュレーションアルゴリズムで使用される勾配降下プロセスと同様に、確率的検索を含む最適なパッケージオプションを取得しようとしましたアニーリング。 本質的に、私はさまざまなパッケージング戦略をたくさん持っていて、それらすべてを試し、最高の結果を使いました。
ランダムな方向の検索を使用することの問題は、まったく同じ結果が再び得られることを確信できないことでした。 Crash Bandicootのいくつかのレベルは、パッカーが幸運であり、彼がこのオプションを見つけたという理由だけで、最大ページ数（私が間違っていなければ21）に収まります。 また、これは、パッケージ化されたレベルを取得するとすぐに、バグのコードを変更でき、21ページに収まるパッケージを取得できないことを意味していました。 デザイナーが何かを変更したい場合、ページ数が増えたため、パッカーが再び機能するオプションを見つけるまで、ほぼランダムな他の場所で何かを変更する必要がありました。 朝の3時にイライラするデザイナーに説明してみてください:)
このレトロスペクティブの最高のエピソードと最悪の期間は、Cおよびアセンブラーでのカーネルコードのパッケージ化でした。 「ゴールドマスター」バージョンをリリースするのにたった2、3日しかありませんでした。ホリデーシーズンに間に合う最後のチャンスで、もう1年を失うことになります。 そして、Cコードを意味的に同一であるが構文的に異なる構造に再配置し、コンパイラーが200、125、50、そして8バイト少ないコードを発行するようにしました。 例えば、「for（i = 0; i <x; i ++）」に再配置し、whileループでこれを書き直して、繰り返しの前にどこかで既に使用された変数を使用してみましょう。 これはすべて、ポインターの最後の2ビットにデータを入れるなどの標準的なトリックを試した後に行われました（これは、R3000アドレスが4バイトで調整されたためにのみ機能しました）。
最終的に、クラッシュはPS1のメモリに収まり、4バイトも残っていました！ はい、2097152から4バイト。幸運を祈ります。