How to handle transparent pixels in a spritesheet

Question

I am trying to correctly handle transparent pixels. I have a spritesheet that gave me the following:

The green body is the ground physics body and the gray body around the sprite is the sprite's physics body - calculated with the bounds of the sprite. I plan on having images for the ground body of the same size, and wanted the sprite's feet to touch the ground. I was able to achieve this by repacking the images in a new spritesheet with TexturePacker, without any transparent pixels:

However, now my problem is other animations, like crouch for example:

As you can see, the sprite's feet are once again off the ground. Doing this animation in the game looks silly because the sprite crouches by lifting his feet off the ground body.

The output metadata in JSON from TexturePacker looks like this:

{
    "filename": "Crouch/soldier_crouch_1.png",
    "frame": {"x":712,"y":867,"w":353,"h":425},
    "rotated": false,
    "trimmed": true,
    "spriteSourceSize": {"x":49,"y":42,"w":353,"h":425},
    "sourceSize": {"w":433,"h":500},
    "pivot": {"x":0.5,"y":0.5}
},
// ...

This is a problem for several of my animations with this and other sprites. Repacking with TexturePacker allows me to remove the transparent pixels and have a more accurate physics body (which was really the goal, I'd like the most accurate collision detection once I start having projectiles) but now the animations look funny.

How is something like this handled in game development?

Answer 1

I don't think it is a good idea to mix logic and art; or more precisely, base your logic on your art. In simpler terms, don't do what you're doing. Separate logic from art.

The idea behind this is that the person who draws the sprites should be able to do any kind of drawings and change them at will, without having to worry that artistic changes will have an effect on the logic of the game.

Instead, I recommend you define a sprite size, and a logical origin (baseline and horizontal center), which is constant for all sprites (or explicitly defined for each sprite), regardless of what the pixels look like; then, you base all your logic around those numbers, not on what the sprites look like.

The logical origin is pretty much where the sprite touches the floor. This is not necessarily the lowest pixel, as it may be possible to have drawings where the character does intersect the ground. Also, not always the lowest pixel will be the character's feet: a running animation may have frames in which no feet are touching the ground.

It is also useful for the origin to contain a horizontal center. You could use this as a pivot when turning the character to the opposite direction. This is not necessarily the actual center of the sprite: a sprite of a jousting knight with a long lance pointing right could have a horizontal center placed all the way to the left.

Additionally, you may want to include other points of interest in your specification, such as where the top of the head is when jumping (for top collisions), where the action point is (like the tip of the lance in our jouster), or where any collision points are (for damage taking and stuff). All this is called the technical specifications for your art. This should obviously be discussed with the artist.

If the artist also respects these specifications, you should not have the problem you're having, the artist can change the sprites at will, and not worry that any changes will affect the logic of the game.

The main advantage of working in this manner is consistency, but also you can get rough sprites so you can work on the game, and then replace your sprites with the final ones. This workflow is much easier to work with.

Then, if you want you can make the sprites take less space in your spritesheets, you can trim the transparent pixels out, but you should then make any necessary coordinate corrections for when this happens.

Answer 2

If you arent going (or can't because of software limitations) to remove the extra pixels you could go into the original sprite sheet and move the image of the crouching soldier down.

The problem is that you won't have accurate collision detection if you are keeping those extra pixels so crouching might be useless.

Answer 3

you can simply use the box2d editor to match your sprite sheet with the body fixture there is a powerful application who do this for you :

LINK

you can :

• Automatically decomposes concave shapes into convex polygons,
• Automatically traces your images if needed,
• Supports multiple outlines for a single body,
• Supports polygon and circle shapes,
• Reference point location can be changed,
• Visual configurable grid with snap-to-grid option,
• Built-in collision tester! Throw balls at your body to test it,
• Loader provided for LibGDX game framework (written in Java),
• Simple export format (JSON), to let you easily create your own loader for any framework in any language.