Texture formats for 2D games, part 3: DXT and PVRTC

DXT is the most used texture format in games and it is what we use most in Swords & Soldiers II and Awesomenauts. DXT is easy to use but provides some weird compression artefacts, so a good understanding of how it works is very useful for both artists and graphics programmers. Since DXT is not supported on iOS I will also shortly discuss the quite similar PVRTC format. This is part 3 in my short series on texture formats for 2D games. Here are part 1 and part 2.

Note that DXT is often also referred to as DDS because DXT textures are usually saved as .DDS files. DXT is also known as S3 Texture Compression.

There are several versions of DXT. The most versatile type is DXT5, which stores an alpha channel that can be used for transparency. DXT5 uses only 8 bits per pixel, making it 75% smaller than full 32bit RGBA. If no alpha is needed or only on/off alpha, DXT1 can be used, which is even smaller: 4 bits per pixel, making it 87.5% smaller than RGBA. That's quite a spectacular win, so where's the catch?

The downside is that DXT can bring serious quality loss due to how it compresses textures. The quality impact of this compression heavily depends on the type of art: some textures will look really bad but in most cases it will look fine as long as you don't zoom in on the compression. Zooming in that far is not common in 2D games so DXT is very usable despite the quality loss.



The most basic type of DXT is DXT1. Here's how it works:



This means that if a single 4x4 block contains few different colours, there won't be any significant compression artefacts. Having more colours inside the block is also fine if those colours are near the others. For example, if the block stores red and yellow then it can also store orange well since that is in between. Heavy artefacts occur if the block contains more really different colours. For example, if a 4x4 block contains red, green and black, then one of those will be lost and replaced by one of the others (whichever is nearest to reduce the artefacts).



This sounds absolutely horrible, but the fun part is that we are only talking about tiny 4x4 blocks here. In practice few blocks contain many different colours, and even if they do the next block will be able to choose different colours, so artefacts usually remain small. In practice in 2D games DXT artefacts will mostly appear in spots where three coloured areas touch each other, and around thin outlines. Have a good look at the image below to get an idea of which situations result in serious artefacts and which are fine.



As you can see above, if your art contains lots of thin outlines it will be damaged severely by DXT1. However, fixing this by going from DXT1 to 24bit RGB makes your textures 6 times bigger. Auch! Luckily there is an awesome compromise: if you store your DXT texture at a slightly higher resolution it will look a lot better and still be smaller than RGB. Upscaling makes the outlines (or other small details) thicker, greatly reducing the artefacts. If you make your texture 41% wider and higher it becomes twice as big, which is still 3 times smaller than RGB. As a huge bonus you also get sharper textures, so this probably looks way better than the lower resolution RGB texture would have. We've used this trick in Awesomenauts on all the characters: they're stored a bit higher than required for a 1920x1080 screen to reduce artefacts.





The format I've explained so far is DXT1, while DXT5 is what you'll want to use most. Colour is stored in the exact same way in DXT1 and DXT5. The difference is that DXT1 only has 1 bit alpha, while DXT5 can also store partially transparent pixels. DXT5 stores alpha in the same way as colour, so it stores two alpha values per block. Per pixel it stores an interpolation value for the alpha. So in total DXT5 stores two colours and two alpha values per block, and for each pixel one interpolation value for the colour and one for the alpha. This makes DXT5 exactly twice as big as DXT1 and results in high quality alpha/transparency.

There's also DXT3, but in practice I've so far never found it useful. DXT3 does not store two alpha values to interpolate between: instead it just uses 4 bits per pixel to directly store alpha per pixel. Since it's only 4 bits this means DXT3's smallest alpha step is 16. In other words: DXT3 is really bad at doing subtle alpha gradients, but really good at doing strong alpha contrasts (like object outlines). Since DXT5 is already good enough at doing strong alpha contrasts I've so far never used DXT3 in an actual game.

DXT1 can also store alpha, but only 1 bit alpha, so only on/off. A clever yet simple trick is used for this. Remember that each 4x4 block stores two colours. If the first colour is brighter than the second colour, then a block can store four different colours: the two main colours and two interpolated colours. This is how I explained it above. If however the first colour is darker than the second colour, then the block can store only three different colours. The fourth colour is used for fully transparent pixels. This results in slightly less colour quality around edges in the texture. Unfortunately it's only 1 bit alpha, so any anti-aliasing on object edges is lost.



