RockstarはいかにしてPS2をハックし『GTA: サンアンドレアス』を作り上げたのか

3つの広大な都市、それらを繋ぐ大自然が広がる架空の州全体、そしてロード画面は一切なし —— これらすべてが、わずか32MBのシステムRAMと、圧縮されていない4K写真1枚分よりも少ないビデオメモリ予算という極限の制約下にあるゲーム機で動作していました。それこそが、2004年にRockstar Northがリリースした『Grand Theft Auto: San Andreas』の開発における技術的ミッションであり、これにより少数の低レイヤプログラマーのチームは、PlayStation 2を単なる「ゲーム機」としてではなく、むしろ「扱いにくいストレージメディアが横に取り付けられたリアルタイム組み込みシステム」として扱わざるを得なくなったのです。

本稿は、ゲームのストーリーやサウンドトラックを振り返るレトロスペクティブではありません。そうではなく、そのシステム的な配管（プラミング）の解剖です。非同期ストリーミングパイプライン、ディスクの物理的なシーク遅延（レイテンシ）を隠蔽するLOD（Level of Detail）階層、コンパイラを完全にバイパスして手書きされたベクトル演算ユニット（Vector Unit）のマイクロコード、そしてわずか4MBのビデオメモリ枠を州全体に引き伸ばしたインデックスカラー（CLUT）を用いたメモリマジックについて解説します。Rockstarが使用した正確な内部定数の一部は一度も公開されておらず、過去20年間にわたりリバースエンジニアリングコミュニティによって大まかに推測されてきたに過ぎません。これに該当する箇所については、その旨を明記しています。しかし、そのアーキテクチャ自体は十分にドキュメント化されており、制約主導型エンジニアリング（constraint-driven engineering）の極めて優れた手本（マスタークラス）と言えます。

1. 2004年のハードウェア危機とパラドックス

PlayStation 2のEmotion Engine（エモーションエンジン）は、メインシステムメモリとして32MB of Direct RDRAMをアドレッシングしていました。コード、AIの状態、物理演算、オーディオバッファ、ストリーミングされるジオメトリ、そして処理中のテクスチャが、すべて同じメモリプールを奪い合っていたのです。一方、PS2のラスタライザであるGraphics Synthesizer（グラフィックス・シンセサイザ）は、GPUダイに直接搭載された、独立した4MB of 混載DRAM（eDRAM）を利用して動作していました。この4MBの中に、フレームバッファ、Zバッファ、そして描画のためにアクティブにバインドされたすべてのテクスチャを同時に保持しなければなりませんでした。現代のようなユニファイドメモリ・アーキテクチャや仮想テクスチャのページング（virtual texture paging）は存在せず、アセットがこれら2つのプールのいずれかに物理的に常駐していなければ、レンダラーにとってそれは存在しないも同然でした。

そのタイム予算は極めて過酷なものでした。目標とする30 FPSにおいて、エンジンに与えられた時間は：

$$T_{frame} = \frac{1}{30\ \text{fps}} \approx 33.3\ \text{ms}$$

シミュレーションの更新、アニメーションと物理演算の実行、描画呼び出し（draw calls）の発行、そしてストリーミングパイプラインへのデータ供給を、プレイヤーに一切の引っかかり（スタッター）を感じさせることなく行うために、これだけの時間しかありませんでした。ドライブの最良のシナリオであるシーケンシャル転送速度に、この1フレームあたりの処理可能時間を愚直に掛け合わせると、理論上の1フレームあたりのデータ上限値が導き出されます。

$$D_{frame} = R_{DVD} \times T_{frame} = 5.28\ \frac{\text{MB}}{\text{s}} \times 0.0333\ \text{s} \approx 176\ \text{KB}$$

