- Edited
Exporting multiple files into a minimum # of spritesheets
I'm currently working on a game that has a number of units that the player can spawn. At the moment, for each unit, I have a separate Spine file with a single skeleton in it (the units only move left/right, which we are using reflection to handle). These units have a number of skins and animations they use, and reference a single image directory containing only the images required for the skeleton in the file.
However, we're looking to optimize the amount of amount of memory taken up by the sprite sheets, as the performance of the game is suffering a bit when there are many units on the screen (which our developer blames on the many sprite sheets we're loading at once (although I'm not sure this is the true reason).
Thus, I'd like to minimize the number of sprite sheets we have. I'd like to specify a maximum size for the sheet and have the program export out multiple sheets, but pack the many units into as few sheets as possible (as opposed to what I have now after exporting out each unit's individual spine file alone, resulting in some files of 128x128, 256x256, I'd like to pack them all into as few 2048x2048)
Am I setting up my project incorrectly? Should I be including more than one skeleton in each file? Should my image directories be set up in a different way? Should I be using the 'include subdirectories' feature of exporting somehow? I tried looking for some documentation and in the forums for a breakdown of export options or workflow breakdowns, but I couldn't find anything too related.
Also, if this work to minimize the number of sprite sheets won't really affect the performance, are there any other options to explore in Spine that might?
Thanks!
Am I missing something very obvious here? Any input would be appreciated!
- Edited
Roughly how many units are we talking here?
Packing them in ONE 2048x2048 atlas would really help in terms of batching to minimize draw calls/texture binds.
But there's no guarantee that that's the cause of the slowdown. In fact, it's kind of unlikely, but it really depends on the situation.
There are other things like GPU-side fillrate and CPU-side processing that goes into animating each skeleton.
Anyway,
to allow them to share one atlas, you need to do a few things:
1) Make sure the images used by the different skeletons don't share the same filename.
1.1) If they share the same file names, you'll need to move them into their own folders. If you move them into their own folders, you'll need to fix the references to those files in your project using the Find and Replace tool (there's a magnifying glass button on top of the Tree panel) This may get a little involved if you have to do this. Feel free to ask questions on how it works.
2) Use Spine's Texture Packer. Open the Spine menu on the upper left and choose Texture Packer...
The input directory is the folder where you stored all your images.
The output directory is where you want to save the final atlases.
There's something about the Combine Subdirectories checkbox that I'm not sure of, whether it should be checked or unchecked. (Sorry.)
With this, you should end up with the fewest (hopefully one), png and one .atlas file.
Which runtime are you using, by the way?
Combine Subdirectories is described here, with the rest of the settings:
https://github.com/libgdx/libgdx/wiki/T ... r#settings
You normally get one atlas page for each directory you are packing, allowing you to easily control what gets packed together. Combine Subdirectories tries to pack everything on one page. Note when running via Texture Packer on the menu that pack.json files can be used to provide per directory settings. Eg, you can use this to have some directories use Combine Subdirectories and some not. See that link for more info.
Using many separate textures can definitely hurt your framerate. How many texture binds do you have per frame? Are you targeting mobile or desktop?
Thanks for the replies, guys!
After reading your replies and trying the Texture Packer directly (and not using the texture from the Export feature), I realize my issue was a very simple fix, since I can just pack the images first and refer to the resulting image.
We are using the cocos2d runtime. We're experiencing issues when there are about 20 or so units on the screen (which are composed of 8-22 bones/images depending on the unit) along with various other sprites/particle effects on an iPhone5. I don't believe the framerate drop is due to the number of spritesheet files we are using, but we shall see.
20 is not a lot. Especially in cocos, and on an iPhone5.
I wonder what's going on.
2 years later
I'd agree, that is a very small number to see frame drops.
We are using Cocos and Spine on iPhones and using far more active Spines on screen.
Your developer should use the Apple performance tools to isolate the issue, not guess and point fingers at spine 