PVRTC with 4 bits per pixel, no transparency, (PVR file only, no real-time preview available) PVRTC with 2 bits per pixel, no transparency, (PVR file only, no real-time preview available) PVRTC with 4 bits per pixel, (PVR file only, no real-time preview available) PVRTC with 2 bits per pixel, (PVR file only, no real-time preview available) Textureĭefault, 4 bytes per pixel, 8 bits per channelĢ bytes per pixel, 5 bits per color channel, 1 bit transparencyģ bytes per pixel, 5 bits per channel, not supported on all platformsģ bytes per pixel, 8 bits per channel, no transparencyĢ bytes per pixel, 5 bits for red and blue, 6 bits for green, no transparency Sets the filtering values in the LibGDX exporter. (only available if Data Format is LibGDX) Header file -header-file Ĭhoose the file name for the header file containing definitions for the sprites and (only available if Data Format is SpriteKit)Ĭhoose the atlasc directory containing all data and image files. (only available if Data Format is MonoGame)Ĭhoose the file name for the classfile output file. This can be used to store the sprite sheet image in another location than the DataĮxample: /assets Class file -classfile-file

This value can be used to prepend a path before the file name of the texture in the Data

To disable this feature you can uncheck Auto-detect animations Texture path -texturepath TexturePacker would define an animation walk in the data file. TexturePacker automatically defines animations for sprites which have the same base name and onlyįor the sprites walk_001.png, walk_002.png, walk_003.png (only available for some frameworks like LibGDX, SpriteKit, Cocos2D-x)įor some frameworks it is possible to mark a group of sprites as animation in the data file. Sub-folder names are always included in the sprite name. Prepends the smart folder's name as part of the sprite name. Note that this has nothing to do with the Pixel Per Unit values on the sprite.Removes image file extensions from the sprite names - e.g.png. It would be super easy to add a scaling parameter in the SpriteAtlas directly and scale all the sprites with that value (plus our choice of scaling algorithm would be awesome). Rinse and repeat until you have found just the right scaling. It requires resizing the sprite in an external tool, then re-pack. In addition, the workflow to make the sprites are as big as possible to just fill a 2k atlas is horrendous. Going forward pretty much everyone will use SpriteAtlas so it would be nice to get a size improvement on this front. I have played with all the variable that I have access to to try to create smaller atlas with SpriteAtlas but to no avail. TexturePacker (MaxRect) generates images that are 30% smaller. On the UI atlas, with SpriteAtlas (padding=2, no rotation, no tightPacking) produces 3 images 2048x2048, 2048x2048 and 512x512. SpriteAtlas produces a 1024x1024 image while TexturePacker manages a 512x1024. However I think all the developers could use some better packing algorithms for those atlases.Īttached are the same sprites packed with the SpriteAtlas (allowRotation, tightPacking, padding=2) and TexturePacker (Polygon Outline). We recently upgraded a project to 2018.1 and great improvement to the workflow with the SpriteAtlas, well done.

Texturepacker polygon disabled