実際のところ、この数値は非現実的なほど楽観的なものです。なぜなら、シークによるオーバーヘッド（seek overhead）が「ゼロ」であることを前提としているからです。プレイヤーが車で街中を駆け抜け、ディスクレイアウト上のセクター間をファイルの線形順序とは全く異なるパターンで飛び回るようになれば、そのような前提は瞬時に崩壊します。『サンアンドレアス』のエンジン開発チームが直面した設計上の課題は、要するに1つの問いに集約されていました。「わずか33ミリ秒の猶予しかないゲームループの中で、数百ミリ秒もの間停止（ストール）する可能性のあるストレージデバイスを、いかにして隠蔽するか？」

開発の目標は一切の妥協を許さないものでした。それは、州全体にわたるシームレスなストリーミングを実現し、世界の移動において一度もロード画面を挟まないこと —— このような地理的スケールにおいて、それまでのオープンワールド系家庭用ゲームが一度も成し遂げたことのない挑戦でした。

2. アセットストリーミング：サンアンドレアスのリアルタイム空間分割と予測読み込み

『サンアンドレアス』は、Criterion社が開発したマルチプラットフォーム向けレンダリングミドルウェアである「RenderWare」のライセンスを取得していましたが、使用したのは低レイヤのラスタライズ層である RenderWare Graphics のみでした。シーン管理、オーディオ、物理演算、AIといったCriterion社製の上位モジュールは一切使用せず、Rockstar Northは独自のシーングラフ、オクルージョン（遮蔽）システム、LOD（Level of Detail）システム、そしてストリーミングエンジンを完全に内製。これらをRenderWareの描画プリミティブの「内部」ではなく「上層」に構築しました。そのため、「RenderWareを大幅にカスタマイズした」という表現は、きわめて控えめな描写と言わざるを得ません。人々が『サンアンドレアス』において「RenderWareエンジン」と呼んでいるものの大部分は、RenderWareのラスタライザをバックエンド（描画の出口）として利用している、Rockstar自身が開発したコードだったのです。

ゲームの世界自体は、シーンセクター（scene sectors）と呼ばれる2Dグリッドの空間セルに分割されていました。各セルは、そのマップエリアに物理的に属する一連の3Dモデル、コリジョン（衝突判定）データ、テクスチャを保持しています。毎フレーム、エンジンはプレイヤーのワールド空間内の位置をセクターの境界線と比較し、新しいセクターに進入した時点で、そのセクターに必要なリソース群の「ストリーミング要求（streaming request）」を発行します。バックグラウンドでは「使用中のストリーミングメモリ」の実行カウンタが常に動作しており、ロードされたアセットに対してどれだけのRAM予算が割かれているかを追跡します。このカウンタが上限に近づくと、エンジンは現在メモリに常駐しているオブジェクトの中から「最も重要度の低いもの」から順に破棄（エビクション）し始めます。カメラから遠いもの、ビューフラスタム（視錐台）の外にあるもの、あるいは単純にプレイヤーから最も離れているオブジェクトを解放し、新しいセクターのデータが到着するための空きスペースを確保するのです。

ストリーミング要求を発行するためのトリガー半径は、プレイヤーを中心とした固定の円ではありません。プレイヤーがまだ読み込まれていないエリアに対して「どれだけの速度で接近しているか」を計算に入れる必要があります。徒歩で移動しているプレイヤーと、戦闘機「Hydra」をフルスロットルで操縦しているプレイヤーとでは、必要となる先行読み込み（ルックアヘッド）の条件が劇的に異なります。概念的には（Rockstarの正確なチューニング定数は公開されていないため、これは実コードそのものではなく、仕組みを説明するためのモデルとして捉えてください）、ストリーミング半径は速度に応じて以下のようにスケーリングされます。

$$R_{stream}(\vec{v}) = R_{base} + k \cdot \lVert \vec{v} \rVert$$

ここで、$R_{base}$ は歩行速度において必要最低限となるストリーミングバブルの半径、$\lVert \vec{v} \rVert$ はプレイヤーの現在の速度ベクトルの大きさ、そして $k$ は速度の上昇に伴ってバブルを広げるための調整定数です。さらに予測精度を高めたバリアントでは、現在の進行方向に沿って未来の位置を予測（プロジェクション）し、プレイヤーの現在座標ではなく、その予測位置を中心としてロード要求を発行します。

