I would always encourage use of the common features, so as to maximize compatibility across devices, so I'd recommend your using GL_OES_compressed_paletted_texture.
Also, while GL_OES_draw_texture is fast, if you need to render many sprites, then using this extension you'd need multiple calls to OpenGL ES to render them all, and that may cost you more than you gain. We have a fledgling OpenGL ES wrapper library at http://code.google.com/p/skylight1 that can help you to render multiple sprites in a single call to OpenGL ES. We haven't checked in the example code projects, but let me know if you are interested and we can prioritize it. On Dec 28, 5:59 am, Steve <[email protected]> wrote: > 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...... > > > 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