There is another type of quality loss happening with DXT compression that I haven't mentioned yet. Colours are stored with 16 bits instead of the full 24 bits. This means that on top of the compression artefacts already mentioned we also get less colour depth. For most textures this is not a problem, but for subtle gradients it is. For this reason in Awesomenauts and Swords & Soldiers II we don't store pure gradients using DXT. We use simple 24 bit TGA instead. This is much bigger, but gradients are usually very thin, so storing a bunch of 256x1 textures with less compression is no problem.



Since DXT is used by so many games there are plenty of tools and plugins to work with it. For example, Nvidia has released a free Photoshop plugin for handling DDS files. When using this for 2D games, be sure to turn off mipmaps to save some more texture space (unless you actually need those mipmaps of course). Image browsing tool XnView supports DXT right away and I've heard there's even a plugin for Windows to see thumbnails of DXT files directly in Windows Explorer.

A fun aside here is that we've tried writing our own DXT compression tool to achieve DXT with less visual artefacts specifically for 2D games. We indeed managed to slightly reduce compression artefacts, but at the cost of more flickering in animations, so we ended up not using our own DXT compression tool. Maybe I'll get around to writing about that some day, let me know if you're specifically interested in this.

An important note on DXT is that iOS doesn't support the DXT format. Instead it has PVRTC. I haven't made any iOS games myself (Proun+ and Swords & Soldiers 1 were ported to iOS by respectively Engine Software and Two Tribes) so I don't personally have any experience with PVRTC). The rough concepts are pretty similar though. The big difference is that PVRTC doesn't have the little 4x4 block artefacts that DXT produces. Instead, PVRTC's compression artefacts come in the form of a slight blurriness.

One trick to improve quality with PVRTC is the same as with DXT: saving at a slightly higher resolution than what you really need will massively reduce the compression artefacts. Aaron Oostdijk from Gamistry (creators of the mobile hits Gold Diggers and Munch Time) mentions it also helps a lot to first smear the RGB colours our across the transparent areas. “A tool called Solidify B does this very nicely. And sometimes a light dither after that will improve results even more.” Note that I didn't use those tricks when compressing the image below.



On iOS you get the additional requirements that textures need to be square (same width and height) and power-of-two (16, 32, 64, 128, 256, 512, etc.). In many cases these two extra requirements demand a huge waste of texture space, unless you work around them through clever usage of texture atlases. On PC and console these requirements have been abolished around a decade ago, making efficient texture usage much easier there.

DXT results in serious compression artefacts but it provides such powerful compression that it is by far the best option for the vast majority of games. Next week I'll wrap up this series on texture formats by giving a big overview of all the formats discussed. See you then!

See also:
-Texture formats for 2D games, part 1
-Texture formats for 2D games, part 2: Palettes
-Texture formats for 2D games, part 4: Overview

Texture formats for 2D games, part 2: Palettes

After last week's introduction to texture formats we are going to look at palette textures today. Palette textures are an interesting and underused option for 2D games. Using them is quite a hassle since normal videocards don't support them, but for certain art styles they offer high quality and small texture size.

Palette formats are similar to GIF files. The idea is that we have a palette, a list of all the colours in a specific texture. In the actual texture we don't store the colour of each pixel, but rather a reference to the palette. If the texture doesn't have a whole lot of colours we can get away with using only 256 different colours. References to these can be stored in 8 bits per pixel, so this format is 75% smaller than uncompressed RGBA.



Palette textures are particularly useful for cartoony styles with flat shading, since those have fewer colours per texture. If your textures have more than 256 colours, you can reduce the number of colours. Depending on the art style this loss in quality might be acceptable. For a style with lots of colours and gradients, it probably isn't.

Most textures in Swords & Soldiers 1 on Nintendo Wii were stored using palettes. Some textures even had few enough colours that we could get away with only 16 different colours in the entire texture. This means we needed only 4 bits per pixel. That's 87.5% smaller than uncompressed RGBA! This would bring a 4096x4096 texture down from 64mb to 8mb. Of course such heavy compression is only suitable for some art styles and some textures.





The big caveat is that most videocards don't support palette textures directly. Older videocards like the one of the Nintendo Wii support it, but none of the modern Nvidia, AMD or Intel cards do. Swords & Soldiers 1 was originally a Wii game so we could easily use palette textures there.

This doesn't mean that using palette textures is impossible, just that it's more involved. It's quite easy to write a pixel shader that uses the colour from a greyscale texture as an index for a lookup in a 1D palette texture.

