Texture Compression

[Rockthesmurf]

Hi there,

Up until now, I have been using .png graphics in my engine, either 8bit palettised ones, or full 32bit RGBA ones. On load these get unpacked to a R8G8B8A8 texture and sent off to OpenGL - there are a few exceptions, but these can be ignored for now. One of the reasons for doing this is for simplicity, but now the time has come that I am looking to squeeze out more performance, and am interested in utilizing various texture compression schemes that different hardware can support. Interestingly, I am finding there is not as much information on this subject as I hoped. I currently target Pandora, iPhone and Android, having a fixed specification for Pandora/iPhone is a nice luxury, Android on the other hand seems to support various compression schemes based on the device, doh! The formats I have seen listed so far are:

Pandora/Droid (latest Android handset, from Motorola)

GL_OES_compressed_paletted_texture
GL_OES_draw_texture
GL_OES_compressed_ETC1_RGB8_texture
GL_IMG_texture_compression_pvrtc
GL_IMG_texture_format_BGRA8888
GL_EXT_texture_format_BGRA8888
GL_IMG_texture_stream

IPhone - maybe more than listed here

GL_OES_compressed_paletted_texture
GL_OES_draw_texture
GL_IMG_texture_compression_pvrtc
GL_IMG_texture_format_BGRA8888

G1/MyHero/Touch (older, but quite common handsets)

GL_ATI_texture_compression_atitc
GL_OES_compressed_paletted_texture
GL_OES_draw_texture
GL_QUALCOMM_direct_texture

Android Emulator (not too important, just here as reference)

GL_OES_compressed_paletted_texture
GL_OES_draw_texture
GL_ARB_texture_compression
GL_ANDROID_direct_texture

In a perfect world (from my point of view), I'd be able to use a common texture format for all platforms - the two common format that appears in the above list are GL_OES_draw_texture and GL_OES_compressed_paletted_texture. The first appears to more or less copy a texture (or region of texture) from a source texture to the back buffer - it doesn't seem to cater for alpha blending/z testing, so other than my background, I don't think it is of use for my particular requirements, which is a shame, as some Android documents say this method provides the best performance for a lot of Android devices. The compressed palleted texture sounds a bit more interesting, although I am not sure if it offers improved performance. I appreciate it takes up less memory, but I have heard that it is slow as you have to do two lookups per texel read (one for the palette and one for the actual data). I am currently pixel bound on all platforms, so while saving memory is always nice, what I am really after is a way to improve performance. It seems on more modern devices, GL_IMG_texture_compression_pvrtc is a good format to go for, if you can put up with the compression artifacts (which vary from almost perfect, to pretty nasty). Although one thing I am not clear about, is the GPU technical documents (for Pandora/Droid) state the supported formats are: Compressed textures PVR-TC1, PVR-TC2, ETC1 - but as of yet the texture compression tools I have found will compress to PVRTC 2BPP or PVRTC 4BPP, but they don't specify if that is PVR-TC1 or PVR-TC2.

After a fair bit of Googling, I have not been able to come up with much information regarding the ATITC compression format, I have heard that The Compressonator (ATI/AMD tool) can compress to this format, but I'm not entirely sure what settings are required to do this, or how to read the data back on the device.

Does anyone have any information relating to the above? I know this post is a bit of a ramble, speaking of various devices/compressions and so on, but essentially I am just trying to find out if there is a good resource that explains all these various formats, and shows their relative performance/memory foot print, or if anyone has any input as to what the best format(s) would be for me to use on various devices? I just want to be able to draw as much as possible before getting pixel bound! It isn't a problem for me to have unique textures for iPhone/Pandora, but having unique textures for different Android devices is a bit much, as at that point I wouldn't be able to bundle all my assets in with the application (it would be too big), and instead I would have to have a downloader built in to the application to download the 'best' textures for your specific platform, I don't really like the idea of this as it adds a lot of complications.

Any help will be much appreciated,

Steve

 

[Adventus]

Have you considered using 16bit textures (RGB565, RGBA5551 or RGBA4444)? They should be supported on all OpenGL ES implementations. Most displays cannot really show 24 bits of color variation, so you don't really lose anything. Performance-wise i think PVRTC is the clear winner, 16x/8x memory gain and it's decompressed in hardware after the texture cache.

The extension registry is a good resource, for the IMGtech stuff anyway (it seems to be missing the ATITC and Qualcomm strings): http://www.khronos.org/registry/gles/

 

[Rockthesmurf]

Firstly thanks for your reply. I have considered 16 bit textures in as far as I can see they would be a win over my current setup, but haven't looked any further, as they didn't seem to be as good as some of the other methods. I am almost certainly going to keep R8G8B8A8 support, as I find there are occasions where I really don't want any compression artifacts, but in general I guess I could default to using RGBA5551 for textures that don't have any real translucency but do require on/off, RGBA4444 for textures that need translucency, and RGB565 for textures with no alpha requirements (but as I say, only my background really meets this criteria).

I know when I compressed all the textures for my last game from 32bit PNG down to 8bit PNG there were a lot of cases that didn't look very nice (mainly for full screen sprites that have a lot of gradients in them), so it will be interesting to see how various other 16 bit modes compare.

On top of that, I can provide PVRTC support for iPhone/Pandora - I'm not sure what the best method will be for selecting the compression scheme though, one option would be for the guy that does the art to be educated about what the various formats strengths/weaknesses are, and let him choose which method to use (obviously allowing him to view the results too). But this could be a problem for anything he uses PVRTC for, as that isn't available on all platforms, so it would either have to automatically fall back to a suitable 16 bit mode, or force him to save out multiple files. I wonder if there are any program that will walk through a bunch of textures and compress them in the 'best' way (based on some user parameters, such as allowed formats, allowed difference tolerance, etc). These feel like quite 'real world' problems, but I guess they might not be so prevalant for small indie games that don't have too many graphics etc.

