Picking the wrong resolution or compression format is one of the most common mistakes in Source Engine texture work — go too high and you waste memory and file size for no visible benefit; go too low or pick the wrong compression and your textures look blurry or blocky in-game. Unlike modern engines that often lean on adaptive streaming, Source Engine texture decisions are largely fixed at conversion time, so it’s worth getting them right upfront.
This guide breaks down how to choose resolution and format based on what the texture is actually used for, rather than defaulting to “as high as possible.”
Table of Contents
- Why Resolution and Format Matter More Than People Think
- Resolution Guidelines by Texture Type
- Power-of-Two Requirements
- Choosing a Compression Format
- Format Selection by Texture Type
- How to Tell If You’ve Over- or Under-Sized a Texture
- Quick Reference Table
- FAQ
Why Resolution and Format Matter More Than People Think
Source Engine loads textures into GPU memory largely as-is, and there’s no automatic quality scaling based on distance beyond what mipmaps provide. That means every oversized texture is a permanent memory and file-size cost, not a temporary one — and every wrong compression format choice is a visible quality issue that persists no matter how good your source artwork was.
Getting these two decisions right at conversion time avoids having to redo a texture pack later after noticing performance issues or visual artifacts in-game.
Resolution Guidelines by Texture Type
Resolution should be driven by how large the texture appears on screen during typical gameplay, not by how much detail exists in your source artwork. Rough starting points:
- Weapons and first-person view models: 1024×1024 to 2048×2048 — these are viewed up close constantly, so extra detail is genuinely visible
- Player models and main characters: 1024×1024 per major texture sheet is usually sufficient for most engine branches
- Standard world props (furniture, crates, mid-size objects): 512×512 to 1024×1024
- Small props and background details: 256×256 to 512×512
- Wall and floor textures (tileable): 512×512 to 1024×1024, depending on how large an area a single tile covers
- Distant terrain, skybox elements: 256×256 to 512×512, since these are rarely viewed up close and skyboxes in particular benefit more from smaller, well-compressed textures
- HUD icons and UI elements: 32×32 to 128×128 (see our HUD and sprite guide for details specific to UI textures)
These are starting points, not hard rules — a texture that covers a huge visible surface (like a large tiled floor) may justify going a step higher, while one that’s rarely seen up close can often go a step lower with no visible difference.
Power-of-Two Requirements
Source Engine textures should generally use power-of-two dimensions: 32, 64, 128, 256, 512, 1024, 2048. While some modern engine branches tolerate non-power-of-two textures, older Source titles and many tools in the pipeline still expect it, and mipmapping in particular relies on clean power-of-two halving at each level. Non-square textures are fine (e.g. 1024×512) as long as both dimensions are individually powers of two.
Choosing a Compression Format
The three formats you’ll use for the vast majority of Source Engine textures:
- DXT1: For opaque textures with no transparency. Roughly 6:1 compression versus uncompressed, making it the default choice for the majority of world and prop textures.
- DXT5: For textures that need an alpha channel — transparency, blend masks, glow maps. Larger than DXT1 but still heavily compressed.
- RGBA8888 (uncompressed): Reserved for cases where DXT’s block-based compression creates visible artifacts — typically small UI elements with hard edges, or gradient-heavy textures where DXT5 banding is noticeable. This format is 4-8x larger than DXT1 and should be used selectively, not by default.
For a deeper comparison of DXT1 versus DXT5 tradeoffs specifically, including when the file size difference is and isn’t worth it, see our dedicated compression guide.
Format Selection by Texture Type
Matching format to actual transparency needs, rather than defaulting to DXT5 everywhere, is one of the easiest ways to control file size without any visible cost:
- Opaque world textures (walls, floors, most props): DXT1
- Foliage, fences, chain-link, anything with cutout transparency: DXT5
- Glow maps, blend masks, decals with soft edges: DXT5
- Small HUD icons with hard edges: RGBA8888 or DXT5 with alpha test, depending on how visible compression artifacts are at that size
- Skyboxes: DXT1 (skyboxes are opaque and benefit significantly from the smaller file size across six faces)
How to Tell If You’ve Over- or Under-Sized a Texture
A practical way to check: view the texture in-game at the typical distance and angle a player would actually encounter it, not zoomed in in an image editor. If you can’t tell the difference between the current resolution and a step lower at normal viewing distance, it’s oversized. If edges look visibly soft or blocky at normal viewing distance, it may be undersized or using the wrong compression format for its content.
It’s also worth checking file size against the number of similar textures in your pack — a handful of oversized textures can quietly account for a large share of a pack’s total download size without being individually obvious.
Quick Reference Table
| Texture Type | Suggested Resolution | Suggested Format |
|---|---|---|
| Weapons / first-person view models | 1024–2048 | DXT1 (DXT5 if transparent parts) |
| Player models | 1024 | DXT1/DXT5 mixed by part |
| Standard world props | 512–1024 | DXT1 |
| Small/background props | 256–512 | DXT1 |
| Tileable walls/floors | 512–1024 | DXT1 |
| Skyboxes | 256–512 | DXT1 |
| Foliage / cutout transparency | 512–1024 | DXT5 |
| HUD icons | 32–128 | RGBA8888 or DXT5 |
FAQ
Should I always use the highest resolution my source art supports? No — resolution should match how the texture is actually viewed in-game, not the maximum detail available in your source file. Oversized textures cost memory and file size without a visible benefit if the surface is small or rarely viewed up close.
Is DXT5 ever a bad choice even for opaque textures? Yes — using DXT5 on a texture with no actual transparency wastes file size on an alpha channel that has no data to store, since DXT1 achieves the same visual result for opaque content at a smaller size.
Does non-power-of-two resolution ever cause actual problems, or is it just a convention? It depends on the game and engine branch — some modern Source-based titles handle it fine, but many older titles and tools in the pipeline still expect power-of-two dimensions, and mipmapping specifically relies on clean halving at each level. Sticking to power-of-two avoids compatibility issues across the widest range of games.
How do I know if a texture needs DXT5 instead of DXT1? If the source PNG has any meaningful transparency — cutout edges, soft alpha blending, or a glow/blend mask — it needs DXT5. If the image is fully opaque with no alpha data used, DXT1 produces the same visual result at a smaller file size.