I have heard that using palettised textures can actually have a negative impact on performance, due to the fact two lookup are needed per texel sampled (one to ascertain the lookup index, then another to use the look up index to get the full value) - does anyone know how much truth there is in this?
I am currently going through a bunch of texture extensions that are supported for various handsets, including: Droid, G1, MyTouch, Hero, Emulator and trying to find out what their compression/performance/etc is like. For now the list I am working on is: Droid 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 G1/MyHero/Touch GL_ATI_texture_compression_atitc GL_OES_compressed_paletted_texture GL_OES_draw_texture GL_QUALCOMM_direct_texture Emulator GL_OES_compressed_paletted_texture GL_OES_draw_texture GL_ARB_texture_compression GL_ANDROID_direct_texture So the two common ones seem to be GL_OES_compressed_paletted_texture and GL_OES_draw_texture. From what I understand, the draw_texture extension lets you basically copy a GL texture (or region of a GL texture) to the back buffer, at a given Z depth, but it doesn't allow for z testing, alpha blending, rotation, scaling, etc. although I haven't found any concrete information to this extent. Certainly if it doesn't support alpha blending/z testing the only sprite I would be able to use it for is the single background image. The documentation I have read indicates this is the fastest way of drawing textures, certainly on older handsets. The GL_OES_compressed_ETC1_RGB8_texture format is an Ericsson format, I believe it can be created with etcpack. From the name it sounds like it can store R8G8B8 compressed, so no alpha channel support - which is not very useful for me. The GL_IMG_texture_compression_pvrtc format is a bit more common, as it is used on iPhone and I believe the Beagleboard/Pandora also uses it. One thing that isn't so clear, is the GPU technical reference for Droid specifies the supported formats as: Compressed textures PVR-TC1, PVR-TC2, ETC1 - but I'm not entirely sure what this covers (i.e. does ETC1 just mean GL_OES_compressed_ETC1_RGB8 or are there other supported ETC1 formats, and similiarly for PVRTC). There is a PVR Tex Tool, which encodes to PVRTC 2BPP and PVRTC 4BPP, the 2/4 BPP indicates the bits per pixel, but it isn't clear if this is a 'PVR- TC1' or 'PVR-TC2' compression being used. I have read that using ATITC compression is a good idea for the majority of handsets (this was from an Android optimisation document from a while ago, so I'm not sure if it still holds true). This is presumably handled by this extension: GL_ATI_texture_compression_atitc but as of yet I am not sure how to create textures of this format, and whether or not they can have an alpha channel - although I've been hinted that The Compressonator can create these textures, I have a feeling the options 'ATC RGB' 'ATC RGBA (Explicit alpha)' and 'ATC RGBA (Interpolated alpha)' could be the ones to use - although I'm not sure how you read on the Android side. The compressonator also has an 'ETC RGB' option, which I am guessing *might* be the ETC mode above. That is as much as I know for now - thought I'd post my findings this far in case it helps anyone, and in case it sparks any further useful discussion! I'll also see if I can dig up anything else - it really feels like someone out there must have already worked all this stuff out though :o) Steve On Dec 28, 3:56 am, Lance Nanek <[email protected]> wrote: > Hmm, the OpenGL ES 1.0 spec says OES_compressed_paletted_texture is a > required extension in both Common and Common-Lite > profiles:https://www.khronos.org/registry/gles/specs/1.0/opengles_spec_1_0.pdf > > Looks like the method/constants are there > too:http://www.khronos.org/opengles/documentation/opengles1_0/html/glComp... > > http://developer.android.com/reference/android/opengl/GLES10.html#glC...http://developer.android.com/reference/android/opengl/GLES10.html#GL_... > > Haven't tried them myself, though. > > On Dec 27, 7:19 pm, Steve <[email protected]> wrote: > > > Hi there, > > > I am looking to improve performance of my OpenGL engine (for games), > > and something that has come up a few times is texturecompression, the > > problem is when it 'comes up' there only seems to be vague details - > > so I spent some time tonight trying to get to the bottom of it, and > > failed. So I hoped someone here might know more specifically: > > > What is the best texturecompressionformat to use for Android? It > > appears to me that this varies per device, with the main (only?) two > > being ATITC and PVRTC. I am able to dig up reasonable details on PVRTC > > (as it is used on iPhone), but as of yet I am yet to find out exactly > > how to create an ATITC texture and load it on Android (I've been lead > > towards 'The Compressonator' tool from ATI/AMD, but there is no > > 'ATITC'compressionoption). The method I have seen mentioned is some > > form of palletised textures, does anyone know if this is a feature > > supported on all Android implementations (guaranteed by the OpenGL:ES > > 1.0 spec) or once again, or just supported on certain devices? > > > I have been trying to keep things simple by having one package for my > > entire game, and have tried to keep it under 10 MB (which is hard, as > > it is a rather large game), but if in order to get best performance/ > > lowest memory foot print, I need to store the textures in multiple > > formats, I think I am going to be out of luck, and instead will need > > to investigate having a downloader built in to the game, to download a > > texture pack suitable for the device (which to me doesn't feel like a > > nice setup). Am I going to end up needing separate texture files, > > audio files, native libs, higher/lower resolution files, to support a > > good chunk of platforms? > > > So I guess in short I am hoping someone might be able to tell me what > >compressionmethod(s) are best to support, whether multiple methods > > should be supported (ideally), and what sort of performance/memory win > > can be had from implementing them. Finally some source code/links to > > tools to do all this would be handy. > > > Can anyone help? Has anyone actually managed to do any of this? > > > Steve -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