Thanks for the help so far, if anyone has any mode to add please feel free to, especially regarding ATITC/GL_OES_compressed_paletted_texture as they seem to be two possible candidates for non PVRTC compatible devices.

Steve

 

[warmi]

Given that 80% of all portable devices (phones etc) contains Imagination Technologies's hardware (MBX,SGX), I would go with:

1. PVRTC for everything that looks decent after compression
2. R8G8B8A8/RGB565 for stuff that cannot handle compression well.
3. I8/A8 for special stuff like font textures/lightmaps

GL_OES_compressed_paletted_texture doesn't buy you anything as , according to Img tech folks, images of this type are uncompressed internally into RGBA.

 

[Rockthesmurf]

Given that 80% of all portable devices (phones etc) contains Imagination Technologies's hardware (MBX,SGX), I would go with:

1. PVRTC for everything that looks decent after compression
2. R8G8B8A8/RGB565 for stuff that cannot handle compression well.
3. I8/A8 for special stuff like font textures/lightmaps

GL_OES_compressed_paletted_texture doesn't buy you anything as , according to Img tech folks, images of this type are uncompressed internally into RGBA.

Thanks, a lot of Android devices actually don't support PVRTC, they instead support the ATI/AMD compression system (ATC) or the Erricson compression system (ETC), but I think I have worked out how to create/load these file types too. I still haven't quite worked out how I am going to handle it yet, but it did strike me that I can uncompress PVRTC textures, so I could use them as standard (where possible), and on devices that don't support this uncompress them on the fly - this does still have the problem that a lot of Android devices wouldn't have any texture compression benefit (and typically these are the devices that need it the most).

I'll have a little more of a think - thanks for the heads up about the compressed palette texture stuff, I'll avoid that now!

Steve

 

[andys]

Given that 80% of all portable devices (phones etc) contains Imagination Technologies's hardware (MBX,SGX), I would go with:

1. PVRTC for everything that looks decent after compression
2. R8G8B8A8/RGB565 for stuff that cannot handle compression well.
3. I8/A8 for special stuff like font textures/lightmaps

GL_OES_compressed_paletted_texture doesn't buy you anything as , according to Img tech folks, images of this type are uncompressed internally into RGBA.

Thanks, a lot of Android devices actually don't support PVRTC, they instead support the ATI/AMD compression system (ATC) or the Erricson compression system (ETC), but I think I have worked out how to create/load these file types too. I still haven't quite worked out how I am going to handle it yet, but it did strike me that I can uncompress PVRTC textures, so I could use them as standard (where possible), and on devices that don't support this uncompress them on the fly - this does still have the problem that a lot of Android devices wouldn't have any texture compression benefit (and typically these are the devices that need it the most).

I'll have a little more of a think - thanks for the heads up about the compressed palette texture stuff, I'll avoid that now!

Steve

While not ideal, all GLES2 devices support ETC1 I believe.

Obviously sometimes it will do better than PVRTC (and sometimes worse), but it might be worth using that as a standard compression format if it's a GLES2 capable device, and using PVRTC if it's not.

To be honest, I fear that supporting different systems will require that you have multiple different texture packs anyway.

 

[warmi]

Given that 80% of all portable devices (phones etc) contains Imagination Technologies's hardware (MBX,SGX), I would go with:

1. PVRTC for everything that looks decent after compression
2. R8G8B8A8/RGB565 for stuff that cannot handle compression well.
3. I8/A8 for special stuff like font textures/lightmaps

GL_OES_compressed_paletted_texture doesn't buy you anything as , according to Img tech folks, images of this type are uncompressed internally into RGBA.

Thanks, a lot of Android devices actually don't support PVRTC, they instead support the ATI/AMD compression system (ATC) or the Erricson compression system (ETC), but I think I have worked out how to create/load these file types too. I still haven't quite worked out how I am going to handle it yet, but it did strike me that I can uncompress PVRTC textures, so I could use them as standard (where possible), and on devices that don't support this uncompress them on the fly - this does still have the problem that a lot of Android devices wouldn't have any texture compression benefit (and typically these are the devices that need it the most).

I'll have a little more of a think - thanks for the heads up about the compressed palette texture stuff, I'll avoid that now!

Steve

On an unrelated note, I am wondering how are you handling the fact that Android is Java based while other devices (like iPhone or Pandora) are C/C++ based ?

 

[Rockthesmurf]

On an unrelated note, I am wondering how are you handling the fact that Android is Java based while other devices (like iPhone or Pandora) are C/C++ based ?

Android have released an official native development kit (NDK), so I have just cross compiled my C++ engine + games to Android (ARM), and my Java code looks similar to:

void OnJavaCreateOpenGLSurface( )
{
nativeInit( );
}
void OnJavaSurfaceDraw( )
{
nativeDraw( );
}

And my C++ code just picks up these two native functions and calls my game initialise and 'tick' functions (these are the only two functions my engine/games need to have called to function.

Steve

 

[Rockthesmurf]

Also, I should mentioned, I decided to have texture packs for Android, so I've got a downloader built in now that will download a texture pack (potentially) specific for any device/support texture combination, to the SD card. It was reasonable straight forward to do, as Google provided a sample that does most of what I need.

Steve