DDS in Games: Why Engines Love BC and DXT Compressed Textures

Why DDS is the native tongue of game engines

DDS (DirectDraw Surface) was invented by Microsoft all the way back in DirectX 7.0 (September 1999), and over a quarter of a century this container became the unofficial standard for PC-game textures. The reason is simple: DDS is the one common format that can store a texture already in the form the graphics card expects it. Not a "picture for a human," but a ready-to-upload block of VRAM data with mipmaps, cubemaps and the right compression type packed inside a single file.

Any other format — PNG, JPG, TGA — the engine first has to decode on the CPU into a full-size uncompressed RGBA buffer, then re-encode into a GPU format on import. DDS skips that whole ordeal: load the file, hand it to the graphics card. That's why when you dig into the assets of nearly any game, from Skyrim to fresh AAA titles, you will almost certainly run into .dds.

4×4 blocks and how they save VRAM

The heart of the format is block compression (Block Compression, BCn; formerly known as S3TC or DXT). A texture is sliced into 4×4-pixel squares, and each block is encoded with a pair of reference colors plus a compact set of indices. The crucial part: the graphics card decodes these blocks on the fly, right as it samples a texel — and keeps the texture in VRAM compressed.

The numbers speak for themselves. A BC1 block takes 8 bytes per 4×4 pixels — that's 0.5 bytes per pixel, or 4 bits per pixel. Uncompressed RGBA is 4 bytes per pixel. So BC1 gives 8:1 compression for opaque textures. BC7 and BC6H weigh twice as much — 16 bytes per block (1 byte/pixel) — but that's still 4:1 compression versus uncompressed.

To make it tangible: a 4096×4096 texture in uncompressed RGBA is 64 MB. In BC1 it's just 8 MB; in BC7, 16 MB. Now multiply that by hundreds of materials in a single scene, and it becomes obvious why a modern game simply wouldn't fit in video memory without compression. Different BC variants are tuned for different jobs.

Why compressed textures mean a stable FPS

Here's the counterintuitive bit. It seems like decoding should slow rendering down — but in practice compression speeds it up. The win isn't in the decode (that's free, baked into the GPU's texture units in hardware); it's in memory bandwidth.

Every frame the graphics card reads millions of texels from VRAM. If a texture is uncompressed, each pixel costs 4 bytes of traffic over the memory bus. In BC1, it costs 0.5 bytes. That's 8 times less data to push through memory on every sample. In scenes with lots of materials, the memory bus is often the bottleneck — and compressed textures relieve it, helping hold an even frame with no dips.

As a bonus, compressed textures sit better in the GPU cache: more texels fit into the same cache line, which means fewer misses and fewer trips to slow video memory. So the tech-artist rule is unambiguous: don't disable texture compression without a very good reason — it's almost always a win, on both memory and speed.

Texture streaming and fighting pop-in

Even at 8:1 compression, an open world's textures add up to tens of gigabytes — while a top-tier graphics card rarely has more than 16–24 GB of VRAM. The answer is texture streaming. The engine keeps only the mip levels that are actually visible right now in video memory and streams in more detailed versions from disk as you approach objects.

DDS is perfect here again: the texture is already split into mipmaps and stored compressed, so streaming individual levels is fast and cheap. Streaming has a "budget" — a fixed amount of VRAM for all streamable textures. When a scene exceeds the budget, the engine doesn't evict textures wholesale; it gracefully lowers their resolution by using smaller mip levels in place of the full-size ones.

Modern engines go further with virtual texturing: instead of whole textures, they load only the visible fragments (tiles). That makes it possible to show surfaces at extreme resolution while keeping only a tiny fraction of their full size in VRAM.

Mipmaps and LOD in a real scene

Mipmaps are pre-scaled copies of a single texture: full size, then half, a quarter, an eighth, and so on down to 1×1. They are all stored right inside the DDS file. When an object is far from the camera, the GPU has no reason to read a 4096×4096 texture — it grabs a smaller mip level.

That delivers two effects at once. First, the unpleasant "shimmering" of distant surfaces (aliasing) disappears: a fine texture on a far-off wall no longer turns into noise. Second, the GPU reads less data and uses the cache more efficiently — rendering gets faster. Mipmaps are texture LOD (level of detail) in action.

Texture budgets: PC versus consoles

A texture budget is the unspoken contract between artist and hardware: how much VRAM you can spend before the game starts to stutter. On PC the picture is messy — one player has an 8 GB card, another has 24. So engines set a conservative streaming pool by default (in Unreal Engine it's around 1000 MB, up to 2000 MB depending on quality settings) and scale detail to the specific system.

The common tech-artist rule of thumb is to keep texture memory usage below roughly 75% of available VRAM, leaving headroom for frame buffers, shadows and the rest of the render's needs. Overshoot, and you get constant swapping and micro-stutters.

On consoles things are different — and in some ways simpler. The PS5 and Xbox Series X carry 16 GB of unified memory, shared between CPU and GPU, plus a blazing-fast NVMe SSD. That combination lets them stream textures so aggressively that noticeable pop-in has all but vanished on current-gen consoles. A fixed configuration is a blessing for developers: the budget is known up front, so every asset can be tuned to it — something you can never pull off across the patchwork of PC hardware.

Engine support: Unreal, Unity, CryEngine, Source

Every leading engine works natively with block-compressed textures, and DDS is the natural container for them:

• Unreal Engine. On import, textures are compiled to BCn: BC1/BC3 for color, BC5 for normals, BC7 for high-quality maps on PC and consoles. The built-in streamer with a configurable VRAM pool manages mip levels automatically.
• Unity. For DirectX 11+ GPUs it recommends DXT1 (BC1) for RGB and BC7 where quality matters. There's also Crunch — a layer on top of DXT that further shrinks the texture on disk (it doesn't affect runtime memory, but it cuts build size).
• CryEngine. Historically one of the most texture-hungry engines; DDS with precomputed mipmaps is its core working asset format.
• Source / Source 2. Uses its own VTF container, but it's built on the very same DXT/BC compression formats — and for exchange and modding it all comes back to DDS.

Where it's all heading: BC7 and trends

Old reliable BC1 is alive and well — for many textures the quality loss at 8:1 compression is practically invisible, and the space saving is worth it. But the flagship format of the modern PC is BC7. It supports up to 8 bits per channel and reproduces gradients, skin and skies — where BC1 visibly falls apart — far more cleanly. By the objective PSNR metric, BC7 delivers more than 42 dB against 35–40 dB for BC1 — a gap the eye catches on complex transitions.

The cost of that quality is double the size (8 bits/pixel versus 4). So production runs on a hybrid principle: BC1 for opaque color, BC3 for transparency, BC5 for normals, and BC7 for the headline "hero" textures the player examines up close.

Want to put an edited texture back into the game? The reverse conversion comes in handy — PNG to DDS with a choice of compression type. And the full list of supported conversions is always on the all formats page. If you're just getting into the topic, start with the guide "What Is DDS", and for hands-on practice see our piece on game modding with DDS textures.