$$\vec{p}_{predicted} = \vec{p}_{current} + \vec{v} \cdot T_{lookahead}$$

これこそが、プレイヤーが新しい地域に「進入してから反応する（react）」エンジンと、それを「予測する（anticipate）」エンジンの決定的な違いです。数百ミリ秒単位で発生するDVDのシーク遅延に対し、1フレームの予算がわずか33.3ミリ秒であることを考えれば、事後反応的なシステムでは到底間に合いません。Hydraの最高速度で飛行する場合、ストリーミングシステムはプレイヤーが到着する数秒前にあらかじめ地形のフェッチを開始しなければ、プレイヤーの足元の世界が消失してしまうことになります。

図1：シーンセクターのグリッドと動的なストリーミングバブルの関係。低速時にはロード半径はほぼ円形ですが、高速時にはプレイヤーの進行方向に向かって引き伸ばされ、すでに後方に過ぎ去ったセクターよりも、これから進入しようとしている前方のセクターの読み込みを優先します。

3. ストレージ遅延の緩和：LOD階層と「ポップイン」の解決策

予測ストリーミングバブルを駆使しても、最終的には物理法則には抗えません。あまりに高速で飛行する戦闘機は、ディスクの読み込み速度を追い越してしまいます。これこそが、建物や橋、木々が本来表示されているべきタイミングから一歩遅れて、突然目の前にパッと現れるという、『サンアンドレアス』で悪名高い「ポップイン（pop-in）」現象の根本原因です。DVDドライブが、高解像度のジオメトリデータを時間内に供給しきれなかったために発生していました。

プレイヤーが高速移動中に、吊り橋や高精細な樹木の群れが目の前の虚空から突如出現するのを目の当たりにしたとき、それは単なるソフトウェアのバグ（グリッチ）を見ていたのではありません。2004年当時のハードウェアが持つ「物理的な限界」を目撃していたのです。PlayStation 2の筐体内部では、DVDドライブの物理的なレーザーヘッドが、回転するディスクの上を必死に往復（スイープ）していました。新しい地域の高解像度テクスチャや3Dメッシュ（mesh）を取得するために、レーザーヘッドは物理的に位置を調整する必要があり、正しいセクターに着地するまでに最大200ミリ秒もの時間を要したのです。レーザーがディスク上を移動している間も、ゲームループは1フレームあたり33.3ミリ秒のペースで時を刻み続けています。レーザーのシーク完了を待つためにゲーム全体をフリーズさせるのではなく、エンジンは処理を継続することを選択し、結果として空の空間か、あるいはカクカクとした粗いプレースホルダーを表示させていました。

この問題への対策は、原因そのものを排除することではありませんでした（5.28 MB/sの光学ドライブでは物理的に不可能でした）。むしろ、その移行（トランジション）を可能な限りシームレスにすることでした。その中核となるメカニズムが、永続的な低ポリゴン「プロキシ（代理）モデル」です。これは遠景用の粗いデータであり、ストリーミングの状態に関係なく、メモリ上に「常に常駐（always resident）」し続けます。建物やランドマークの高詳細バージョン（本データ）のロードが完了すると、エンジンはそれを低ポリのプロキシモデルと入れ替えます（スワップ）。画面上には常に何かしらが表示されているため（最終クオリティのアセットではないにせよ）、描画パイプラインは未描画の虚空（何もない空間）へと破滅的に陥る代わりに、低詳細なプレースホルダーへと優雅に縮退（グレイスフル・デグラデーション）していくのです。

非常に興味深いのは、このアプローチが1フレームのタイム予算においてエンジンに何をもたらすかという点です。低ポリのプロキシレイヤは、メモリから決して破棄されないため、DVDのシーク遅延に対する依存度が実質的に「ゼロ」になります。つまり、レンダラーが描き出す最悪のシナリオであっても、出力結果は常に「低品質だが正しい」状態に留まり、「アセットが欠落している」状態には決して陥りません。これにより、DVDのシーク遅延というハードウェア的な問題が、「データが正しいかどうか（正確性の問題）」から「サービスの品質（クオリティ・オブ・サービス）」という次元の問題へと再定義されることになります。これこそが、リアルタイムシステムが動作環境として保証すべき理想的なフォールトトレランス（障害許容）の形なのです。

