views:

1388

answers:

4

I'm writing a basic sprite engine for my own amusement and to get better aquainted with Java's 2d API. Currently I am making use of large numbers of separate .png files with transparent backgrounds to represent the various sprites and different frames of animation that I need. Most 'real world' game development projects seem to make use of 'sprite sheets' which contain multiple sprites or frames of animation within a single file. Also, rather than making use of native image transparency support, people often nominate an arbitrary colour that does not appear in the sprite pallette to be the transparent colour. How does one manage a file like this programatically?

  • how do you know where one sprite starts and the next begins
  • how do you deal with transparency

There may be other factors that I've not thought of here, so I may add to the list above as I think of things or as people make suggestions (please do so in the comments).

A: 

Well, since most of them are custom, those details are up to the implementor. You'd generally have the file start with header information that contains the details of height/width and encoding, transparency, etc.

A lot of the time things are in one file because it is very expensive to open/read multiple files compared to open/read one file. Many game engines use zip or "ziplike" files with 0 compression to treat a single file as a filesystem.

John Gardner
what do you mean by "custom"? Most are vanilla bitmaps. If I have a sprite sheet in .jpg or .png format, how can you encode meta-data into it without employing steganography or something?
ninesided
they are "custom" in that they are yours so you can decide what is in the file. yes, the content may be a simple bitmap, but you could make a custom file format or custom info in the bitmap containing the size of the sprites.
John Gardner
A: 

some info including a java demo Tilestudio

Peter
Thanks for the info, but that looks like it's just a sprite/tile creation tool. What I'm wanting to know is how best to implement something that reads/processes that kind of image.
ninesided
+1  A: 

I currently use XML files generated by a simple sprite editor that store the sprite as a collection of (optionally animated) poses, which are in turn a collection of frames or cells. Frames store per-frame information like the x and y offset of the frame in sheet, cell width and height, and any transformation (resize/rotation/hue/etc.). Poses store individual frames and animation information (speed, for example), and a pose name to easily identify them in the program (hero.pose = sprite.pose["standing_right"]). Sprites serve as a document root to hold several poses, such as a pose for each facing direction.

A less flexible alternative I used earlier was to specify fixed sizes for cells and sheets and calculate frame offsets and sizes based on these values (e.g. width is always 32 pixels, so third sprite is at 32 * 2). Later I started specifying these dimensions in the file name (e.g. sprite_name_32x64.png) for sprites that don't fit the fixed cell dimensions. I like the new approach more, especially with a simplistic editor that fills most values for me and allows me to use sprites as templates for other sprites.

I use the alpha and transparency information stored in PNG images directly so I don't need to worry about storing it elsewhere, although other approaches would be to pick a fixed value per sprite and store somewhere, use the leftmost pixel in the pose if you know it's always empty, use a specific palette entry if you're using those, sprite masks, or what have you.

Firas Assaad
A: 

Make your sprite sheet knowing the size and number of each sequence.

Grab a buffered image of your sheet and use something like this: currentframe=spritesheet.getSubimage(x, y, w, h);

Your x and y will change based on the frame you are on. Keep the width and height the same to make things easy on yourself.

Forget trying to keep the entire game on one sheet. It's nuts and hard to manage. Use a new png for each animation sequence. If you are anal about saving space only create moving right animations and just flip the buffered image real time to move left.

Java will read png files with the alpha so don't worry about the transparency colour. Draw everything in pngs. Use Photoshop or Gimp.

Search google for java image TYPE_INT_ARGB

SAKIPOOH