I am designing a game that would benefit alot from a large variety of graphics. however i am cutting the graphics short, because of the large file size they take up. In the long run this will take away alot from the game.

I've noticed that Spiderweb Software's games have extensive amount of graphics, but the installation file is only 10MB. After installation the graphics folder reaches around 17- 18MB. I was wondering if anyone knew how this is possible, how spiderweb software manages this, and how I could go about doing the same thing. This would help me greatly improve my game because I do not want the download to go anywhere near over 10MB. Thank you for any help.

I think you are barking up the wrong tree here... there is no magical compression method that is going to make Spiderweb's graphics come out smaller than yours. Even if you used raw bitmaps in your game, when you zip those they will compress down to about the size a GIF or PNG would be.

One trick is to use 8-bit images, or a custom format that maps 8-bits of color info into 16-bit color space dynamically. That would save you 50% on file size.

Actually, there IS a way to reduce the size of graphics far below that of GIF/ZIP/PNG or 8 bit: using procedural graphics, as discussed in this (http://www.dexterity.com/forums/showthread.php?s=&threadid=1102) thread.

Depending on what type of game it is, it might be possible for you to use procedural graphics, but it will require you to remake all the graphics for the game.

I'm about to use JPEG compression in AF, which I imagine will shrink the game by about 3MB. I'll be stripping out the alpha channels and storing them separately as deltas, which zip down fantastically small.

I did an experiment with JPEGs: I grabbed a few sprites from my game and saved them at different levels of compression in Paint Shop Pro until I found the compression level at which they were no longer distinguishable from the PNG versions. In fact I've erred on the side of quality because most of the sprites are moving and the details are hard to see when they move. The end result is my graphics are less than 30% of their original zipped size.

Cas :)

Did you read this thread? http://www.dexterity.com/forums/showthread.php?threadid=1053

In my testing I was able to reduce an 8-bit PNG image file to be 24% smaller than a regular PNG without a single shred of quality loss. When an installer compresses it, the difference is more like 20%, but that's still enough. Has JPEG compression magically advanced since Photoshop 6? I tried to see if I could reduce a sprite smaller than a PNG, (or even the same size) but it was grossly unacceptable before I even got it near the same size as the commpressed PNG. Were you using 24-bit PNG's?

The original JPEG coding hasn't changed for years. It just works really well with our sprites, because a) we render all our stuff in 3dsmax anyway which tends to produce far more organic shading than artificially hand-pixeled artwork and b) separating the alpha channel is a crucial step because the inside of the sprite can be a bit more blurred but the edges still need to be perfectly defined and nicely antialiased.

Cas :)

Thanks guys for your help. I took what you said into consideration and at first thought you were nuts . :p I have been using a lot of gif image files, why? I'm not really sure... but what I found were these do not compress very well at all when zipped or anything. But 17 MB of bmp graphics for avernum compressed down to around 3MB... So my studies show that I should be using bmps like the rest of the world. It will take a long time to convert everything to bmps and a lot of changes will have to be made to the code. But am I right in saying that BMPs are excellent at compressing compared to gifs?

No, that's not really true. A gif in its raw form is very much like a BMP file. A standard compressed gif just uses LZW compression - very like normal zipping - to zip the raw data up. There's precious little difference between gifs and zipped bmps. The only real gains can be made with lossy compression such as jpeg, or sometimes using strange techniques like planar-delta encoding (I use this at the moment, compresses slightly better).

Cas :)

Originally posted by Mickey Crocker
[...]It will take a long time to convert everything to bmps and a lot of changes will have to be made to the code.[...]

Try the batch convert option of IrfanView (hotkey 'b'). You can convert tons of files at once, change color depth, change the format etc.

http://www.irfanview.com/ (it's free :))

Originally posted by Mickey Crocker
[...]But am I right in saying that BMPs are excellent at compressing compared to gifs?[...]

The compression ratio is better with bmps, because bmps aren't already compressed. The only thing wich really matters is the size of your installer... and that depends. I would say, that you should simply try what works best for your files.

Procedural images are probably the way to go if you are really, really concerned about download size. Here are some options:

Include your own raytracer on startup, and render on the user's machine. There is plent of open source code for rendering out there... and assuming you are rendering small sprites, it probably wouldn't take an extreme amount of time to render (AND, you can always offer the pre-rendered downloads for high-bandwidth people, and the rendering download for low bandwidth).

Use Direct3D as your renderer, and then save the images. Yes, old computers have a hard time with 3D graphics... but if all you are doing is loading a single model, rendering it with several camera angles, and then saving those images to bitmap, nearly any computer with Direct3D installed should be able to handle that. Then use your 2D bitmaps as sprites.

Use Vector drawings, like lunar lander, tempest, etc., etc... I have tested on my modest computer, and I can handle thousands of seperate rotating vectors all at once without the FPS ever going below my refresh rate (And my vector code is implemented poorly... someone could probably get 50-75% better performance if they really tried optimizing)... perfect for a slow computer. And vectors take up 32 bits per line for my system... or about 0.2k for a fairly complex vector drawing with 50 lines. Certainly a very space saving way of doing things. And once again, there are some tricks you could do to get things even less than that (I just didn't bother using them because what is the different between 0.2k sprite and 0.1k sprite, even on a modest machine).

I think all the useful stuff has been said already, but let me add something. In this thread (http://www.dexterity.com/forums/showthread.php?threadid=1053) I said exactly what I was doing, which is nothing really weird, actually. But I didn't post the numerical results. The resource file for BBB (http://www.mrio-software.com/info.php?id=bbb) is currently at 600 or 700 KB. Most of it are the animations for Betty, but there are several characters, too. Let's say it's 75% Betty, or 525 KB. Loading was slow so I implemented a decompression step, where the graphics are read and stored in the fastest way they can be loaded - raw data. Guess what? The Betty animations was around 10 MB. That's approximately 20:1.

As you see and as many others pointed here, Spiderweb is doing nothing extraordinaire.