Stop Shipping PNGs in Your Games

Summary

Are you shipping textures to players as PNGs? The goal of this post is to convince you that this is suboptimal, and walk you through a better approach.I’ll also share my implementation of the suggested approach, but if you’d rather do it yourself I’ll also provide you with the information you need to get started.If you’re using a game engine, it is almost certainly doing what this post suggests automatically, but it doesn’t hurt to double check! sourcePNGs are great for interchange. They’re lossless, they compresses well, and support is ubiquitous. PNG is my image interchange format of choice.This post isn’t a criticism of PNGs–it’s just that the PNG format is designed for image data, not texture data.Here are some examples of features you would expect out of a texture format that you’re not going to find in an image format:Can you work around all these issues? Sure.You can premultiply and generate your mipmaps at load time. You can ship separate images for each cuebmap face. But now you’re resigned to cheap mipmap generation, and cubemaps that are difficult to downsample correctly.You can certainly make it work, but you’re making things unnecessarily difficult for yourself by using the wrong tool for the job.Furthermore, texture formats have a killer feature not mentioned above–support for GPU compatible texture compression like BCn.An in-depth explanation of GPU compression formats it out of scope for this post, but at a high level, these formats store each block of pixels as a couple of endpoints and a method for interpolating between those endpoints.This trades mild degradation of image quality for improvements in storage, VRAM usage, and sampling performance. It’s so good it feels like you’re cheating thermodynamics.GPUs can’t decompress PNGs on the fly, so as a result, if you ship PNGs you either can’t take advantage of this compression, or you have to first decompress the PNGs and then do an extremely expensive compression step to convert to the desired block...