Anatomy of a Texture

A graphics programmer recounts the surprising complexity of converting textures between gaming platforms, using a 1024x1024 RGBA example to explain why simple row-major memory layouts are rare in real engines. Key topics are block compression (focusing on BC7), texel ordering (swizzles such as Morton/Z-order), mipmaps, and tiled memory. Each technique optimizes performance - reducing bandwidth, improving cache locality, and enabling efficient sampling - but they change how texels are grouped, indexed, and sized in memory. BC7 compresses 4x4 texel blocks into 16-byte chunks, so code must treat blocks rather than individual texels; swizzles reorder texels for locality, and mips add multiple scaled levels, all of which can differ across platforms and thus require calculating exact memory addresses for every element during conversion.

Practical debugging advice addresses the real pain points: compressed formats are unreadable in raw dumps, misalignment or wrong swizzle makes textures appear as jumbled puzzle pieces, and naive writes can be misinterpreted. Useful techniques include writing four 32-bit integers per BC7 block to encode coordinates/mip level and using invalid-but-black 16-byte blocks as visible markers to locate regions in a texture viewer, then inspecting memory dumps between markers. The writeup highlights that beyond these core issues there are additional offsets like pitch, depth, and array indices, but the core challenge is correctly handling block vs. texel addressing and platform-specific ordering.