In conventional Flash games, most developers use the PNG format for their textures, or JPG if they don't need transparency.
In Starling, you can use those as well, of course. Through stage3d, however, Starling can offer a great alternative to these formats: ATF textures. Compared to conventional file formats, they have several powerful advantages:
Before we go on, it might be interesting to know how much memory is required by a texture, anyway.
A PNG image stores 4 channels for every pixel: red, green, blue and alpha, each with 8 bit (that makes 256 values per channel). It's easy to calculate how much space a 512×512 pixel texture takes up:
Memory footprint of a 512x512 RGBA texture: 512 x 512 pixels x 4 bytes = 1,048,576 bytes = 1 MB
When you've got a JPG image, it's similar; you just spare the alpha channel.
Memory footprint of a 512x512 RGB texture: 512 x 512 pixels x 3 bytes = 786,432 bytes = 768 kB
Quite a lot for such a small texture, right? Beware that the built-in file compression of PNG and JPG does not help: the image has to be decompressed before stage3D can handle it. In other words: the file size does not matter; the memory consumption is always calculated by the above formula.
Nevertheless: if your textures fit into graphics memory that way — go ahead and use them! Those formats are very easy to work with and will be fine in many situations, especially if your game is targeting desktop hardware.
However, there might come a moment in the development of your game where your memory consumption is higher than what is available on the device (looking at you, iPad 1!). This is the right time to look at the ATF image format.
Above, we saw that the file size of a conventional texture has nothing to do with how much graphics memory it uses; a massively compressed JPG will take up just as much space as the same image in pure BMP format.
This is not true for compressed textures. Textures that are saved in such a format can be loaded directly by the GPU. Depending on the compression settings and the actual image data, this means that you can use up to ten times as many textures! Quite impressive, right?
Unfortunately, each GPU vendor thought he could do better than the others, and so there are several different formats for compressed textures. The problem: depending on where your game is running, it will need a different kind of texture. How should you know beforehand which file to include?
This where the ATF format comes to the rescue. It is a brand new file format that Adobe created especially for stage3D; actually, it is a container file that can include up to four different versions of a texture.
I said before that ATF is a container format. That means that it can include any combination of the the above formats.
When you include all formats (which is the default), the texture can be loaded on any stage3D-powered device, no matter if your game is running on iOS, Android, or on the Desktop. You don't have to care about the internals!
However, if you know that your game will only be deployed to, say, iOS devices, you can omit all formats excepts PVRTC. Or if you're only targeting high end mobile devices (with at least OpenGL ES 3), include only ETC2; that works on both Android and iOS. That way, you can optimize the download size of your game.
ETC1 actually does not support an alpha channel, but Stage3D works around this by using two textures internally. Again, this happens completely behind the scenes.
Adobe provides a set of command line tools to convert to and from ATF, and to display ATF files. Beginning with AIR 18, those tools are part of the AIR SDK.
Probably the most important tool is “png2atf”. Here's a basic usage example:
png2atf -c -i starling-atf.png -o starling.atf
This will compress the texture with the standard settings in all available formats. To see the result of the process, open the file in the “ATFViewer”:
In the list on the left, you can choose which internal format you want to view. Furthermore, you see that, per default, all required mipmaps have been created.
You can also see that the image quality has suffered a bit from the compression. This is because all those compression formats are lossy: the smaller memory footprint comes at the prize of a reduced quality. How much the quality suffers is depending on the type of image: while organic, photo-like textures work well, comic-like images with hard edges can suffer quite heavily.
The tool provides a lot of different options, of course. E.g. you can let it package only the PVRTC format, perfect for iOS:
png2atf -c p -i starling-atf.png -o starling.atf
Or you can tell it to omit mipmaps in order to save memory:
png2atf -c -n 0,0 -i starling-atf.png -o starling.atf
Using a compressed texture in Starling is just as simple as any other texture. Simply pass the byte array with the file contents to the factory method
With an embedded ATF file, it's even easier:
[Embed(source="starling.atf", mimeType="application/octet-stream")] public static const CompressedData:Class; var texture:Texture = Texture.fromEmbeddedAsset(CompressedData);
That's it! This texture can be used like any other texture in Starling. It's also a perfect candidate for your texture atlas.
As always, you need to create an
Image instance to display that texture:
var image:Image = new Image(texture); addChild(image);
If you get an exception when you want to create the ATF texture, you probably don't meet one of the following requirements:
For ETC2 support, which was added ATF version 3, there are updated requirements:
You can find out more information about this topic in the following sources:
Next section: Flattened Sprites