[font="arial, verdana, tahoma, sans-serif"]I've come to the stage where the most of the coding in my game is done. The only things I got left is to add sound and change most of the textures. Replacing the textures is really neccessary, but in my opinion both boring and hard. What I got a lot of struggles with is 2d sprite animations. I'm doing it by using a texture atlas storing all frames for each character, then I just extract the part of the image that needs to be drawn at frame X. The coding part of it is completed but I'm curious what the best/easiest way is to setup a good looking texture atlas.

I've both tried to make my own character from scratch (which failed) and also to take a Mario or Megaman sprite sheet and resize them and then put them in a texture atlas, which this topic is about, but that also went bad. The issue is that my algorithm for finding which texture coordinates to draw requires that all the frames have the same dimension. That aren't the case on most sprite sheets so it ends up with me having to scale them to the same size, which looks terrible.[/font]


This is how my customized Megaman texture atlas look:



As you can see the size of him is not the same on each frame.

I'm either looking after completed animations for characters/enemis or a really good tip about how to do this.

Thanks a lot, cheers!

I believe the two conventions are to:

• Add a load of whitespace (zero alpha) padding around the larger cells to make them all the same size.
  
• Accompany your sprite sheet with an XML file or similar that describes the co-ordinates of each cell along with a reference point to centre the image upon.
  

I used to use a variation on the second approach. I had a command line tool that would take a bitmap sprite sheet and a text file describing the dimensions of each cell along with the reference point and compile it into a binary file containing the image data for each sprite that my game could then load, but then I always do tend to overcomplicate things.

BMFont uses the second approach in the list above to deal with proportional fonts I believe.

Thanks for the fast reply Aardvajk!

The second approach sounds like the best one, when I think about the first one it feels like it wouldn't work. If the source of a frame is bigger than the character itself wont that mess up the collision detection? I mean if a object collides with a wall to the right and than has 20 pixels of transparency wont that make it look like the object isn't touching the wall?

I will try the second approach. You have to count the width of each frame animation from the texture atlas and the size of the character in-game also needs to change when the size of the frame changes, right?

the source of a frame is bigger than the character itself wont that mess up the collision detection? I mean if a object collides with a wall to the right and than has 20 pixels of transparency wont that make it look like the object isn't touching the wall?

Your collision box can be different from your animation frame. Since the alpha of the padding is zero anyhow, it won't interfere with any graphic issues, and the hitbox can be the same size and relative position in each frame for something like Mega Man.

I will try the second approach. You have to count the width of each frame animation from the texture atlas and the size of the character in-game also needs to change when the size of the frame changes, right?
[/quote]

The character size doesn't need to change with differently sized frames (unless there's a particular reason to do so, like using a different hitbox). The frames' size can be adjusted through padding with whitespace, the only effect of which is to make animating a string of frames easier via a consistent set of dimensions. All that you use the frame width/height for is to clip the right sprite from the sprite sheet.