{"id":103,"date":"2014-12-11T18:50:17","date_gmt":"2014-12-11T10:50:17","guid":{"rendered":"http:\/\/www.zhuyanbin.com\/?p=103"},"modified":"2014-12-18T23:37:46","modified_gmt":"2014-12-18T15:37:46","slug":"stage3d-compressed-textures-introducing-the-atf-sdk","status":"publish","type":"post","link":"https:\/\/www.yanbin888.com\/?p=103","title":{"rendered":"Stage3D compressed textures \u2013 Introducing the ATF SDK"},"content":{"rendered":"

We introduced Stage3D last year and the momentum behind has never stopped growing but there is one area we did not give all the details. The ATF file format, it is mentioned here and there, so what’s up with this?\u00a0Some of you may have seen it in the documentation for Stage3D referred as the compressed texture file format, but we never shared any tools to create those famous ATF textures.<\/p>\n

Before we package the ATF tools with the AIR SDK,\u00a0I am happy to share here in advance the ATF tools so that you guys can start leveraging the ATF format now!<\/p>\n

So what is it?<\/strong><\/p>\n

First, let’s start by talking about what compressed textures are.<\/p>\n

When doing GPU programming with any technology,\u00a0you have two options for how you handle your textures. You can go compressed or uncompressed, very simple. So, what is the difference?<\/p>\n

\n
    \n
  1. When using uncompressed textures, a good old uncompressed file format like PNG is used and uploaded to the GPU.<\/li>\n
  2. Because GPUs don’t support such a file format natively, your texture is actually stored in CPU memory, when it could actually be stored on the GPU memory!<\/li>\n
  3. Same thing applies for JPEG images, make no mistake, graphics chipsets don’t know anything about JPEG which would also be decoded on CPU memory.<\/li>\n
  4. Of course, each platform has different support for compressed textures depending on the hardware chipset being used.<\/li>\n<\/ol>\n
    Now get ready for the fun!\u00a0Here is below a little table to illustrate it:<\/div>\n<\/div>\n\n\n\n\n\n\n\n\n\n\n\n
    Platform<\/th>\nFormat<\/th>\n<\/tr>\n<\/thead>\n
    ImgTech (iOS)<\/td>\nPVRTC<\/td>\n<\/tr>\n
    Qualcom (Android)<\/td>\nETC1<\/td>\n<\/tr>\n
    Mali (Android)<\/td>\nETC1<\/td>\n<\/tr>\n
    NVidia (Android)<\/td>\nETC1\/DXT1\/DXT5<\/td>\n<\/tr>\n
    Android (PowerVR)<\/td>\nPVRTC\/ETC1<\/td>\n<\/tr>\n
    Windows<\/td>\nDXT1\/DXT5<\/td>\n<\/tr>\n
    MacOS<\/td>\nDXT1\/DXT5<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

     <\/p>\n

    Why ATF?<\/strong><\/p>\n

    As you can imagine, if you would develop a game targeting iOS, Android and desktop, you would need to supply your textures compressed to each format for each platform. Which would look like this:<\/p>\n

      \n
    1. leaf.png encoded to DXT for Windows<\/strong> and MacOS<\/strong><\/li>\n
    2. leaf.png encoded to ETC1 or DXT for Android<\/strong> (Nvidia)<\/li>\n
    3. leaf.png encoded to PVRTC for iOS<\/strong> (ImgTech)<\/li>\n<\/ol>\n

      Of course it is a pain to provide all the different versions of the textures, detect at runtime which platform you are running on and upload the corresponding texture. Wouldn’t it be cool if you could just rely on one single container, that would wrap all the textures for each platform and Flash Player or AIR would extract\u00a0automatically\u00a0the texture required depending on the platform? So here comes ATF.<\/p>\n

      The ATF internals<\/strong><\/p>\n

      Really, think about the ATF format as a container for lossy images. Here is below a little figure showing very sinply the structure of a default compressed ATF file:<\/p>\n

      \"01\"<\/a><\/p>\n

      By default, all textures format (PVRTC (4bpp), ETC1, and DXT1\/5) are embedded in the ATF file so that for each platform, AIR or Flash Player automatically extracts the appropriate texture. But in some cases, you may want to target mobile only and why should you embed desktop related textures or Android if you are targeting iOS only? To cover this, you can also embed the PVRTC textures only inside the ATF file, making your assets smaller.<\/p>\n

      The figure below illustrate the idea:<\/p>\n

      \"02\"<\/a><\/p>\n

      As you can imagine, the same applies to ETC1 if you are targeting Android:<\/p>\n

      \"03\"<\/a><\/p>\n

      If you know about ETC1, you may wonder how we handle transparency then? We use a dual ETC1 approach with two textures, one for the alpha channel and one for the colors.<\/p>\n

      And finally on desktop only, where only the DXT texture can be provided:<\/p>\n

      \"04\"<\/a><\/p>\n

      The difference between DXT1 and DXT5 resides in alpha support. DXT1 does not support transparency, DXT5 does. Automatically the ATF tools will detect if your images have transparency and select the proper DXT version for you. Also note that ATF is not alpha pre-multiplied.<\/p>\n

      Now, if you want to store uncompressed textures inside an ATF file, you can also do that:<\/p>\n

      \"05\"<\/a><\/p>\n

      Why would you do that you may ask? Well, you may want to use uncompressed textures but still want to leverage cubemap, automatic mipmap support or even texture streaming.<\/p>\n

      Ok, now apart from the fact that hardware requires those textures to be compressed, what is the value for your content?<\/p>\n

      Yes, what does it bring you?<\/strong><\/p>\n