Compression of large files
Author
I''m using DirectX 9/Direct3D to create a 2D game. I''m using a rather large bitmap for the main town. Because I am using bitmaps and a high color depth for alpha channeling, the size of the bitmap file is up around 100 megabytes. If I keep going at it with bitmaps of this size, then my game will go into the gigabytes range. What''s a commonly used and effective way for compressing and uncompressing large bitmaps without loss of any data like the alpha channel. (I hope I worded that right)
What is the purpose of this enormous bitmap? Do you really need its dimensions so large? 100 megabytes sounds like a hell of alot. You could try PNG.
Oh, and unhelpful linky.
Oh, and unhelpful linky.
may I recommend breaking the huge bitmap into tiles? lots of smaller files could be dynamically loaded as the user roams.
btw, if you want to code your own loader, check out the PRF format from:
http://www.muppetlabs.com/~breadbox/software/prf.html
lonesock
Piranha are people too.
btw, if you want to code your own loader, check out the PRF format from:
http://www.muppetlabs.com/~breadbox/software/prf.html
lonesock
Piranha are people too.
Yeah. It''s likely that you''ll find a lot of repeated uses of tiles, too. So you could just store one set of all the different tiles, and a big array of tile indices. Then use PNG compression on your tile image (and possibly ZIP on the array, which you''ll probably store as a binary file), and you''re all set.
Author
Thanks for the advice. I''ll try out converting it to PNG and see how much of a difference that makes.
For gosh-darn sakes, change your design! 
Consider tiles, like others have suggested. Suppose some one actually is willing to download a game with such monster file sizes, what kind of machine are they going to require to load and process graphics that large into memory in real-time? Just converting to PNG isn''t going to solve your problem.
Consider tiles, like others have suggested. Suppose some one actually is willing to download a game with such monster file sizes, what kind of machine are they going to require to load and process graphics that large into memory in real-time? Just converting to PNG isn''t going to solve your problem.
yes, big bitmap == death. your town will get bigger and bigger and your bitmap will get bigger and bigger. then your app will die because you have exceeded the memory of your machine. use tiles.
and to answer this question:
people don't use huge bitmaps. they use tiles.
TILES!
-me
[edited by - Palidine on March 30, 2004 2:14:31 PM]
and to answer this question:
quote:
What's a commonly used and effective way for compressing and uncompressing large bitmaps without loss of any data like the alpha channel. (I hope I worded that right)
people don't use huge bitmaps. they use tiles.
TILES!
-me
[edited by - Palidine on March 30, 2004 2:14:31 PM]
Author
Hey, thanks for the advice, guys; hang with me though I''ve got just a few more questions. 
Tiling takes care of the in-game memory, but how much can tiling help for actual game size? I mean, if I split a 100 meg bitmap into a hundred smaller 1 meg tiles, that''s still a 100 meg game. If I''m going to be making several villages like this, then that easily makes the game a gigabyte in size. Now, supposing I converted all of the formats to png, and then even zipped it from there, would the compression cause me to lose color quality? And would I unzip those files all at once at compile time, or one-by-one as I need them during run time?
Tiling takes care of the in-game memory, but how much can tiling help for actual game size? I mean, if I split a 100 meg bitmap into a hundred smaller 1 meg tiles, that''s still a 100 meg game. If I''m going to be making several villages like this, then that easily makes the game a gigabyte in size. Now, supposing I converted all of the formats to png, and then even zipped it from there, would the compression cause me to lose color quality? And would I unzip those files all at once at compile time, or one-by-one as I need them during run time?
Tiling can help for the total game size if some of the tiles are repeated. As the game designer, you need to enforce that if you want to reuse tiles.
There are things you can do to get away from this model: for example, generate the background (like ground textures) proceduraly from some function, then just overlay the buildings (or whatever) on that. PNG supports transparency, so you're already ahead there.
You'll find that when images are compressed in png (or jpg), then zipping the result is a waste of time and processor power. You might not want to leave them as individual files, but just stitch them together yourself with some kind of index, and don't worry about a zip lib.
PNG is lossless, so you will not end up losing color info, but you also won't get exceptional compression ratios either (maybe reduce by half?). If that is an issue you may want to go to jpg (no transparency) and just eat the quality loss.
Also, I think I remember someone making a patched png encoder that allowed lossy encoding, to reduce the size. This wouldn't affect the decoding (think of the lossy part as a pre-processor), so it's no trouble for your png loading lib. You'll have to google it, though.
lonesock
Piranha are people too.
[edited by - lonesock on March 30, 2004 8:07:38 PM]
There are things you can do to get away from this model: for example, generate the background (like ground textures) proceduraly from some function, then just overlay the buildings (or whatever) on that. PNG supports transparency, so you're already ahead there.
You'll find that when images are compressed in png (or jpg), then zipping the result is a waste of time and processor power. You might not want to leave them as individual files, but just stitch them together yourself with some kind of index, and don't worry about a zip lib.
PNG is lossless, so you will not end up losing color info, but you also won't get exceptional compression ratios either (maybe reduce by half?). If that is an issue you may want to go to jpg (no transparency) and just eat the quality loss.
Also, I think I remember someone making a patched png encoder that allowed lossy encoding, to reduce the size. This wouldn't affect the decoding (think of the lossy part as a pre-processor), so it's no trouble for your png loading lib. You'll have to google it, though.
lonesock
Piranha are people too.
[edited by - lonesock on March 30, 2004 8:07:38 PM]
I''m not sure you understand what the guys mean by tiles..... they don''t mean break the bitmap up into 100 or 1000 smaller squares (that would require dynamic loading and scrolling code.....)
Tiles are something like what Mario used on the NES (everyone must remember Mario on the NES).... there were certain textures for walls, pipes and trees and so on... what YOU have to do when using the tiles, is have a sort of script or area in your code that details exactly what tiles get placed and where they are placed.
Also the tiles are normally quite small, so for example a wall tile could be 32x32 pixels, and what you would do is have that tile repeat itself for however much wall you needed.....
Hope this helps........ anyone got any other way to explain tiles ?
Tiles are something like what Mario used on the NES (everyone must remember Mario on the NES).... there were certain textures for walls, pipes and trees and so on... what YOU have to do when using the tiles, is have a sort of script or area in your code that details exactly what tiles get placed and where they are placed.
Also the tiles are normally quite small, so for example a wall tile could be 32x32 pixels, and what you would do is have that tile repeat itself for however much wall you needed.....
Hope this helps........ anyone got any other way to explain tiles ?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
