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?

Improve this question
\$\endgroup\$
5
  • \$\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, 2015 at 12:19
  • \$\begingroup\$ so it wont improve my fps rate? found this article for etc1 performance link \$\endgroup\$
    – jeromintus
    Jul 17, 2015 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, 2015 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, 2015 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, 2015 at 12:32

2 Answers 2

Reset to default
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.

Improve this answer
\$\endgroup\$
9
  • \$\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, 2015 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, 2015 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, 2015 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, 2015 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, 2015 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.
Improve this answer
\$\endgroup\$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .