Let's say I'm using the following sprite as a sample to try LibGDX Animation and TextureRegion.


As you can see, the provided image above has different width & height per image. The width when Zero performs a slash is different when Zero stands.

Is it a good practice to create a padding / margin for every image so they have similar width & height. Or should I just have all the sprite cramped like that and try to handle it in the backend?



2 Answers 2


It depends.

There's a few things to think about here:

  1. Are you using a lot of memory on textures already?

  2. If you make all your texture rect sizes uniform (rects being the slice of the texture that represents a single frame of animation) and draw them all on the same size quad, are you drawing a lot of transparent pixels to the point where it's taking too long to render a frame? (more problematic on mobiles)

  3. Are your art assets already in one format or the other?

  4. Is it easy for whoever is creating your art to do one way versus the other?

The advantage of uniform rect sizes is that they're stupid-easy to deal with in code, and may or may not be easy to deal with from an art perspective. Some artists work by default drawing their sprites such that the character is already centered. This is less efficient both in terms of memory and (potentially) in terms of what you're making the GPU render, but before you start worrying about that you need to identify that this is even causing a problem for you.

Real world examples:

I've worked on a couple of 2D projects recently where each used a different approach.

The first had an isometric view, so our artist was modelling and animating characters in Maya then exporting them as a series of PNGs. Instead of making him pack together his own sprite sheet, I used a sprite packing tool that automatically generated frame positions and dimensions for each frame of the animation that he exported.

The second project was a platformer and our artist was animating each frame by hand. After doing a rough sketch of each frame in a character's animation, he would lay out a sheet in photoshop and draw directly on that. With this setup we figured that re-packing the sprite frames would have just been a waste of time. Thus we used the other approach where we just divided the spritesheet evenly in code and identified each frame by a single index.

This also enabled us to make a fun little animation file parser that let you easily mix and match animation frames. It's very possible to do with packed sprites, but I would have had to put a little more brainergy into making it happen.

Here's what the animation files looked like:

# Texture filename
# Frames across,down

# Basic Animations
idle            0-5
walk            6-12
jump            13-18
climb           19-23
dig_DOWN        24-29
dig_UP          30-35
dig_SIDEWAYS    36-41
swim            42-49
attack          50-56
split           57-64
death           65-71
falling         72-75
land_and_get_up 76-83

# Special animations made out of frames from animations above
unsplit         61-57
pulsate         66-69,68-67,57-63,62-57
  • \$\begingroup\$ Awesome! This explains a lot. \$\endgroup\$
    – syanaputra
    Mar 11, 2013 at 22:28

Best practice for your backend/engine, or however you draw them, depends entirely on your game. Best practice for artists is probably a different story. So what you should do is really tough to answer.

You could add the padding when it is imported as a game asset. Or the code could keep a list of dimensions along with a list of texture coordinates for every animation frame, and draw different sized rectangles.

This community question has many websites dedicated to the subject. I know that more than a few of them will lead you to advice about best practice for the content itself. But again, that should be secondary concern to making content that fits your own game.


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .