I need to display sprites. I was thinking of writing a class that :
[*] load images
[*] pack them into a big texture (or several of needed)
[*] allow to display sprites without having to care of the textures
To pack the images in a big texture, a kind of geometric optimization algorithm is needed.
I've seen a SpriteBank class somewhere but I'm not sure it has something to do with it.
What do you think of such a class ? Should it be dynamic (like, each time you add a new image, the texture is updated) or compiled once ?
It should allow to play animated sprites, also.
Does someone has already implemented something like this ?
Regards
Tom
A class to display sprites
Thanks ! This class is cool.
And what about the idea of automatically build a texture composed of all the sprites ?
The use may look like :
Than, you would not have to care of how you create the Sprites (neither how many), since only a minimum number of textures is uploaded to the graphic card.
The point is that I don't see a quick way to pack images of arbitrary size in a power of 2 sized rectangle.
And what to do when you decide to drop one of them ?
And what about the idea of automatically build a texture composed of all the sprites ?
The use may look like :
Code: Select all
SpriteLoader loader();
Sprite & s1 = loader.createSprite("s1.jpg"); // SpriteLoader update its internal texture
Sprite & s2 = loader.createSprite("s2.jpg"); // ..if a new texture were created, s2 knows its id
...
s2.render();
s1.render();
The point is that I don't see a quick way to pack images of arbitrary size in a power of 2 sized rectangle.
And what to do when you decide to drop one of them ?
-
- Posts: 5
- Joined: Fri Jan 18, 2008 2:57 am
Google comes up with some decent looking results for "2d bin packing", try http://www.astrokettle.com/data.html
Is it really much more efficient to store the images in one big texture?
Is it really much more efficient to store the images in one big texture?
Although that doesn't apply to sprite sheets and surely it would actually be worse for performance...
Although i suppose if you're rendering a lot of sprites it would be good (if they were all rendered consecutively) to just set the texture once and then do all the rendering and with just one sheet you'd have all their different stages of animation on the gfx card already, whereas just one stage of animation per texture would require the texture to be changed for each sprite that wasn't at the same stage...
But if you've just got one sprite to render and a massive sprite sheet then you'd be needlessly uploading an unecessarily large texture which would take longer.
I guess you just have to consider which is best for your particular application. Lots of the same sprites on screen at once? Then use a sprite sheet, only one particular sprite on screen (such as your avatar)? Probably best to use individual textures.
Although i suppose if you're rendering a lot of sprites it would be good (if they were all rendered consecutively) to just set the texture once and then do all the rendering and with just one sheet you'd have all their different stages of animation on the gfx card already, whereas just one stage of animation per texture would require the texture to be changed for each sprite that wasn't at the same stage...
But if you've just got one sprite to render and a massive sprite sheet then you'd be needlessly uploading an unecessarily large texture which would take longer.
I guess you just have to consider which is best for your particular application. Lots of the same sprites on screen at once? Then use a sprite sheet, only one particular sprite on screen (such as your avatar)? Probably best to use individual textures.
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
But that would mean that you wouldn't show the other sprite frames at all. Otherwise you'd have to upload somewhere in your running application, which would mean a heavy performance problem at arbitrary moments. So even if you show the other sprite parts only every few seconds it doesn't make sense to separate them into separate textures, because the texture switch is (mostly) independent of texture size, it's just a (basically) constant factor for mapping the texture into the current process.