Printable View
Hypothetically, if I had a C++ program that uses 3,000 different small bitmaps (mostly 32x32, but maybe a hundred or two are bigger than that) that had a total size of 30MB combined, is there some way I could combine them all into a resource file of some kind so that my exe could just read a single "Graphics.dat" file (or whatever) instead of cluttering the end user's hard drive with 3000 individual files?
See Resource Functions under the heading Menus and Other Resources.
From what I can tell, C++ "resource files" are stuffed into the end of the exe itself.Quote:
Originally Posted by dilettante
Stuffing 2800 bitmaps into an exe file would result in a 30mb exe, which doesn't seem workable. Is there a way to bundle resources outside of the exe, to a separate data file?
You could create a "resource-only" DLL that you can then LoadLibraryEx and FreeLibrary on demand.Quote:
Originally Posted by Ellis Dee
The bigger problem here seems to be the file size involved, which is easily mitigated by using a format other than BMP.
For best results, you'd want to combine multiple images into a single sprite sheet, then store the sprite sheet in a compressible format like PNG. This changes the way you retrieve the individual images, obviously, but I wouldn't be surprised if the size savings approached ~80-90%.
Gotta love those moving goalposts, hmm?
A downside of a huge imagemap is that making use of it still means expanding it to the full bitmap in memory.
Compression might still be an answer though, and almost always worth exploring. Consider converting each small image to PNG or even GIF if you can do it without loss of fidenlity.
Then you can go back to looking at resources, or develop your own ad-hoc file format. For example maybe just concatenate the compressed image files into one file, creating a directory (offset and length of each image in the BLOB), then append the BLOB to the end of this directory block.
Then if you normally use only a subset of this set of images random I/O can be used to retrieve only the ones you need. If you normally use most of them then the imagemap approach may make more sense.
However a GDI BITMAP (er, or is that a DIBSECTION?) can store images in their "original format" so GIF format may still save RAM if you will be keeping these around for use as BITMAPs. I don't know enough about GDI+ to know whether it can do the same for small PNGs.
I just now saved one of the bitmaps as a png file (using Paint) and then ran it through pngoptimizer.Quote:
Originally Posted by Tanner_H
Original bmp: 5238 bytes
"Clean" png: 3072 bytes
That's nice, but not nearly enough to bother with, I don't think. Right now the graphics folder (tree) with the 2837 bitmaps is 30,969,348 bytes. If that sample compression stays true, they'd shrink to 18,163,008 bytes. That's still much too big to stuff into an exe, and if we're talking about an external data file, the size on disk is largely irrelevant.
That's the initial thinking they're considering. It seems inelegant to me to zip/unzip bitmaps as needed instead of having a resource file you can LoadPicture from.Quote:
Originally Posted by dilettante
That sounds like something I would do, but I'm not sure they'd be into this.Quote:
Then you can go back to looking at resources, or develop your own ad-hoc file format. For example maybe just concatenate the compressed image files into one file, creating a directory (offset and length of each image in the BLOB), then append the BLOB to the end of this directory block.
Only a small subset, yes. Any given "session" will only use maybe a couple hundred, tops.Quote:
Then if you normally use only a subset of this set of images random I/O can be used to retrieve only the ones you need. If you normally use most of them then the imagemap approach may make more sense.
It's also worth pointing out that new sets of images (~40 at a time) get added occasionally, so it would be ideal if whatever solution supported easy maintenance.
Well have you considered ZIP archive format? InfoZip libraries should make retrieval easy enough and these are probably as easy as anything to maintain. Or even CAB format.
That's exactly what they're considering, yes.Quote:
Originally Posted by dilettante
This seems weird and inelegant to me, which is why I started this thread. But I don't know C++; if there's really no elegant way to bundle graphical resources outside of the exe, then so be it.
It was wise of you to test, but that's not an accurate representation of how sprite sheets work. (If the gains were that small, no one would go to the trouble of using them!)Quote:
Originally Posted by Ellis Dee
The gains of compression go up as the size and repetition of the source material increases. In a tiny single file, a good chunk of those bytes are simply headers and overhead. With each image that you combine into the single sprite sheet, you 1) reduce the need for duplicate headers for each image (which add up over ~300 files), and 2) you increase the repetition in the source file, since most images are likely using similar colors and patterns.
So the gains of a single image are not in any way indicative of the gains of the collection as a whole, condensed into a single sheet.
That said, you wouldn't generally do a single master sheet. You'd use a couple different sheets, divided up by where they are used in the program. Then you'd just swap in the sheets you actually need at any given time.
There are countless programs, sites, and scripts for generating sheets.
Excellent points.
I played around with one of those just to get a feel for it. Sprite sheets do indeed look like the simplest, cleanest way to go. And while they still don't crunch down small enough to pack inside the exe (first test took ~170k down to ~70k) that's irrelevant. Crunching 2800 images down to <100 images would be a total victory.
Most of the 2800 images are 32x32 icons for trees. There are around 65-ish trees with around 35-ish icons per tree. So that would take care of well over 2000 of the images, wrapping them into a mere 65 different files. (Each only around 70k? Win!)
Thanks much for the ideas, I appreciate it.