Cached at:
05/12/26, 03:21 PM
# TL;DR
*Grand Theft Auto III* used innovative streaming technology to fit an entire city into the PlayStation 2’s 32 MB of RAM. By loading and unloading assets in real-time, controlling Level of Detail (LOD), managing memory fragmentation, and optimizing disc layout, it delivered a seamless open-world experience.
## Background: 32 MB vs. a City
The PlayStation 2 (PS2) had a 4.7 GB DVD disc, enough to store the entire game — all models, textures, sounds, and radio stations. But the DVD read speed was slow (~5–6 MB/s), making real-time asset loading impossible; system RAM was fast (3.2 GB/s) but only 32 MB — less than 1% of the disc capacity.
The traditional approach was to load all data for the current area into memory, clear it upon leaving, and load the next area with a loading screen. But *GTA III*’s world was open and seamless. Players could freely explore Liberty City, built from thousands of unique models (~77 MB) and textures (~45 MB), totaling ~130 MB — far exceeding the memory budget.
## Solution: Streaming
The game’s technical lead, Adam Fowler, proposed a more radical method: divide Liberty City into thousands of small zones. Set an invisible square around the player and load only the models and textures for zones within that square. As the player moved, continuously load new zones while unloading those left behind.
Since newly loaded models were always far from the player, any slight delay from DVD reads wouldn’t cause noticeable stutter. This technique was called **streaming**.
By modifying *GTA III*’s source code and recompiling, you can see the mechanism visually: the city constantly loads and unloads chunks of assets as the player moves — the world secretly builds ahead and silently vanishes behind.
> **Core idea**: Don’t cram the whole city into memory. Build a “moving window” around the player, showing only what’s needed to maintain the illusion.
## Level of Detail (LOD) and Pop-in Control
A simple rectangular load zone would cause horrible “pop-in” — buildings appearing out of thin air. The solution:
- For distant zones, load only large structures (buildings, bridges, ships, etc.) using **simplified, low-poly, low-resolution texture** stand-ins.
- As the player approaches, stream in the real models and textures, smoothly fading them over the low-poly copies.
- This system is called **LOD** (Level of Detail).
Even other islands (Portland, Staunton, Shoreside Vale) each had low-poly versions that floated on the horizon as stand-ins for the rest of Liberty City. For example, Staunton Island had two different distant models — one when seen from Portland and another from Shoreside Vale — to avoid rendering unnecessary backfaces and save triangles.
## Memory Management: Squeezing Every Byte
The 32 MB of RAM also had to hold animations, pedestrian AI, physics calculations, player vehicle positions, and more. In reality, only a small portion was available for streaming. For example, in the same-engine *San Andreas*, the `stream.ini` file shows only about **13.5 MB** dedicated to city streaming.
### Vehicle Pool Limits
The game had ~60 unique vehicle types, with total models + textures ~10 MB. But only 8 vehicle types’ models could be kept in memory at once. When spawning a new car, either reuse one of the existing 8, or kick out an old one to free up space. This pool had to include the car you’re driving, cars you drove earlier, nearby parked cars, plus common taxis, police cars, helicopters, military trucks, etc. This is why players often see the same vehicles repeatedly, and why after finding a rare car, it seems to appear everywhere — because it occupies one of the eight slots, increasing its spawn probability.
### Memory Fragmentation
Continuously loading and unloading small resources created memory fragmentation that was hard to coalesce, potentially crashing the game. Adam Fowler wrote a custom memory manager that could:
- Merge and move memory blocks to avoid fragmentation.
- Actively free memory — delete objects behind the camera or large buildings on the distant horizon.
- Ensure **hundreds of resource files were exactly the same size**: over 500 files were exactly 2 KB, and 416 exactly 4 KB. This allowed resources to seamlessly replace each other when loaded/unloaded, filling gaps and preventing fragmentation.
Testing method: Bind the character to a train speeding around Portland, and let the game run on five PS2 dev kits overnight. All crashed within the first five minutes. After days of debugging, gradually survived half an hour, one hour, and eventually ran all night — meaning it cycled through loading and unloading models all night long.
## Disc Seek Optimization
DVDs were designed for sequential reads (like movies), with data stored in a continuous spiral track. Jumping to another part of the disc (seeking) required moving the laser, costing time. *GTA III* constantly asked the DVD reader to seek different locations. To speed this up, Rockstar had to physically optimize resource placement on the disc:
- Group assets from the same city area together to minimize long laser movements.
- The DVD reader code maintained a queue of pending loads, prioritizing assets closest to the current read position, not in queue order.
- Try duplicating assets on the disc — for example, placing multiple copies of the same model (trees, lampposts) at different locations on the disc, which was more efficient than constantly seeking back to a single location. This technique is still used today, e.g., Insomniac’s *Spider-Man* placed hundreds of identical mailboxes on the Blu-ray disc.
## Risks and Validation
Was constant seeking safe for the DVD drive? Producer Leslie Benzies said in a documentary: “Streaming was risky. Could the drive in the machine keep moving for 24 hours without melting?” In fact, the PS2 drive did not melt — Vermeij believes Sony approved the design before release. The game was ultimately successful and set a technical benchmark for the entire open-world genre.
---
Source: How Rockstar fit an entire city into PlayStation 2 memory (https://www.youtube.com/watch?v=cIbCxbrBCys)