How to pack textures in libGDX?

Question

Android

I'm writing an Android game with libGDX and using TexturePacker ( https://www.codeandweb.com/texturepacker) to create atlases. There are quite a lot of graphics, so the question arose of how to pack textures in a less resource-intensive format than PNG / RGBA4444 (which I use now).
Googling, I understand that I need ETC1. TexturePacker can export to "PKM with ETC1" - just what you need. If such a file is archived and renamed to etc1, then libGDX will read it. BUT. The format itself implies that the images are saved in one etc file without an alpha channel, and the alpha channel is saved in another etc file. How to combine these 2 atlases in libGDX - I have no idea!
In gdx-tools ( https://libgdx.badlogicgames.com/tools.html)there is its own TexturePacker, but, as I understand from the documentation, it only exports to PNG. There is also a certain KTXProcessor, but I don’t understand where to get the binary, or how to create atlases.
So, how do you package textures in libGDX? Is there a guide for dummies?

Answer 1

Merge in shader. Without a shader, I don't know if it can be done.

Answer 2

Andrey, your question, as you can see from the text, is a bit about something else. The description shows that you see a wall in front of you, but you don’t even suspect about the door in the wall. So, here is the door, even a few. :)
First, you need to understand how much graphics you have in your project. For a modern mid-end device on Android 5.0, it is not at all a problem to keep 2-4 RGBA textures with a resolution of 4096 edge-to-edge. This is not to mention the accompanying shaders, bitmap/depth/vertex/index buffers. Minimalism in resources is welcome, but you shouldn't pinch yourself in a tesky either.
Second - let's take a look at the paragraph "Open GL Version" of the page https://developer.android.com/about/dashboards/ind...
OpenGL 3.x takes a large share of all devices. This version of OpenGL can work with the ETC2 format (thanks to the declared support from the GPU), in which alpha can already be saved. And the wiki ( https://en.wikipedia.org/wiki/Ericsson_Texture_Com... ) also says about backward compatibility.
There is a gap in my experience, I have not worked with ETC2 yet and clearly I don’t know anything about backward compatibility with ETC1. Therefore, I propose to arrange an exchange of knowledge in this topic. :)
Third, there are actually many hardware-supported texture compression formats: S3TC, ATC, PVR-TC. ETC is not the only one. Each of the formats is supported by its manufacturer. ATC - Quallcomm; PVR-TC - Imagination Tec. But S3TC (better known as DXT3/DXT5) is supported by both QC and ImgTec, but in secret. And only ARM Mali supports the ETC format alone.
Why am I doing this. The trio of profile formats also supports alpha, and is processed faster than the same ETC (and even more so a pair of ETC1).
Therefore, maybe it will be more convenient for you to use the conversion to this trio of formats?
I have a very fast library on github for programmatically reading PVR-TC.v2 into an RGBA buffer, which will allow loading textures for the Mali GPU.