The problem with doing this yourself is that you can't use texture filtering any more. Interpolating palette indices results in random colours. To implement standard bilinear filtering you need to sample and interpolate the colours yourself in the pixel shader. Including the lookups in the palette this means 8 texture reads per pixel. If you happen to also need trilinear filtering for mipmapping this increases to 16 texture reads per pixel. Luckily not all 2D games need mipmapping, but still: 8 texture reads per pixel is significant and costs performance. However, the fun part is that many 2D games have plenty of performance to waste. If this is the case for your game and you have the time to write a good pipeline for them, then palette textures might be an excellent choice.



An interesting side effect of reducing the number of colours for a palette texture is that it makes ZIPping the texture much more effective. With less colours in the texture there is less variation so it can be compressed more effectively. This only helps for download size and for the size of the texture on disk: videocards can't handle ZIPped textures so the texture needs to be unzipped before it goes into video memory.

We used this extensively in Swords & Soldiers 1 to reduce download size. Since the Nintendo Wii had an extremely small hard disk keeping the install size of the game small was really important. For this reason we reduced the number of colours even in cases where it didn't make the texture itself smaller. For example, the size in video memory is the same for a texture with 200 colours or 256 colours. However, the texture with only 200 colours can be ZIPped further. Often there is no visible quality loss when reducing the number of colours a bit further, so we did this with a lot of textures on the Wii version of Swords & Soldiers 1.

When saving an image for the web in the GIF format it's common to turn on dithering. Dithering makes a palette texture alternate between two different colours in a noisy pattern to achieve what looks like smoother gradients with fewer colours. This works quite well for the web, but is totally unsuitable for games. Dithering makes the art flicker like crazy when an object moves around, so in games it can only be used on objects that are rendered pixel perfect, like the backdrops in old adventure games.



A huge benefit of palette textures is that team colours and colour variations can be done extremely efficiently. By simply swapping the palette you can change all the colours. This costs hardly any memory or additional performance.

In Awesomenauts we don't use palette textures so we have to store each character twice: once for the red team and once for the blue team. With palette textures this wouldn't have been necessary. To add to the fun this would also have allowed us to let the player customise his team colour (not that we would want that in a team-based game in which the visuals are all about readability). Lots of other fun tricks can be achieved through clever usage of palette swapping.





Since palette textures aren't supported by videocards by default they are quite impractical to use. Their limitation of a maximum of 256 different colours per texture is also very limiting. However, with certain art styles this technique will give you powerful, lossless compression and easy colour swapping, unique benefits that no other texture format can provide.

See you next week for a look into the master: DXT texture compression!

See also:
-Texture formats for 2D games, part 1
-Texture formats for 2D games, part 3: DXT and PVRTC
-Texture formats for 2D games, part 4: Overview

Texture formats for 2D games, part 1

When making a large scale 2D game like Swords & Soldiers II or Awesomenauts using the right texture formats can make a big difference for visual quality, video memory, loading times and download size. What format works best varies depending on art style and platform and a good understanding of the options helps a lot in making the right choices.

This is a huge topic so I've split it into four posts. Today I'll cover the basics. The other three posts will discuss the more obscure palette textures, DXT and finally a comparison table of all the discussed techniques. This short series will get a bit technical at points but I've tried to make it as readable for artists as possible: knowing how your art will be compressed is important for game artists.

While the texture formats available for 2D and 3D games are the same, 2D games have different requirements, so it is interesting to approach this topic from a 2D standpoint. Also, 2D games usually don't have things like normal maps, roughness maps and reflection maps and mostly don't need high dynamic range (HDR) textures, so I won't be discussing the requirements of such special kinds of textures.

The first thing to realise is that transparency is extremely important in 2D games. While in a 3D game the shape of an object is generally determined by its polygons, the shape in a 2D game usually comes from transparency in the texture. In many 2D games the art is put on the screen by just having a simple rectangle with an image with transparency on it. Transparency is generally stored in the alpha channel, so the quality of the alpha channel is an important factor in 2D games.



The most basic and highest quality texture format is a simple RGBA32 with 8 bits per colour channel. In total each pixel then uses 4 bytes, or 3 bytes if there is no alpha channel. These can be stored in various file formats, like TGA and BMP, but in the end in the videocard it's all the same. At Ronimo we use TGA for these. This image format is lossless: whatever your original image was, you get exactly that in the game. Note that compressed TGA isn't supported by videocards, so when using TGA you will need to use its uncompressed 32 bit or 24 bit format (depending on whether you have alpha).



The big downside of this format is that it's huge. A 1024x1024 texture with alpha is already 4mb this way. Awesomenauts characters have a texture of nearly 4096x4096, containing all their animation frames. With simple RGBA, this would amount to a whopping 64mb of texture space for just a single character texture! This results in a simple conclusion: we need something smaller for the vast majority of our art. Even when you have several gigabytes of texture space available, full RGBA32 will fill it up really quickly. At Ronimo we only use TGA for images that are small and would lose too much quality when compressed. In practice this means we only use TGA for gradients.



One approach to reducing texture size is to use vector art and render that directly. This means you hardly need to use any textures at all since most colour and shape are defined by polygons instead of by a texture. It also means that artists need to use special vector tools like Illustrator and Flash. This is extremely limiting: more painterly styles are practically impossible this way. It also uses way more performance because in-game animation isn't simply swapping an image frame any more. Rendering vector art in real-time is a relatively complex and performance-heavy task.

Since vector tools are so limiting and since rendering vectors is a lot of work to program and much slower than textures, we don't use vector art in-game at all at Ronimo. We sometimes use vector tools when specific images are most easily made that way, but by the time they get to the game we always save the result as simple textures. Depending on your art style vectors might be a great option though!



A common suggestion from artists when discussing texture formats is to use JPG or PNG. These formats are excellent at achieving small image size with little visible loss. However, they aren't suitable for real-time games: videocards don't support these texture formats at all. That means that a texture that is stored on disk as JPG or PNG needs to be converted to something else to go into video memory, often growing the texture to the size of an uncompressed TGA. An important goal in choosing a texture format is to reduce the usage of video memory (usually to be able to store even more art there). Since JPG and PNG cannot be stored in video memory, they don't help there at all.



This doesn't mean these formats are entirely useless. In a game where the size on disk is most important you can use JPG for all the textures and then simply put them in the much larger RGB24 format in video memory. A game that famously did something like this is Rage (one of my favourite games of the past years). Rage needs to constantly stream in new textures, so the speed of reading from disk was a problem. To solve this they stored the files in a JPG-like format on disk, loaded that into memory, and then converted it in real-time to DXT to be used by the game. Such hardcore streaming tech is generally not necessary for 2D games though.

Videocards can only handle a very limited set of texture types. The three main approaches to reducing texture size without simply reducing their resolution are to use less bit-depth, to use palettes or to use the DXT format. Note that specific types of hardware might offer additional formats, so it can really pay off to look into the details of whatever platform you are developing for. Palettes and DXT will be separate blog posts, so let's look into reducing bit-depth now.

Using less bit-depth is the simplest approach to texture compression. For example, you can use a 16 bit format. Instead of using 8 bits per channel for RGB, you might use 5 bits for red, 6 for green and 5 for blue. Such an R5G6B5 format is 33% smaller than uncompressed 24bit RGB. It also means less colour depth, so especially gradients will look visibly worse. The difference is quite small though so for most textures this loss in quality is hardly noticeable and totally acceptable. The reason green is 6 bits while red and blue are 5 bits is that 16 doesn't divide by 3 equally. Human eyes are better at seeing in the green spectrum, so the extra bit is put in the channel where it matters most.



If you need alpha there's often something like R5G5B5A1 available, which also uses only 16 bits per pixel, but at slightly greater compression costs. This specific format has only 1 bit for alpha, so pixels are either fully transparent or fully opaque. This not only means that partially transparent pixels aren't possible, but also that anti-aliasing on the image's edges is entirely lost. In 2D games anti-aliasing is usually part of the original art and stored in the texture. Losing this can be pretty bad for image quality, so I generally wouldn't advice using formats with only 1 bit for alpha. There are also other combinations, like R4G4B4A4, giving better alpha but significantly worse colours. If you hate your own game you can even use R2G3B3.



Videocards support many different combinations of bitrates per channel so it's useful to have a look and figure out what works for your purpose. Specifically interesting is L8A8: this is a greyscale texture (L for “luminance”) with high quality alpha. This is 50% smaller than full R8G8B8A8. If the original image is already greyscale this format doesn't result in any quality loss. If you happen to be making a game with many monochrome textures, this might be a relevant option. If you don't need alpha you can half the size again by using L8.

In our own games none of the formats discussed so far are used extensively. We use a little bit of R8G8B8A8 through TGA files for gradients, and L8A8 for fonts. The vast majority of our textures is DXT5, which I will discuss in part 3 of this short series. Next week I will first look into the format we used for Swords & Soldiers 1 on Nintendo Wii: palette textures. This format is often overlooked and usually quite a hassle to use, but for certain art styles it delivers an excellent combination of small textures with little quality loss, as I'll show next week.

See also:
-Texture formats for 2D games, part 2: Palettes
-Texture formats for 2D games, part 3: DXT and PVRTC
-Texture formats for 2D games, part 4: Overview