Sprite-sheet vs individual images

[David M.]

Do you prefer working with sprite-sheets or having individual images stored in an array for sprite animation? Which is more efficient?

So far I've only used images in an array for my animation and wanted to hear from you guys.

[kammce]

I personally prefer working with individual images... I am actually thinking about creating my own type of image that has animations within them (similar to GIF files) but I would be able to invoke then more efficiently.

But what I use now is a folder, I separate every animation by a folder, full of a sequence of images that add up to one animation, then I use the Java Thread and a class and a function that I came up with to make sure that the animation goes all the way.

[Skiller]

If you want any kind of real performance and are using hardware acceleration (probably OpenGL) then sprite sheets are a must, they also use less memory and make it easier to reduce draw calls and cause significantly less cache misses. However if you are making a small game, a game with no real need for real time performance, or a game that will run on hardware far exceeding what the game requires then you can probably get away with multiple images provided it's not too many (say under 200). It's a lot easier to maintain individual images rather than sprite sheets and they are a lot easier to implement but at the professional level it's almost never done.

I come from a c++ background though, having worked on PS2, PS3, XBox 360, PC and currently contracted for an iPhone game (having to put my own android game on hold for a few months :( ), so I can't really comment on performance if you are just using whatever the standard Java UI classes are, but I suspect that they are slow enough that the performance difference of using arrays of textures wouldn't matter much.

In short if you want to be a professional game developer use sprite-sheets, if you are making a hobby game you'll probably be fine using multiple images.

[David M.]

Thanks for the reply. I haven't gotten into anything more than swing animation yet. How do you normally read the images from the sheet? I tried for a while a few weeks ago but couldn't get it to work right.

[Skiller]

It depends on what you are using to render/draw the images to the screen, in OpenGL you just use a different set of texture coordinates for each frame in the image, since the texture coordinates are needed and used in the rasterization anyway it's essentially a free operation which makes it very fast. If you are using some Java GUI classes then I'm not sure about the specifics as there could be multiple ways to achieve it, but there will probably be some way to only draw a small part of the image, so you just create an array defining the parts for each frame in the image. If you let me know what API you are using to draw the images I might be able to help further.

[David M.]

So far all I've done is override the paint() method of a JPanel and use the Graphics2D drawImage() method.

How difficult is OpenGL to learn?

[Skiller]

I had a quick look over the Graphics2D docs, and you could probably use a sprite-sheet by offsetting the position of the image so the section of it that you want to render is in the right spot then using the clip method to limit the area to draw to just the section of the image you want before you call drawImage. For each frame in the image you'd want to store both the relative offset to add to the transform and something to set up the clip to use into an array for you can just use the pre-calculated values to adjust the image as needed when it's drawn.
However it looks like the Graphics2D stuff wasn't designed for that sort of use so I'd recommend sticking to using separate images while using it unless someone more knowledgeable about Graphics2D says otherwise.

As to OpenGL, it's difficult to say how hard it is to learn, if you are good with maths it's not too hard, also using earlier versions of OpenGL with the fixed function pipeline is really quite easy too and still plenty good enough for most games. But learning to use OpenGL efficiently, understanding the vector and matrix math involved and using newer OpenGL versions that require you to use shaders that you have to program yourself instead of the fixed function pipeline can be much more difficult. Probably a bigger consideration is that it's also a LOT more work using OpenGL, you'll pretty much need to write your own GUIs, and in particular displaying text can be a huge pain, it's usually worth the effort though, it's very fast and can do a lot of fancy things to really make a game look good and run smooth. TBH though, unless your target platform has a JVM with OpenGL integrated like Android you'll probably be best sticking to that Graphics2D stuff, unless you also want to learn C++, as after a quick look into OpenGL in Java on other platforms it seem a little under supported, though Minecraft has done well with Java and OpenGL on Windows. If you are still interested in learning OpenGL check out NeHe they have some of the best tutorials to get you started with OpenGL, they are aimed at a Windows/C++ audience, but C++ has almost identical syntax to most of Java so it should still be just as easy to understand what's going on and will only need minor modifications for the code to work (if any), you'll have to read the docs on setting up an OpenGL window in Java in the docs for the Java implementation of OpenGL that you use first though.

[kammce]

I had a quick look over the Graphics2D docs, and you could probably use a sprite-sheet by offsetting the position of the image so the section of it that you want to render is in the right spot then using the clip method to limit the area to draw to just the section of the image you want before you call drawImage. For each frame in the image you'd want to store both the relative offset to add to the transform and something to set up the clip to use into an array for you can just use the pre-calculated values to adjust the image as needed when it's drawn.
However it looks like the Graphics2D stuff wasn't designed for that sort of use so I'd recommend sticking to using separate images while using it unless someone more knowledgeable about Graphics2D says otherwise.

This is the reason why I use separate image files for everything because it is easier for me. Performance wise, you could get you program to load all of the images into the user's RAM (just add all images to a JLabel that is inside of an invisible JFrame, and when that is done the game's images should present themselves much faster) then you could flush all the images right after you done using them.
Lets say your on level 1. You use your invisible JFrame to load all of the images. Once the loading is complete, the level starts. You finish the level. You flush all of the images out and load all of level 2's images into the user's memory. This is just my preference though. Do what ever feels/works right for you.

[DarrylBurke]

you could get you program to load all of the images into the user's RAM (just add all images to a JLabel that is inside of an invisible JFrame

Just load them using ImageIO#read(...), which blocks till the image is loaded.

And BufferedImage#getSubImage(...) is the way to go for handling a sprite sheet. No need for mucking around with Graphics clips. The memory footprint is also low as

The returned BufferedImage shares the same data array as the original image.

db

[David M.]

Thanks for the replies.

I've looked into Android in the past but never got into it. Wanted to start C++ for its wider use in game programming but haven't gotten to it yet.