by date
Spritesheets and Video Memory in TGB
Spritesheets and Video Memory in TGB
| Name: | Michael Woerister |  |
|---|---|---|
| Date Posted: | Feb 13, 2007 | |
| Rating: |  5.0 out of 5 | |
| Public: | YES | |
| Comments: | YES | |
| RSS Feed: |  or Subscribe with  . | |
| Profile Page: | View profile page for Michael Woerister |
Blog post
2D games can take up quite a lot of video memory. They often feature smooth animations that need a lot of single frames and you constantly hear people complaining about TGB's high memory consumption. Fact is though that quite a significant percentage of video memory is wasted for storing completely transparent areas. For example take a look at this clipping of a regular sprite sheet (from Konami's 1993 'Batman Returns' on the SNES):
Only the green areas of the image carry relevant picture data whereas the red areas could be omitted without any loss. If the sprite sheet is stored as a PNG file those red areas won't make a real difference on your hard drive as they will compress practically to zero. However in video memory such compression is not available. Even if texture compression is available it is neither lossless nor is it very strong (50% gain at the best). So in video memory it does matter whether those red areas are stored or not.
Last Sunday I found the time to do some tinkering. TGB's image map system already is pretty nifty and if you hook into the place it is just a minimal code addition that has the task to find out the relevant area of every frame and then store its size and position relative the original size and position. The rendering code can then use this information to simulate the transparent areas of the image by just offsetting the smaller green area in the sprite. It took less than 2 hours to get a prototype working and the result is quite pleasing :)
BEFORE
AFTER
As you can see the sprite sheet created without this technique was sized 1024x256 pixels whereas the second sheet is sized only 512x128. That means it uses only a fourth of the memory the other sheet uses without losing any information.
And that gain can be achieved without any intervention on the side of game developer. Everything happens behind the scenes.
I think this would be quite a nice addition to TGB's image map system.
Only the green areas of the image carry relevant picture data whereas the red areas could be omitted without any loss. If the sprite sheet is stored as a PNG file those red areas won't make a real difference on your hard drive as they will compress practically to zero. However in video memory such compression is not available. Even if texture compression is available it is neither lossless nor is it very strong (50% gain at the best). So in video memory it does matter whether those red areas are stored or not.
Last Sunday I found the time to do some tinkering. TGB's image map system already is pretty nifty and if you hook into the place it is just a minimal code addition that has the task to find out the relevant area of every frame and then store its size and position relative the original size and position. The rendering code can then use this information to simulate the transparent areas of the image by just offsetting the smaller green area in the sprite. It took less than 2 hours to get a prototype working and the result is quite pleasing :)
BEFORE
AFTER
As you can see the sprite sheet created without this technique was sized 1024x256 pixels whereas the second sheet is sized only 512x128. That means it uses only a fourth of the memory the other sheet uses without losing any information.
And that gain can be achieved without any intervention on the side of game developer. Everything happens behind the scenes.
I think this would be quite a nice addition to TGB's image map system.
Recent Blog Posts
| List: | 02/13/07 - Spritesheets and Video Memory in TGB 08/13/06 - The Only Alternative |
|---|
Submit your own resources!| Don Hogan (Feb 13, 2007 at 14:01 GMT) |
| Michael Woerister (Feb 13, 2007 at 14:08 GMT) |
It is not really a resource though. I just hacked together a proof of concept. Unfortunatly a modification like this cannot not be made by just adding a new source file to the project. Existing source files have to be modified (t2dImageDataBlock.h, t2dImageDataBlock.cc, t2dAnimatedSprite.cc, t2dStaticSprite.cc, t2dTileMap.cc).
| Maurice Ribble (Feb 13, 2007 at 14:34 GMT) |
You seem to have a small misconception about texture compression on GPUs. They way textures are compressed on GPUs is constant rate compression. For example with DXT1 all RGB8 textures are compressed at a ratio of 8:1 and with DXT5 all RGBA8 textures are compressed at a ratio of 4:1. This is regardless of whether the image is all white or random noise (the noise texture will have much more error when compressed though). The reason this type of compression is done on the GPU is because it's much easier to implement fast hardware for these gradient block based compression schemes.
One tool that I really like using is called the compressionator. This tool lets you compare your original image to what it looks like when compressed on the GPU. Then you can decide if the image should be compressed or not. Any savings from using compressed textures would be additional to the memory savings of your tool. http://ati.amd.com/developer/compressonator.html
| Matt Huston (Feb 13, 2007 at 15:50 GMT) |
| Tom Spilman (Feb 13, 2007 at 16:35 GMT) Resource Rating: 5 |
Also note that this not only saves texture memory, but also performance. The transparent areas of those sprites consume fillrate and the less of it, the more GPU performance you gain.
Edited on Feb 13, 2007 16:37 GMT
| Chris Labombard (Feb 13, 2007 at 16:42 GMT) |
Quote:
It is not really a resource though. I just hacked together a proof of concept. Unfortunatly a modification like this cannot not be made by just adding a new source file to the project. Existing source files have to be modified (t2dImageDataBlock.h, t2dImageDataBlock.cc, t2dAnimatedSprite.cc, t2dStaticSprite.cc, t2dTileMap.cc).
There are lots of resources that involve editing files instead of just dropping in whole files... I'd be very interested in seeing this posted as a resource.
| Todd Pickens (Feb 13, 2007 at 17:22 GMT) |
This is exactly the sort of thing that makes the Garage Games community so great to work with, we have an opportunity to build on each others innovation.
I don't even want to begin to recount the amount of sprite work in the TGB game I am currently working on. This would be very beneficial.
Please do share it.
| Phil Carlisle (Feb 13, 2007 at 17:42 GMT) |
| Justin DuJardin (Feb 13, 2007 at 18:04 GMT) Resource Rating: 5 |
I'd love to incorporate this into TGB at such a time as it is beyond being a proof of concept, please do post this as a resource!!
-Justin
| Drew -Gaiiden- Sikora (Feb 13, 2007 at 18:10 GMT) |
| Michael Woerister (Feb 13, 2007 at 18:46 GMT) |
@Maurice - Thanks for explaining that. My knowledge of texture compression is very rudimentary.
@Tom - I got your email. I'll come back to your offer for sure.
@Justin - University will take another year at least. That is if I stop at the bachelors degree ;)
| Thomas Buscaglia (Feb 13, 2007 at 21:47 GMT) |
| Clint Herron (Feb 13, 2007 at 22:41 GMT) |
| David Higgins (Feb 13, 2007 at 23:14 GMT) |
| Andrew Douglas (Feb 14, 2007 at 16:56 GMT) |
Note: I definitely want texture compression as well. I guess I want the best of both worlds :)
-Andrew
| Michael Woerister (Feb 14, 2007 at 18:14 GMT) |
The image (96x96 px) above results in the texture page below (48 x 48 px cells):
As you can see the padding occurs around the relevant area of the image - not around the transparent border as it would without the resource. So one could even argue that this improves the filterpad feature.
Edited on Feb 14, 2007 18:17 GMT
| Joe Rossi (Feb 16, 2007 at 04:27 GMT) |
Anyway I think this is awesome work and I'd also love to see this become standard in TGB.
| Ehrlichmann Casas P. (Aug 08, 2007 at 11:36 GMT) |
You must be a member and be logged in to either append comments or rate this resource.
