Jump to content

Texture Atlas Animations vs Spritesheets


WombatTurkey
 Share

Recommended Posts

I keep thinking about this all the time but never really cared until now.

As we know, there is texture atlas animation:

http://www.joshmorony.com/how-to-create-animations-in-phaser-with-a-texture-atlas/

Which is nice because we save memory, a quote from Richard Davey:

Quote

There is no technical advantage of using a sprite sheet at all. They tend to use more space both in memory and bandwidth because they don’t pack frame data as efficiently as a texture atlas does.

However, there are lots of legacy graphics out there in that format, and its still quite popular today. So we support them. But you should try and pack graphics into atlases where possible to save on ram.

What I am worried about is this:

Let's say you're making a gigantic game, using.. tons of skill animations. And... you stick them all into a texture atlas. That image becomes huge, like 3000x3000. And you don't want to continue to add images on it because you're worried it will effect performance. That's where I am at and am curious if that is the case, is using sprite sheet's more appropiate? I mean, I cannot imagine having like 100 skill animations, and you fit them all on a 5000x5000 image and it would be okay animating those in-game. And plus, some skill animations have tons of frames, so in essence, the dimensions I'm talking about here are peanuts compared reality.

So, is having one YUUUGE sprite image with hundred's of animated sprites better than going the spritesheet route? Then, you got to think, well, you will have hundred's of spritesheets that need to be loaded; and that alone takes up memory.. I just don't know which way would be the most efficient. Maybe @rich can chime in.

Just to add: Since there are over 100 skill animations, I also created a little 'dynamic loader' function that only loads that spritesheet when a player uses that skill. This way, the game doesn't have to load all 100 spritesheet's in the beginning, but do so dynamically. If I choose that route then I am not using the texture atlas animation image... Now I'm back at square one, not sure which way would be better. Thanks for reading :)

Edit: This is about desktop GPU's only  

Link to comment
Share on other sites

Swings and roundabouts.  Pros and cons for atlas's vs spritesheets.

You say for desktop GPU's only, so your max texture size is most likely better than a mobile, so I'd start getting worried going above 8192x8192.

Assets via slow remote network or fast intranet/filesystem?  If fast then probably don't need to worry about too much about sizes and number of items.

If slow then sizes and number of items will affect loading times.  It isn't always the case that an atlas will outperform separate gfx, for example a spritesheet that contains an animation using similar colours might be acceptable as an 8bit png, if there's no transparency then a .jpg would probably be smaller.  The problem with atlases is that you have to use a common format to cater for all the contents, just one image with transparency will require the complete image to have transparency, this can increase your file size quite a lot.  You can store transparency separately or even build an atlas internally from separate images but that's a whole new level of complexity.

An atlas will usually outperform separate images during rendering because of reduced texture swapping, but if you've squashed everything into more than one atlas then you could still be swapping between large textures quite often depending on how your scene is arranged.

In your case there isn't a clear direction to take, there will be pro's and con's either way, all I can recommend is that you adopt a pipeline which gets you too your goal easier and quicker.  If you already have a workflow and codebase which can switch between separate's and atlases then great, otherwise worry about optimisation at the end.

Link to comment
Share on other sites

11 hours ago, stupot said:

Swings and roundabouts.  Pros and cons for atlas's vs spritesheets.

You say for desktop GPU's only, so your max texture size is most likely better than a mobile, so I'd start getting worried going above 8192x8192.

Assets via slow remote network or fast intranet/filesystem?  If fast then probably don't need to worry about too much about sizes and number of items.

If slow then sizes and number of items will affect loading times.  It isn't always the case that an atlas will outperform separate gfx, for example a spritesheet that contains an animation using similar colours might be acceptable as an 8bit png, if there's no transparency then a .jpg would probably be smaller.  The problem with atlases is that you have to use a common format to cater for all the contents, just one image with transparency will require the complete image to have transparency, this can increase your file size quite a lot.  You can store transparency separately or even build an atlas internally from separate images but that's a whole new level of complexity.

An atlas will usually outperform separate images during rendering because of reduced texture swapping, but if you've squashed everything into more than one atlas then you could still be swapping between large textures quite often depending on how your scene is arranged.

Hey, thanks for this reply.

About the network, it will all be local since I'm going to use NW.js. That's kind of why I was thinking loading the individual spritesheets would be a good idea.

Quote

In your case there isn't a clear direction to take, there will be pro's and con's either way, all I can recommend is that you adopt a pipeline which gets you too your goal easier and quicker.  If you already have a workflow and codebase which can switch between separate's and atlases then great, otherwise worry about optimisation at the end.

Honestly, I think the spritesheet way for me and loading them in dynamically would make me reach my goal easier. I guess I will just do that, and worry about optimization later. I really do appreciate your post, it has helped.

Link to comment
Share on other sites

 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...