4. アセンブラの魔術：Emotion Engineとベクトル演算ユニットの限界突破

PlayStation 2のCPU複合体である、ソニーと東芝が共同開発した「Emotion Engine（エモーションエンジン）」は、現代のハードウェアには類似するもののない、極めて非対称なアーキテクチャをしていました。その中心に鎮座するのは、約294.912 MHzで動作し、一般的なゲームロジックを実行する128ビットのMIPS R5900コアです。そして、このコアに直結されていたのが、VU0とVU1という2つのベクトル演算ユニット（Vector Units）でした。これらは、128ビットレジスタを中心に構築された小さなSIMDプロセッサであり、3D変換、クォータニオン演算、物理シミュレーションで正確に使われる「4要素の単精度浮動小数点ベクトル演算（4-wide float vector math）」に特化していました。

VU0はメインコアと密結合して動作し、実質的にCPUのインストラクション（命令）ストリームのコプロセッサ拡張として機能していました。そのため、車両のサスペンション挙動のモデリング、フレームごとの衝突判定、ラグドール風の物理演算など、遅延（レイテンシ）に敏感で、同一クロックサイクル内でゲームロジックと密接にやり取りする必要があるベクトル演算処理の割り当て先として最適でした。一方、VU1は全く異なる性質を持っています。独自のローカルな命令メモリとデータメモリを内蔵しており、メインCPUから1命令ずつ供給されるのを待つことなく、CPUと並行して独自のマイクロプログラムを*自律的（自律分散型）*に実行できました。さらに重要なのは、VU1がGraphics Synthesizerへと直通する、優先度の極めて高いプライベートバスである「Path 1（パス1）」を備えていた点です。これは XGKICK という単一の命令によって駆動し、変換、ライティング、クリッピング処理が完了したジオメトリのパケットを、メインCPUやシステムRAMのバスを一切経由（往復）することなく、GPUへ直接送り込むことができました。

結果として構築されたパイプラインは、大まかに以下のようになります。メインCPU（および支援役のVU0）がそのフレームのゲーム状態と物理演算を更新し、VU1がその結果を受け取って、視認性テストをパスしたジオメトリのマトリクス変換、ライティング、クリップ空間カリングを完全に独立してガリガリと処理します。そして、GPUへの描画準備が整った完成済みのプリミティブが、Path 1経由でGraphics Synthesizerへ向けて射出されます。このとき、CPUはすでに次の処理ブロックへと移行しています。これは「コンピュートシェーダー」という言葉が生まれる何年も前に、固定機能に近いハードウェアから絞り出された、ソフトウェア・パイプライン化された並行処理（software-pipelined parallelism）の極致でした。

図2：Emotion Engine内のデータフロー。VU0はゲームプレイに密結した物理演算のためにCPUの近くに配置され、VU1は半自律的に動作して、メインシステムRAMのバスに触れることなく、XGKICK 命令により専用のPath 1バスを介して完成したジオメトリをGSへストリーミングしています。

5. メモリの節約：CLUTテクスチャとプロシージャルなエンティティの再利用

1フレーム中にアクティブにバインドされるすべてのテクスチャを保持するためのeDRAMがわずか4MBしかない中で、『サンアンドレアス』は環境アートの圧倒的多数において、インデックスカラー（Color Look-Up Tables、すなわちCLUT）に強く依存していました。1ピクセルあたり完全な32ビットRGBAカラーを格納する代わりに、インデックスカラーテクスチャは1ピクセルあたり小さな整数値の「インデックス」のみを格納し、それとは別個に用意された極小のパレットテーブル（CLUT）が、各インデックスを実際の16ビットカラーへとマッピングします。PS2のGraphics Synthesizerは、ハードウェアレベルで2種類のインデックス深度をサポートしていました。4ビット（テクスチャあたり16色まで）と、8ビット（テクスチャあたり256色まで）です。

