Ideally yes, but there are conditions to that.
The ATF container supports multiple GPU texture compression formats, even simultaneously.
- DXT1/5 (S3 Texture Compression) - Used by desktop operating systems (Windows, Mac OS, Linux) and some mobile phones. DXT1 has 1-bit alpha, where as DXT5 supports full alpha. Whether you use DXT1 or DXT5 depends on your alpha needs.
- ETC1 (Ericsson Texture Compression) - Used by mobile phones, most notably Android. Has no alpha.
- ETC2 (Ericsson Texture Compression) - Higher quality than ETC1 and supports alpha. Used by Android and iOS mobile phones. Google claims >95% mobile support for Google Play devices.
- PVRTC (PowerVR Texture Compression) - Supported by all generations of iPhone and iPad.
If you’ve created an ATF that contains DXT only, such as:
Then one should only expect that to work reliably on a desktop system.
The other caveat, is what the target platform supports itself, and browsers critically add another level of support (or lack of) to this caveat. When a new texture is created in OpenFL, the runtime environment is queried for what extensions it supports (DXT1, DXT5, ETC1, PVRTC, etc).
If your ATF contains multiple formats, it’ll upload the first supported format to the GPU (and none of the others). If I’m not mistaken, format priority is in this order (based on order here):
- DXT > PVRTC > ETC1 > ETC2
For example: If your ATF contains DXT1 and ETC1, and the target runtime supports both, only DXT1 is uploaded to the GPU. If the target runtime supports neither of those (perhaps an iPhone?), it’ll fail!
For desktop and mobile support from a single ATF, I’d suggest packaging at least DXT and ETC2.