0
\$\begingroup\$

I wanted to support etc1, because it shoul improve the performance and loading times, but somehow its worse than using normal png files.

I'm using Mali compression tool with seperate RBG pkm texture and Alpha pkm texture. I'm using a GLSL shader to deal with the alpha problem ofc ETC1. With the shader the performance is really bad. but even without the shader, just working with the RGB pkm file (where transparency is black) the performance is equal to png. does anyone know what the problem might be?

\$\endgroup\$
  • \$\begingroup\$ I could say that using ETC1 or any other compression will surely improve your memory usage but will NOT improve your CPU/GPU usage. See uncompressed file formats can be used without any additional processing whereas compressed ones must be decompressed (processing impact) first. If you would reuse (and not load up every time) those textures would act just as any others (inside memory they are all decoded and in raw RGBA form). \$\endgroup\$ – avuthless Jul 17 '15 at 12:19
  • \$\begingroup\$ so it wont improve my fps rate? found this article for etc1 performance link \$\endgroup\$ – jeromintus Jul 17 '15 at 12:22
  • \$\begingroup\$ I am getting 404 with that link. FPS could be improved by reducing work on your GPU (like reducing rendered polygon count, using less/more simple shaders, using less draw calls (most important)). But changing the way your textures are stored will have impact only on: build size (storage), GPU/CPU load on decompression. I may be wrong in some cases, but compression is used mainly for reducing memory footprint and has nothing (very little) to do with your fps. \$\endgroup\$ – avuthless Jul 17 '15 at 12:25
  • \$\begingroup\$ brokenteapotstudios.com/android-game-development-blog/2011/06/… so with etc1 it just reduces the load time and the RAM usage?, the articles say it should reduce the FPS too \$\endgroup\$ – jeromintus Jul 17 '15 at 12:27
  • \$\begingroup\$ From your link i could say, that the OP in that link had issues with memory loading bottleneck. He found out that it is much faster to load smaller files and decompress them on the fly than loading bigger files from start. This once again adds load on GPU/CPU but decreases bandwidth needed to transfer files from disk to memory. In modern devices this should not be the case. Mind you that your link is 4 years old at least. \$\endgroup\$ – avuthless Jul 17 '15 at 12:32
2
\$\begingroup\$

I could say that using ETC1 or any other compression will surely improve your memory usage but will NOT improve your CPU/GPU usage. See uncompressed file formats can be used without any additional processing whereas compressed ones must be decompressed (processing impact) first. If you would reuse (and not load up every time) those textures would act just as any others (inside memory they are all raw in RGBA form).

FPS could be improved by reducing work on your GPU (like reducing rendered polygon count, using less/more simple shaders, using less draw calls (most important)). But changing the way your textures are stored will have impact only on: build size (storage), GPU/CPU load on decompression. I may be wrong in some cases, but compression is used mainly for reducing memory footprint and has nothing (very little) to do with your fps.

And remember kids: Early optimization is root to all evil!

Edit 1: Also bear in mind that using any kind of compression method does not come free. The space saved is not magic! You will lose quality. More space you save - more distorted images you will have. It is a general rule to not use any kind of compression for UI elements if they must be pixel-perfect or contain text.

\$\endgroup\$
  • \$\begingroup\$ so its actually possible to get less fps with ETC1 support? because to support it i have to use a shader on each texture to deal with the alpha \$\endgroup\$ – jeromintus Jul 17 '15 at 12:38
  • \$\begingroup\$ In your case, the answer is YES. On the other hand, if your HDD would not be fast enough to load all the textures in png, using compressed ones (but sacrificing CPU/GPU) would help out. Note: I am always using CPU/GPU since more and more devices (especially mobile ones) have both processors (or one universal) in one chip. \$\endgroup\$ – avuthless Jul 17 '15 at 12:42
  • \$\begingroup\$ Also a small note: Alpha channel is expensive. Every object that is standing behind alpha will be rendered twice. Just some basic old school facts. \$\endgroup\$ – avuthless Jul 17 '15 at 12:43
  • \$\begingroup\$ but what about the extra alpha texture? isn't it as expensive as having a alpha channel? so what do you recommend, etc1 or png \$\endgroup\$ – jeromintus Jul 17 '15 at 12:46
  • \$\begingroup\$ Is RAM usage a problem for you? Will using .png (and therefore having bigger build) will be a big issue for you? If you answer NO - then use png and save your valuable time on something worth optimizing. All those texture compression techniques are mostly used on mobile devices since they have very limited hard drive space and distribution of your build is easier if your build is smaller. \$\endgroup\$ – avuthless Jul 17 '15 at 12:49
0
\$\begingroup\$

The answer to your question rather depends on what the bottleneck is in your renderer.

If your system is bandwidth limited because of, say, many texture reads, then texture compression should help but, as you point out, ETC1 is opaque-only and so to emulate transparency, you need to set up a second texture with R=G=B*=A* and then copy one of the channels back to A in a shader.

If, OTOH, your system is shader limited, which may be the case here, the extra instructions will possibly make things worse.

You probably already know this but no rendering hardware (that I know of) reads PNG files, and these so are typically converted to 32bpp (or 16bpp) RGBA.

Other possible options would be to

  1. identify if the hardware supports a different compressed texture format that includes alpha, eg. DXTC/S3TC or PVRTC or
  2. identify all the textures (or portions of textures if you have atlases) where alpha==255 and explicitly handle them as opaque. This will give additional rendering speed benefits anyway.
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.