Hello, I’ve been working with lwjgl for a while, and I’ve had luck making characters move around and attaching sprites to them so they look like the chracter is moving (I haven’t figured out how to do animation yet though) but I was having a lot of trouble with spritesheets after following some tutorials about using them. Is there a major benefit in speed or other benefit if you use a spritesheet over just separate images of the sprites (EG: player sprites, terrain sprite, etc all in different files)?
I dont remember the detail, but +1 for using spritesheet.
The main point is that it’s neater, which can be a big deal. Other than that, I don’t think it’s that important, but I can’t be sure.
Doesn’t it decrease image size? I mean having it all in one image just means expanding the length/width but 2 10x10 images take up more space than one 20x10. This is what texture packers do so I assume it’s correct…
Spritesheets are better for OpenGL programming as you can just render everything in one go, instead of rebinding the texture every few vertices. It’s a performance thing, but it shouldn’t matter in Java2D, if that’s what you’re using.
Ah okay well I guess Ill continue trying to work with the spritesheets then, thank you all for your quick responses!
Since Java2D tries to use hardware acceleration under the hood, it’s also wise to use sprite sheets and BufferedImage.getSubImage where possible as it may allow for better performance.
With LWJGL, sprite sheets are pretty much essential if you plan to render many sprites per frame. It should really be step 1 of optimizing any OpenGL game. Step 2 would be creating a sprite batcher, instead of using old-school glBegin/glEnd calls everywhere. If you’re interested, you should check out LibGDX’s sprite batcher or my own minimal sprite API here.
If you’ve organized your Texture wrapper well enough, then creating a sprite sheet utility should be easy as pie. See the TextureRegion source in LibGDX, for example. If your’e still struggling with basic OpenGL Texture concepts (of which texture coordinates is an essential part) then see here.
I’m still really new to LWJGL and java game design in the first place, so I’m not 100% sure what a lot of this means! xD I’ve been trying to follow tutorials, however there seems to be a lack of good ones out there for LWJGL. There are some limited ones from thecodinguniverse on youtube and some others, but none that go into depth on sprites. Thank you for the info however, I’ll make sure to keep it in mind when I learn more.
I agree that there are not too many tutorials that cover LWJGL and Java-specific OpenGL programming. This is why I’m writing my own series:
Cheers. 
That is awesome, thank you for the link! I’ll definitely be following it very closely.
The libgdx texture packer handles converting separate images into a packed spritesheet, with many features like rotation and whitespace stripping. The output is packed image(s) and a text file describing the sprite positions, so it can be used without libgdx.
[quote=“kynian,post:1,topic:40496”]
As far as I understand, the major benefit lies in that using a sprite sheet you can draw all sprites on the texture (that backs the sprite sheet) mixed up while still only needing to “bind” the texture only once. Since in OpenGL a texture “bind” is quite an expensive operation, this saves a lot of time compared to needing to bind a new texture for each new sprite.
I found this out for myself recently when I noticed that using one rendering approach I managed to get 12x the performance of another approach (i.e. binding a new texture for every sprite rendered). So avoiding having to many new texture binds definitely pays off.
There’s some nice brief performance tips on the LibGDX wiki.
In one of my former projects I used individual images. I can tell that if you want to copy like 1000 small PNGs to an USB stick, it takes like, ages. Loading is still fairly fast though.
I assume with a harddisk you don’t notice this.
I then switched to zip archives containing all the small images. Makes it easier to handle, but harder to access. It allows to bundle meta data with the images though, and keeps it all together. This is a benefiot that I started to like.
It also becomes increasingly difficult to name the files, if you have them all in one folder. If you have 0000.png … 1752.png it will become reall hard to find something.
Sprite sheets circumvent some of these problems. But if you have sprites of vastly different sizes, sheets with a fixed raster become inefficient, and you must looks for better organization of the sprites on the sheet.
I’ve been using both, and still couldn’t make up my mind. It’s not too hard to change even late in a project, though, so it wasn’t a big issue for me so far.
[quote=“Varkas,post:13,topic:40496”]
In Libgdx’s Texturepacker, it packs it just as it fits, trying not to waste space - its very effecient.
It also creates the atlas for you and everything… artists can just save every image as a single png the code of the packer will do the rest
its really the best solution