この削減効果は劇的であり、かつテクスチャの解像度に関係なく一定の比率で機能します（スケール非依存）。パレット自体のデータ容量は、ピクセルデータ本体のサイズに比べれば無視できるほど微々たるものだからです。

テクスチャサイズ	フォーマット	ピクセルデータ	パレット (CLUT)	総容量	32-bit RGBAと比較した削減率
128×128	32-bit RGBA	64 KB	—	64 KB	—
128×128	8-bit インデックス (256色)	16 KB	0.5 KB	16.5 KB	~74.2%
128×128	4-bit インデックス (16色)	8 KB	~0.03 KB	~8.03 KB	~87.4%
256×256	32-bit RGBA	256 KB	—	256 KB	—
256×256	8-bit インデックス (256色)	64 KB	0.5 KB	64.5 KB	~74.8%
256×256	4-bit インデックス (16色)	32 KB	~0.03 KB	~32.03 KB	~87.5%

※パレットのサイズは、1インデックスあたり16ビットのカラーエントリーを想定：8ビットCLUTの場合は256エントリー × 2バイト = 512バイト（0.5KB）、4ビットCLUTの場合は16エントリー × 2バイト = 32バイト（約0.03KB）です。

ピクセルデータ列の計算背景にあるのは、シンプルなビットパッキング（bit-packing）の数学です。1ピクセルあたり $b$ ビットの深度を持つ $W \times H$ ピクセルのテクスチャの場合、計算式は以下のようになります。

$$S_{pixels} = \frac{W \times H \times b}{8}\ \text{bytes}$$

1ピクセルあたり32ビットから4ビットへと引き下げることは、単なる線形的な節約ではありません。 $32 / 4 = 8$ であるため、生のピクセルストレージ容量が文字通り「8分の1（8x）」にまで削減されることを意味します。

CLUTインデックス方式には、生のデータ容量削減以外にも、目立たないながらも極めて強力なメリットがもう1つありました。インデックスカラーテクスチャにおける各ピクセルは単なるパレットへの「ポインタ」にすぎないため、（はるかに容量の大きい）ピクセルデータ自体には1バイトも手を加えることなく、わずか数十から数百バイトのパレットテーブルのみを書き換えるだけで、テクスチャの「見た目」を劇的に変化させることができるのです。パレットのエントリーを入れ替えたり、回転させたり、フェードさせたりすれば、そのパレットを参照しているすべてのピクセルが一瞬で、かつ均一に更新されます。8ビットハードウェアの時代からインデックスカラーグラフィックスで確立されていたこの「パレットシフト（palette shifting）」技術は、VRAMコストをほぼゼロに抑えながらライティングの段階的変化（カラーグレーディング）を表現するための、まさに決定打となるハックでした。『サンアンドレアス』における昼夜のサイクルに伴い、街の景観のテクスチャを日中の強烈な太陽光から夕暮れ時の琥珀色のトーンへと変化させる処理も、この技術によって家庭用ゲーム機での実用レベルに落とし込まれました。毎フレーム高解像度テクスチャデータを丸ごと再アップロードしたりブレンド処理したりするのに比べ、ごくわずかなパレットの数バイトを転送し直す方が、言うまでもなく桁違いに処理コストが低いためです。

図3：CLUTインデックスがピクセルデータの格納とカラーデータの格納をいかに切り離しているかを示す図。小さなパレット帯を書き換えるだけで、それを参照しているすべてのピクセルの色が即座に変更される。このメカニズムにより、VRAM負荷が極めて低いライティングやパレットシフト効果が実現しました。

