We realized it takes ages to load (well... 10 seconds!) but we want it faster. We had one unique texture atlas with PNG (2048x2048), fully crowded with everything....
In order to be able to expand our app later on we have decided to split it in 3 atlases (same contents for now)
- 1 PNG (1024x2048)
- 1 PNG (1024x1024)
- 1 ATF (1024x2048)
We compressed out PNG to ATF with:
png2atf.exe -c e -e -q 10 -4
And here are the results:
1 big PNG:
Loading time: 9-10 seconds.
VRAM used (right after loading) 3 PNGS: 31Mb
3 PNGs:
Loading time: 9-10 seconds.
VRAM used (right after loading) 3 PNGS: 37Mb
2 PNGs + 1 ATF:
Loading time: 8-9 seconds.
VRAM used (right after loading) 2 PNGS + 1 ATF: 29Mb
We couldn't speed up the load unless we had some textures loaded AFTER the app started. But this was just an experiment where we forced the program to load everything at start.
We used ATFs in Beekyr (a ton of textures there!) and it was a lot more noticeable as there are a lot of ATFs in the game.
UPDATE:
I tried adding the -r argument and it makes a difference:
It generates very light ATF files that get loaded really fast when we execute the apps. But the images can look very blocky... To avoid this blockyness you need to remove the -q parameter:
png2atf.exe -c e -e -r -4
One thing that doesnt make a difference is when we pack the app into APK it doesnt make much of a difference in file space as APK is a compressed format.
I hope this can be useful for somebody!
2 comments:
you forgot one of the most useful switches of png2atf: -r
it does the real stuff: compresses in the 3D card native format
expect up to 10x better load times and VRAM usage, but there's a loss in quality
a good post about all this:
http://treefortress.com/tutorial-compressed-textures-in-air-atf-format/
Thanks for the tip.
-r:
Makes the app to load a lot faster indeed.
But in terms VRAM is takes the same. It is just helps the app dealing with the image not having to convert it to GPU format.
Thanks for your tip. I will be using it my future releases.
Post a Comment