App Thinning / Texture Atlas Clarification

Graphics & Games SpriteKit SpriteKit

Created Sep ’15

Replies 24

Boosts 0

Views 3.8k

Participants 7

Hello, I am trying to understand how app thinning and texture atlases work together regarding optimizing images. The underlying question is related to the inclusion of texture atlases in "Thinned" applications.

I understand that your images are selectively included using the .xcassets catalog, but it is unclear as to how that works with regards to texture atlases. What structure should be used when creating a iOS 9 compliant "thinned" app, which includes texture atlases?

In the past, I have created .atlas folders for both @1x and @2x graphics, and included the appropriate graphics in code, depending on the multiplication factor. In that case, does app thinning still execute on graphics within those seperate atlas folders? What is the recommended way to support @1, @2, and @3 graphics in a forward compatible way, honoring app thinning, while using texture atlases?

Finally, seeing as you can create texture atlases at runtime, is that recommended? I could see an environment where the images are stored in an Asset catalog, (getting "thinned" on installation), and then on-device compilation into a texture atlas upon the first app initialization. But in that case - testing is sure to be impossible.

Thanks for any insight related to this topic.

Cheers,

keny

Boost

deeeds OP

Oct ’15

The most annoying part is that this is the bit Sprite Kit should get the most right.

Not just because of the name of the framework, but because they continually tout this auto-packaging as wonderful consideration of users.

With their new-fangled-but-always-broken packaging they're (seemingly) trying to reinvent a wheel that's existed from the beginning of 2D game development, and unncessary.

The least of anyone's problems in 2D game development is packaging art assets -- there's dozens of tools to do it, and it's not rocket science.

greven OP

Oct ’15

Hi Karim,

A sprite atlas in an asset catalog is as you point out a new feature of asset cataloges. This is an entirely different path compared to the classic .plist and .png atlas combinations. If you find the asset catalog is causing issues a recommendation would be to go back to using discrete .atlas folders in the project, outside the asset catalog. You can always inspect the packed atlas .png in the build intermediates, look for folders named .atlasc .

We very much appreciate feedback and any radars you can share with us. Moving your atlasses to a catalog is not a requirement but it may help you with app thinning if you application is large.

Cheers

greven OP

Oct ’15

Hi snowkid,

Thanks for reaching out.

Are you using classic .atlas folders or the new Sprite Atlas items in asset catalogs? We have a helper doc explaining texture atlases and their generation in Xcode here https://developer.apple.com/library/ios/recipes/xcode_help-texture_atlas/AboutTextureAtlases/AboutTextureAtlases.html

You can inspect the packed files in the .atlasc folders to see if they are as you expect.

Cheers

snowkid OP

Oct ’15

greven - thanks for your response. considering that the texture atlas document you provided makes no reference to app thinning I am assuming that texture atlases are not supported by the new app thinning protocol.

karim OP

Oct ’15

"Classic" Texture Atlasses (.atlas folders) are not supported in App-thinning.

If you want to take advantage of App-thinning (and On-Demand-Resources) you have to use the new Asset-Catalog-based Atlases, which I described above, because the system needs a way to identify the assets by resolution, and there needs to be a way to tag the assets for ODR, both of which the Asset Catalog schema provides.

Snowkid: I have no reason to believe that Asset-Catalog-based Atlases don't result in generated atlases, but can't strictly prove that they do because the resulting generated assets are archived in an opaque file within the compiled App bundle. They certainly seem to work exactly the same as the "classic" .atlas folders. As I said in my post above, I didn't have to change any of my code (ie: let atlas = SKTextureAtlas(named:"my-atlas") ), so SpriteKit at least thinks they're exactly the same manner of beast.

karim OP

Oct ’15

Greven:

I'm not really having any problems with the new asset-catalog-based atlases. I was just responding to snowkid's question. It all seems to be working fine for me, but I don't have any requirement to inspect the resulting atlases, which he seems to want to do.

snowkid OP

Oct ’15

I hear what you are saying but it's an assumption. Maybe it is, Maybe it isn't... I requested documentation that clarifies this in my enhancement request...

Further, getting into using the actual texture atlases, the consideration of memory management becomes important and there is nothing documenting that either, e.g. does sprite kit instantiate multiple copies of the same atlas when you refer to the same atlas in different scenes? On my previous app I have a TextureManager class where it stores the current atlases in an array and passes them to the requesting scene in order to prevent multiple instances of them, which has been very necessary since the beginning of SpriteKit.

archdanny OP

Oct ’15

Hi I'm having the same problem.

I would like to know if the usage of a texture manager class will improve memory management Apple guru's.

snowkid OP

Oct ’15

you pretty much need to watch allocations in intstruments to realize what is happening with your app. I found that using a shared instance to retrieve atlas references had a big improvement on this.

...

without a code example, pretty much what you do is:

implement a shared instance

implement a public getAtlases function that loads selected atlases (or not if they are already loaded)

implement a protocol which contains a callback that returns an array of texture atlases (use preloadTextureAtlases:iAPTextureAtlases withCompletionHandler)