CPU側のRAM予算におけるメモリ節約も、「再生可能なものは保持しない（再生成する）」という全く同じ哲学に基づいて設計されていました。『サンアンドレアス』における歩行者や走行車両の集団は、永続するアクターの固定データとして保持されていたわけではありません。それらはプレイヤーが世界を移動するにつれて動的にスポーン（生成）およびデスポーン（消去）される、プロシージャル（手続き型）に管理されたメモリプールでした。さらに、どの地区にどの車種が出現しやすいか（例えばガントン地区にはローライダー仕様の車が集まり、ラスベンチュラス周辺にはスポーツカーが集中するなど）を偏らせるための、確率的なゾーンウェイトテーブルによって生成が制御されていました。スポーン処理はビューフラスタム（視錐台）によってフィルタリングされ、新しいエンティティはロードされたエリアのどこにでも現れるのではなく、カメラの画角の「ちょうど外側」に実体化するよう制限されていました。デスポーン処理も同様に非常にアグレッシブであり、フラスタムの外に出てプレイヤーから十分に離れたものは、RAM予算を圧迫するデッドウェイト（無駄なデータ）となる前に、即座にアクティブなヒープメモリから消去されました。システム全体が、空間的および統計的なルールを重ね合わせた「固定キャパシティのオブジェクトプール（fixed-capacity object pool）」のように振る舞っていたのです。これは、限られた32MBという同一のメインメモリ枠の中で、シミュレーションされた市民のデータを、常にストリーミングされ続けるジオメトリ、テクスチャ、およびオーディオと競合させながらやりくりするために、まさに必要不可欠な設計でした。

6. おわりに：制約主導型アーキテクチャの勝利

現代の視点から『グランド・セフト・オート・サンアンドレアス』を振り返るとき、このゲームの広大でシームレスな世界は、ハードウェアの力任せなパワーによって実現されたのではなく、徹底的なマイクロコード、アグレッシブなキャッシュ制御、そして高度に体系化されたメモリ予算管理が維持し続けた「精巧なイリュージョン」であったことが浮き彫りになります。32MBのシステムRAMと4MBのeDRAMは、Rockstar Northのビジョンを制限するものではありませんでした。逆説的ですが、それらの厳格な境界線こそが、このゲームを可能にしたクリーンで予測可能なエンジニアリングの枠組みを定義していたのです。

ストリーミングエンジンは単にアセットをロードするだけでなく、回転するレーザーヘッドの物理的・機械的な限界を相手に、リアルタイムのダンスを指揮していました。ベクトル演算ユニットは単に頂点を変換するだけでなく、上位レイヤのソフトウェア抽象化を完全にバイパスし、シリコンから生の並行処理能力を直接引き出していました。

現代のウェブ開発やゲーム開発が、抽象化の上に抽象化を重ね、結果として巨大なデプロイ容量や最適化不足の実行環境を生み出しがちである今、『サンアンドレアス』はベアメタル（ハードウェア直結）システムエンジニアリングの極めて優れた手本としてそびえ立っています。ハードウェアが何一つタダでは与えてくれないとき、究極の最適化ツールとなるのは、そのベアメタルに対する深く、妥協のない理解であることを、本作は私たちに思い出させてくれます。サンアンドレアスという州は、あの2層DVDの中に最初から格納されていたわけではありません。それは、33ミリ秒のフレームを1コマずつ積み重ねるエンジニアリングの力によって、その場に「生み出され」続けていたのです。

---

参考文献＆推薦図書

• Copetti, R. (2018). PlayStation 2 Architecture: A Practical Analysis. Emotion Engine、Vector Units、Graphics Synthesizerのパイプラインに関する詳細な技術解析。
• Criterion Software. (2002). RenderWare Graphics SDK Documentation. 低レイヤ・ラスタライズ層の構造仕様およびコミュニティで保存されているドキュメント群。
• GTA Modding Community. GTA:SA Memory Addresses & Resource Streaming Documentation. .ipl や .ide ファイル構造、メモリストリーミング定数を詳細に解説する、コミュニティ主導のリバースエンジニアリングWiki。
• The re3 & reVC Projects. Open-source decompilation of RenderWare-era GTA engines (および保存された Internet Archive Torrent). エンジンの構造、メモリプール、エンティティの再利用ルーチンをマッピングした、完全に逆アセンブルされたオリジナルソースコード。

---

テクニカル用語集

