While current industry discussion revolves around massive multi-gigabyte streaming pools and high-throughput NVMe architectures, modern open-world design owes its foundational breakthroughs to hardware constraints that seem unfathomable today. When Rockstar North released Grand Theft Auto: San Andreas in 2004, they pushed Criterion Software’s RenderWare engine to perform a task the Sony PlayStation 2 was never explicitly designed to handle: seamlessly rendering a $36 \text{ km}^2$ dynamic world without loading screens, operating entirely within 32 Megabytes of main system RAM.

Understanding how San Andreas achieved this requires stepping back into early-2000s low-level system engineering, hardware-level Direct Memory Access (DMA) manipulation, and custom asset streaming pipelines.

The 32 MB Bottleneck: PS2 Hardware Realities

To appreciate the architecture of San Andreas, one must first examine the physical limitations of the PlayStation 2 hardware architecture.

Component	Specification	Bottleneck / Constraint Impact
CPU (Emotion Engine)	294.912 MHz MIPS R5900	High clock-cycle cost for complex spatial algorithms
System RAM	32 MB Direct RDRAM (3.2 GB/s)	Shared between executable code, audio, physics, and world state
VRAM (Graphics Synthesizer)	4 MB Embedded DRAM (48 GB/s)	Extremely limited local texture/framebuffer storage
I/O Processor (IOP)	36.864 MHz MIPS R3000A	Handles Disc I/O; maximum read speed bottlenecked by drive
Optical Drive	4x Speed DVD-ROM	~5.28 MB/s maximum theoretical transfer rate

The primary challenge was simple math: loading the full geometric mesh data, texture maps, collision models, and audio banks for a single district (such as Los Santos) required roughly 150 MB to 200 MB of uncompressed assets. With only 32 MB of system memory and 4 MB of VRAM, storing the world state in memory was impossible.

The Dynamic Sector Streaming Pipeline

Rockstar North solved this memory mismatch by ditching traditional monolithic scene graphs in favor of a dynamic spatial sector grid. The game world was divided into a 2D spatial grid made up of discrete sectors.

Asset loading was governed by two primary ASCII descriptor file formats: Item Definitions (.IDE) and Item Placements (.IPL).

Python

[DVD Read Request]
       │
       ▼
┌──────────────┐      DMA Transfer      ┌─────────────────────────┐
│ IOP (Buffer) │ ────────────────────>  │ Direct RDRAM (32 MB)    │
└──────────────┘                        └────────────┬────────────┘
                                                     │
                                             LOD & Frustum Culling
                                                     │
                                                     ▼
┌─────────────────────────┐   VIF Bus   ┌─────────────────────────┐
│ Graphics Synthesizer    │ <────────── │ Emotion Engine / VU1    │
│ (4 MB eDRAM VRAM)       │  1.2 GB/s   │ Geometry Pipeline       │
└─────────────────────────┘             └─────────────────────────┘

The rendering engine prioritized geometry based on Euclidean distance $d$ relative to the active camera position $(x_c, y_c, z_c)$ :

$d = \sqrt{(x_2 - x_c)^2 + (y_2 - y_c)^2 + (z_2 - z_c)^2}$

When $d$ fell below a designated Streaming Distance threshold $T_{\text{stream}}$ , an asynchronous read command was queued to the IOP to fetch the required .IMG archive block containing the binary mesh (.DFF) and texture dictionary (.TXD).

Handling Disc Access Latency

Because the 4x DVD-ROM drive had seek latencies ranging from 100ms to 300ms, streaming requests could easily stall the render pipeline. Rockstar mitigated this using a dual-queue priority system:

High-Priority Queue: Implied spatial movement (e.g., assets directly in front of a high-speed vehicle vector).
Low-Priority Queue: Ambient background LODs, distant foliage, and secondary pedestrian models.

Memory Management and Asset Eviction C++ Logic

Below is a simplified, conceptual C++ implementation illustrating how RenderWare managed streaming buffers, distance calculation, and non-blocking asset eviction to prevent out-of-memory (OOM) faults.

C++

#include <iostream>
#include <vector>
#include <cmath>
#include <algorithm>

