TexturePacker Review: Absolutely Essential Software

After releasing five games in the iOS App Store, it’s hard for me to imagine just how I got along without using Corona’s built-in spritesheet support… that is, once I discovered TexturePacker by code”n”web.

When I worked on our original title, Doodle Dash (now Tilt Monster), I started coding the game with spritesheets, but I was running into some significant roadblocks (all of which are a result of Corona “Game Edition” being in alpha at that particular point in time):

  • Because the game didn’t have any levels and was on-going, after a random amount of time, the character’s sprite would stop animating and would get stuck on one of the frames. The only way to get the sprite animating again was to close out of the app and relaunch.

  • Actual creation of spritesheets was a tedious process, to say the least. On top of that, if any adjustments needed to be made to any of the frames, it added a whole new layer of complexity to the whole thing.

  • While there was external sprite-creation tools, Corona’s Sprite API (at the time) was very limited and didn’t support the formats and features that a lot of other tools incorporated into the spritesheets.

  • Implementation was a little confusing and still a little buggy at the time.

  • Once the iPhone 4 and iPod touch 4 came out, there was apparently no way to get spritesheets working with dynamic content scaling, and that was the deal-breaker for me (I hate the ‘blurry’ look of non-optimized games on 4th generation iOS devices).

Because of those issues, I decided to use a module called movieclip.lua for all of my animation needs because I felt, at the time, that it was really my only option because it could be modified to work with dynamic content scaling (for retina displays), and it wasn’t giving me the “freeze frame” issue I was experiencing with spritesheets.

Since then, all of the alpha-related issues above have been fixed and the Corona Sprite API has been vastly improved and expanded on (and is even compatible with retina displays now), but I was already used to using movieclips and everything seemed to be working fine so I just stuck with it.

Discovering TexturePacker

Recently, I was doing work for a client and they had a particular animation sequence where each frame took up a significant chunk of texture memory. It was bogging down the app and in many instances causing it to crash.

Someone had suggested I try using spritesheets, so that way only one image needs to load and the animation can be handled accordingly.

I was on an extremely tight schedule so I didn’t have time to create a spritesheet manually and also brush-up on the Corona Sprite API, so I asked about any recommended software that’ll help me with the process… and that’s when TexturePacker was brought to my attention.

I downloaded the Essential Version (free) and within minutes was able to create a spritesheet, export to Corona, and begin using it in my project! At that point, TexturePacker won some major points for me and I had planned on revisiting it after I completed that project.

That little experience alone got me more interested in switching to spritesheets for my own projects, but what really proved to me that spritesheets really are more superior than movieclips was that the suggestion to use spritesheets actually worked. We got the animation going and the project was able to move forward from there.

The Benefits of Using Spritesheets

I always knew that in theory, spritesheets are better than movieclips, but it wasn’t until I had done more research that I realized how they completely blow movieclips away:

  • Loading one image vs. many helps improve texture memory usage, and also speeds up your app by having to draw only one image vs. many.

  • Being able to “alias” similar image frames to be used in multiple animation sets helps to significantly reduce not only the file size of the spritesheet, but the amount of texture memory that is used while the app is running (more on this later).

  • Control the exact amount of time between each frame of animation (this is actually a limitation of movieclip.lua).

  • Creation of display objects that are associated with a spritesheet is much quicker (since no new image loads are actually taking place).

  • Eliminate a major memory leak (currently) associated with movieclip.lua by avoiding movieclip.lua altogether.

  • Probably more benefits that I haven’t thought of at the time of this writing.

However, even though there are a lot of benefits to using spritesheets over movieclips, there was still a major drawback to using spritesheets (for me anyway), and I mentioned it before:

Actual creation of spritesheets was a tedious process, to say the least. On top of that, if any adjustments needed to be made to any of the frames, it added a whole new layer of complexity to the whole thing.

And that’s where TexturePacker comes in.

Creating an actual spritesheet is as simple as importing your images into the app and clicking “Export’ … and while that would have been enough for me to use it, TexturePacker does so much more than just that. You can visit the product page for a list of features, but some of my favorite ones include:

  • The ability to import your images and have your spritesheet created instantly.

  • Option to use MaxRects algorithm to decrease the overall texture size of the spritesheet (as much as possible anyway).

  • Auto-aliasing. I mentioned this earlier, but it’s actually very complicated and time-consuming to implement. That is, unless you’re using TexturePacker, in which case it’s as simple as checking a box and exporting to Corona.

  • Autosizing, and the options on the left make the creation of spritesheets, exporting to Corona, and importing into your Corona project mostly effortless.

TexturePacker actually supports several platforms, but I only use Corona so that’s the only one I tested out during this review process.

TexturePacker + Spritesheets vs. Movieclips

I decided to run a little experiment to see the advantages of spritesheets vs. movieclips first-hand. The experiment consists of a simple app that displays a simple glowing star animation (looping indefinitely) in the middle of the screen.

One project uses movieclips, the other uses spritesheets (created with and exported out using TexturePacker).

The animation consists of 61 frames, so that’s 61 total images for the movieclip project and just one image for the spritesheet project.

For the experiment, I used the following code to keep track of Lua memory and texture memory for each app:

Runtime:addEventListener(“enterFrame”, function() – watch for leaks collectgarbage() print( “\nMemUsage: “ .. collectgarbage(“count”) )

  local textMem = system.getInfo( "textureMemoryUsed" )
  print( "TexMem:   " .. textMem )

end)

Because I used TexturePacker with the auto-alias setting turned on (and MaxRects algorithm), the exported spritesheet only consisted of 31 frames (that is awesome, considering the original animation called for 61 frames) and the dimensions came out to be 256x512.

So the results of the experiment:

Using movieclip.lua:

MemUsage: 99.8310546875 kb
TexMem:   3,997,696 bytes

Using TexturePacker + Spritesheets:

MemUsage: 83.2275390625 kb
TexMem:   524,288 bytes

So there you have it. First-hand proof that spritesheets are superior to movieclip animations in just about every way.

To put the results into a little better perspective, here are some percentages (in regards to that specific project):

  • movieclip.lua uses about 17% more memory than the same animation using spritesheets.

  • movieclip.lua uses about 87% more texture memory than the same animation using spritesheets.

Of course, your results will vary depending on your project and specific animations, but I’m confident that in any case, whether or not the percentages are the same as my test project, spritesheets will always outperform movieclips significantly.

But remember, it’s not just spritesheets.

I personally wouldn’t have the patience to manually code in things like aliasing, the MaxRects algorithm, or even just creating spritesheet images if it weren’t for software such as TexturePacker, which makes the whole process almost effortless.

If you create games and use the Corona SDK or any of the other supported platforms, then TexturePacker is not only recommended, but is absolutely essential in my opinion.

I recommend downloading the “Essential Version” for free to try it out, but I highly recommend upgrading to the Pro version if you plan on using spritesheets in your final production.

Link: TexturePacker by code”n”web

HostGator $3.96

$3.96 for web hosting – used by jonbeebe.net. Get started today.