Best way to load / Use sprites

Java 2D
#1

Hey guys, I’ve been wanting to incorporate more animation into my game, but I can’t really figure out a good method of doing so. As of now, I break up single .png images into smaller components, and then use those, but this method requires pixel-perfect alignment to work, which is a very tedious process. This also makes it difficult to perfectly line up the sprites, especially for a quick demo.

Basically, the question boils down to:
What system do you guys use of loading and breaking up 2d frame by frame sprites into various components, and how would one do so without extensive pixel alignment?

#2

I do it by turning on the grid in my graphics editing program.

or saving each frame to its own file.

Pixel alignment isn’t that tedious is it?

#3

I ending up to doing my own sprite editor with my own file format (PNG file with encoded data at the end). It is OK for most of my use.

#4

I keep single animation frames in individual image files (usually png) and have metadata (like animation sequences, collision data, etc.) in a seperate xml file. Animations have a sprite offset for every entry to allow me to line things up. And because I’m using Rebirth, tweeking them can be done on-the-fly while the game is running making it a lot easier and less tedious.

#5

Chaz composes all the animations in multiple layers in Photoshop; he’s then got a script that exports all the layers individually, all at the same size. I think he generally defines the actual XML part of the animations (which describes loops and timings) entirely by hand.

The exported layers are of course mostly transparent, so our sprite packer trims the pngs of all dead space and records an offset against the image so that we know to translate it before it’s drawn. This combination of exporting identically sized layers and automating the trimming and offset calculation effectively puts an end to any tedious pixel alignment problems*.

Cas :slight_smile:

  • except, as we discovered, when shrinking sprites down to half size, as we discovered - that can be prone to occasional single-pixel offset rounding errors (correctable by super-faint pixels to fox the trimmer)