用語	定義
Emotion Engine (EE)	PS2のメインCPU。128ビットのMIPS R5900コア（約294.912 MHz）に、2つのベクトル演算ユニット（VU0, VU1）と浮動小数点演算ユニットをダイ上に統合した、リアルタイム3Dシミュレーション専用のプロセッサ。
RDRAM	Direct Rambus DRAM。PS2のメインシステムメモリ（32MB）。約3.2 GB/sの帯域幅を提供し、コード、ゲーム状態、すべてのストリーミングアセットによって共有される。
eDRAM	Graphics Synthesizerのダイに直接統合された埋め込みDRAM。非常に高速だが容量は極めて小さい（4MB）メモリプールで、フレームバッファ、Zバッファ、および描画中のテクスチャを保持する。
Graphics Synthesizer (GS)	PS2専用のラスタライズGPU。固定機能パイプラインであり、プログラマブルシェーダーは非搭載。変換済みのジオメトリとテクスチャを受け取り、ピクセルを出力する。
VU0	EEコアにコプロセッサとして密結合されたベクトル演算ユニット。物理演算やサスペンションのモデリングなど、CPUロジックと毎サイクル密接にやり取りする必要がある演算に用いられる。
VU1	独自のローカルメモリを持つ、より自律的な2つ目のベクトル演算ユニット。主にジオメトリの変換、ライティング、クリッピング、およびGSへ送る前段のカリング処理に専念する。
GIF (Graphics Interface)	3つの優先度「Path」からGSへのデータ配信を調停するハードウェアインターフェース。ジオメトリやテクスチャのデータが正しい順序でラスタライザに到達することを保証する。
Path 1 / XGKICK	VU1からGSへ直結する最高優先度のバスルート。XGKICK 命令により駆動し、メインRAMを経由せずに、完成済みのジオメトリを直接GPUへプッシュすることを可能にする。
CLUT (Color Look-Up Table)	インデックスカラーテクスチャとペアになる小さなパレットテーブル。各ピクセルは色そのものではなくコンパクトなインデックスを保持し、CLUTがそのインデックスを実際のカラー値へとマッピングする。
Palette Shifting	テクスチャのCLUTパレット（数十〜数百バイト）を書き換えることで、ピクセルデータ本体に触れることなく、そのパレットを参照している全ピクセルの色を変化させる技術。
LOD (Level of Detail)	遠方や未ロードのジオメトリを描画するために常に常駐させておく、低ポリゴンで低精細な代替モデル。レンダラーに「常に描画すべき何か」を確保させるためのもの。
Hysteresis (LOD swapping)	LODティア間の切り替えにおいて、ダウングレード用とアップグレード用に2つの異なる距離閾値を用いること。境界線上のオブジェクトがフレームごとにモデルを入れ替えて点滅する「チラつき」を防ぐ。
Streaming Sector	ゲーム世界の地理を分割した離散的なグリッドセル。ジオメトリ、コリジョン、テクスチャのリソースセットを所有し、ストリーミングシステムがロード/アンロードを決定する際の最小単位となる。
Streaming Bubble	プレイヤー周辺の動的な半径。エンジンがセクターデータを先読み要求する範囲であり、DVDのシーク遅延を補償するためにプレイヤーの速度ベクトルに応じて拡大縮小する。
DVD-ROM (4x)	PS2の光学ストレージメディア。理論上のシーケンシャルスループットは約5.28 MB/s。不連続な読み取りにおいては、シーク遅延（一般に100〜200ms）がボトルネックとなる。
Frustum Culling	カメラの視錐台（ビューフラスタム）の外側にあるジオメトリを、GPUへ送る前に破棄する処理。変換負荷とフィルレート（塗りつぶし）負荷を軽減する。
RenderWare Graphics	『サンアンドレアス』が採用した低レイヤ3Dラスタライズ・ミドルウェア（Criterion Software製）。Rockstar North独自のシーン管理、ストリーミング、LODシステムは、その「内部」ではなく、このミドルウェアの「上層」に構築されていた。