struct Vector3 {
    float x, y, z;
};

struct AssetItem {
    uint32_t id;
    Vector3 position;
    float drawDistance;
    bool isLoaded;
    uint8_t* rawBuffer;
};

class StreamingEngine {
private:
    static constexpr size_t MAX_STREAM_MEMORY = 12 * 1024 * 1024; // 12MB allocated pool for assets
    size_t currentMemoryUsage = 0;
    std::vector<AssetItem> registry;

public:
    float CalculateDistance(const Vector3& a, const Vector3& b) {
        return std::sqrt(std::pow(a.x - b.x, 2) + std::pow(a.y - b.y, 2) + std::pow(a.z - b.z, 2));
    }

    void ProcessStreamingPipeline(const Vector3& cameraPos) {
        // Sort assets by distance to prioritize loading close objects
        std::sort(registry.begin(), registry.end(), [this, &cameraPos](const AssetItem& a, const AssetItem& b) {
            return CalculateDistance(a.position, cameraPos) < CalculateDistance(b.position, cameraPos);
        });

        for (auto& item : registry) {
            float dist = CalculateDistance(item.position, cameraPos);

            // Evict out-of-range assets immediately
            if (dist > item.drawDistance && item.isLoaded) {
                UnloadAsset(item);
            }
            // Request async load for assets entering streaming radius
            else if (dist <= item.drawDistance && !item.isLoaded) {
                if (currentMemoryUsage + 256000 <= MAX_STREAM_MEMORY) { // Assuming 256KB block
                    LoadAssetAsync(item);
                } else {
                    // Cache limit hit: Evict farthest loaded asset
                    EvictFarthestAsset(cameraPos);
                }
            }
        }
    }

private:
    void LoadAssetAsync(AssetItem& item) {
        item.isLoaded = true;
        currentMemoryUsage += 256000;
        // Invoke IOP DMA Transfer Here...
    }

    void UnloadAsset(AssetItem& item) {
        item.isLoaded = false;
        currentMemoryUsage -= 256000;
        item.rawBuffer = nullptr;
    }

    void EvictFarthestAsset(const Vector3& cameraPos) {
        // Loop backwards from sorted registry to find the farthest loaded asset
        for (auto it = registry.rbegin(); it != registry.rend(); ++it) {
            if (it->isLoaded) {
                UnloadAsset(*it);
                break;
            }
        }
    }
};

VRAM Optimization: Palette Textures and VU1 Microcode

Loading low-polygon meshes was only half the battle. Storing textures inside the PS2's tiny 4 MB Graphics Synthesizer eDRAM required rigorous texture compression hacks.

Because the PS2 lacked hardware support for standard block compression like S3TC/DXT, Rockstar relied heavily on CLUT (Color Look-Up Table) palette-indexed textures. Instead of storing 24-bit or 32-bit RGBA pixels directly, textures were encoded using:

4-bit Palettized (16 colors): Used for roads, terrain tiles, and building walls.
8-bit Palettized (256 colors): Reserved for vehicle body paint, main character details, and UI elements.

Technical Detail: By using 4-bit CLUT textures, a $256 \times 256$ resolution texture took up only 32 KB of VRAM instead of the 256 KB required by standard 32-bit RGBA formats.

To process geometry efficiently, RenderWare bypassed standard CPU code paths for rendering and passed geometry packets directly to Vector Unit 1 (VU1). Using hand-optimized inline assembly, VU1 performed local transformation matrices, backface culling, and vertex lighting in parallel with the Emotion Engine CPU, ensuring frame rates remained stable during dense urban scenes.

Conclusion

The seamless open world of Grand Theft Auto: San Andreas was not achieved through raw compute performance, but through strict spatial allocation, synchronous IOP DMA streaming, and low-level palette management. By treating system memory as a fluid buffer rather than a static storage unit, Rockstar North maximized the utility of the PS2's modest 32 MB RAM pool, producing architectural principles that continue to inform modern streaming paradigms across the industry.

Deconstructing RenderWare: How San Andreas Streamed an Open World from 32MB RAM