graphic filesize

[Mickey Crocker]

The project I am currently working on will have quite a few image files. But I'm not sure which file type is the best to use between "gifs" or "Bmps".

I don't really care how large the filesize of my game will be when it is installed, but I'm trying to find which of the two image file types compress better with innosetup.

Gifs tend to be smaller filesize then BMPs... (but do they not compress as well as BMPs?)

The reason I ask this is because Spiderweb Softwares games tend to use hundreds of BMPs that extract out to over 35MB-40MB after installation. However, there game's installation programs are only around 10-15MB.

Would it be better to use BMPs, or would I find better results with Gifs.

(P.S. I know that gifs are lower quality (256 colors), and that is all my game really requires.)

[EpicBoy]

Why not look at PNG files? They're already compressed and don't have any color depth limitations...

[Diragor]

You should really test with both. There are options in the bmp format (color depth, RLE) and the nature of your graphics will make a difference. Generally, the smaller the graphic files are to start with, the less they will compress in an installer, so it may be a wash in the installer size.

On a side note, those are just about the last two formats I'd choose to use in a game. May I ask why those are the two you're considering?

Edit: I was thinking the same thing as EpicBoy: png.

[Mickey Crocker]

Never really heard about png files.

I'll give them a shot and see if I can shrink my game's size down a bit.

Thanks.

[oNyx]

Try PNGOUT (http://advsys.net/ken/utils.htm) for PNGs and be sure to use the proper switches.

Well, all that counts is the size of your installer. Sometimes really cheap file formats turn out to be pretty small once compressed. You also might want to try some non compressing archive [used by your game directly], which you compress with something strong like 7z. Yea, I know... that sounds pretty odd, but it yields by far the best compression (especially if you have lots of tiny files). There is also another benefit - loading times are really short, because you stuff is in one place (and doesn't need to be decompressed).

[Mark Fassett]

One thing with using PNG's and inno setup is that they likely won't compress very well at all when creating the installer. In Derelict, I used 8-bit TGA's for storage (they convert up at runtime to whatever bit depth). The 7-zip comression algorithm works really well on them, but won't hardly do anything if they're already compressed, and you're likely to get better compression out of 7-zip.

[princec]

I'm having a lot of success with high-quality JPEG.

Cas :)

[James C. Smith]

I definitely think JPEG is the way to go. The biggest annoyance is that you have to store your alpha channel separately. We have the artists supply the art a 32 bit TGA images and then use an automated tool to convert the image to a proprietary file format which compresses the RGB using JPEG compression and the alpha channel is compressed using a combination of delta encoding and ZLIB. Tests show this to be more effective that the compression done by InnoSetup if we leave the alpha channel uncompressed. Of course, there is nothing InnoSetup can do to the RGB part of the image that comes even close to what JPEG can do. But you do have to be careful to use a high quality JPEG encoder. We use ImageMagick usually with a quality setting of 90 but the exact quality level is adjusted for each piece of art. Some of them still look great at 60. We previously used some other JPEG library which gave horrible results even at the high quality setting. The images always looked washed out. At first we just thought that was the price of using JPEG compression until our artists showed us that PhotoShop could make a better looking JPEG with a smaller file size. We dumped the crappy JPEG encoder and found ImageMagick is just as good as PhotoShop.

[princec]

Exactly what I did. I use the Sun JDK's built-in compressor at quality .95 which seems to be perfect.

The more sprites you can pack into a single image the better, too, and JPEG the lot in one go.

Cas :)

[tentons]

I like PNG, but Photoshop simply can't handle them. It either won't save the alpha channel properly, or it drastically alters the gamma. Do other packages have this issue? (I've tried a couple of plugins, but there's always some amount of alteration to the resulting image that isn't acceptable to me.)

I'm considering using BMP with alpha or TGA with alpha. I'll be leaving them totally uncompressed and then compressing the install files with 7zip for the best results. Hardrive space isn't much of an issue after installation.

[oNyx]

>Do other packages have this issue?

No. Well, it's a PS bug... it just likes to save the wrong brightness setting. I think pngout has a switch to remove that gama setting alltogether. But it's usually no big deal, because most loaders just ignore it.

You could for example just use irvanview's batch convert (it produces smaller PNGs than Photoshop 6.0).

However, 7z 'em should result in about the same filesize (often it's even a bit smaller).

Oh and there is more to JPG than just the quality setting. Progressive is usually a bit smaller and 1px brightness looks sometimes much better than the default 2px (without taking much more space). Afaik Photoshop and other advanced imaging packages do that automatically if you use a high quality setting.

[Igmon]

GIF format is patented isn't it?

In my opinion, the best to go with is either BMP or PCX. That's because they're the easiest to implement ;)

[Dom]

I would chuck a vote in for PNGs. We now use them exclusively. They don't zip well afterwards, but they sure compress well to start with ;)

More importantly for us, they support full 8bit alpha. Paint Shop Pro also does an extremely good job at outputting them. i have tried using various PNG optimising tools on the output and they have never managed to compress better than the normal PSP output.

Add to this the fact that Libpng is free, and easy to use, and you have yourself a winner!

[mrfun]

Just a note, you can install a free plugin called SuperPNG (http://www.fnordware.com/superpng/) to get Photoshop to save PNG's with alpha correctly.

[tentons]

GIF format is patented isn't it?
The patent expired recently, IIRC. But it's limited to 256 colors and no alpha, anyway.

[Chigley]

I like TGAs. They are a raw data format, no compression. When you package your game up for distribution, I assume you use some compression scheme, like ZLIB or LZMA. So, if you don't care about installed file size, your packager will get it as small as possible anyway.

Of course, if you do care about installed size, then PNGs are a decent middle ground, with some compression up front, and a bit of gas to compress down when packaging.

[kevryan]

I've had no problems with PNG using Photoshop 5.0, but Photoshop 5.5 will sometimes give me problems. I've read that the later versions of Photoshop have problems with PNG. Also there are two versions of SuperPNG and they each handle the alpha channel slightly differently.

[Matthew]

There are techniques out there to use regional compression with JPEGs (more destructive compression in bland areas of the image, less destructive for detailed areas). You can create weighted files that are still JPG compatible; you don't necessarily have to jump to JPEG2000. Here's an overview article I just Googled:

http://www.websiteoptimization.com/speed/tweak/weighted/

JDO from xat is a useful command-line tool with automatic weighting:

http://www.xat.com/jdo/index.html

And as another note, PNG files have comparatively sizable headers. It adds up if you're dealing with a huge pile of tiny files. 8- or 16-color GIF files work well for storing alpha channels, in my limited experience with image file size optimization.

[Lerc]

And as another note, PNG files have comparatively sizable headers. It adds up if you're dealing with a huge pile of tiny files. 8- or 16-color GIF files work well for storing alpha channels, in my limited experience with image file size optimization. A related note to this. If you are storing files inside a compressed package (or only care about download size) then BMP is just as good, usually better than PNG. The data still gets compressed, just at a different stage. A zipped bunch of BMPs is usually smaller than the same images in PNGs because of the compression of the headers.

[milo]

Just a note, you can install a free plugin called SuperPNG (http://www.fnordware.com/superpng/) to get Photoshop to save PNG's with alpha correctly.
Could you elaborate on that?

I grabbed SuperPNG from the link in your message, unzipped and installed the plug-in into my Photoshop 7 Plugins folder, and removed the original Photoshop PNG plugin to a safe location. I then created a new image, filled it with a metal plate texture, added an alpha channel (using the Channels tab, not as a Mask layer), and filled the alpha channel with a gradient. Finally, I saved the document using the SuperPNG file type, which had Alpha Channel pre-checked and disabled.

But! First Photoshop complained that not all features of the image had been saved because the selected file format couldn't support them. And when I reloaded the image, the Alpha channel was filled with solid white.

I'd love to be able to make this work...

Thanks,

--milo
http://www.starshatter.com

[Reactor]

Saving bitmaps and compressing them in a 7zip is a bad idea. Once you extract them, your game will suck down a ton of HD space. Like James C. Smith, we go with jpegs, unless the colour doesn't come through, and then we save the textures as pngs (which are usually slightly larger, but handle certain colours better). Having a dual 'before and after compression' save dialogue makes saving and seeing the results very easy. I personally use PhotoImpact, which makes saving to the right format, and getting the compression right, a breeze.

[princec]

With the average computer now packing gigs and gigs of harddisk space, mostly full of pr0n and cached internet rubbish, I don't think a couple of extra megs of graphics from an indie game is going to hurt too much.

The only sound reasons I can see for JPEG compression are bandwidth savings - and for that, they're second to none. Well, except JPEG2000.

Cas :)

[Reactor]

I don't know... I'm still not a big fan of unpacking a 2meg game into a 60meg installation directory.

[tentons]

I don't know... I'm still not a big fan of unpacking a 2meg game into a 60meg installation directory.
If I could get that kind of ratio, I sure wouldn't complain. :D

[Vapouraid]

None of this discussion has anything to do with Rag Doll Kung Fu. I want this thread closed.

[Reactor]

Vapouraid, it's okay to disagree with people (as I did in this thread, in your defence- http://forums.indiegamer.com/showthread.php?t=842) but there's no need to be a git about it.

[oNyx]

I don't know... I'm still not a big fan of unpacking a 2meg game into a 60meg installation directory.

60mb is a whopping 0.05% of a usual 120gb hdd. It's not likely that anyone would care.

However, the ratio is more like 1:4 to 1:10. If you have lot's of tiny files it's benefitical to use an archive without compression on the client side (eg your stuff->stored zip->7z installer). This way you avoid the "snap to clustersize" bloat (the smallest space a file can take equals the clustersize [usually 4k]).

Most people prefer short loading times over space savings. I'm also like that, but I was unaware of that in the past. It's like... y'know at the end you have some icons on your desktop and you remember how long these games load. So if you want a quick game you'll pick one which loads quickly. However, you don't remember how much space they take, because it doesn't matter.

Keep in mind that you are a technical person, who cares about those numbers, but most people don't. They just aren't interested in these things and they are unable to set it into relation. All that matters to them is what they can perceive - framerate, glitch free, loading times, sound, responsiveness... and yea, that's about it. They won't look into your game directory, the don't use explorer's detail view, they won't check the filesize and they won't be able to tell if you've used the space efficiently or not.

[Jim Buck]

Whoa, I don't know what market your games are for, but not even my development machine at work has anywheres near 120gb in hard drive space. (More like 75gb, and I would consider that pretty high-end.)

Not that I consider 60meg a lot, but if someone owned a "typical home system" (whatever that may be), they would probably appreciate a game not taking radically more space than it needed to. (.. especially with all the crap people have on their computer these days taking up lots of space - browser cache, pr0n, spyware, etc..)

[oNyx]

That was just an example. With a 20gb hdd it would be 0.3%... still no big deal. "But you can only install 300 games"... seriously no one cares ;)

The biggest shareware game I found on my PC is ~80mb and well... it's highly unlikely that I will ever produce so much content for a single game (raw textures, pcm sound effects, ogg bgm).

>if someone owned a "typical home system" (whatever that may be), they
>would probably appreciate a game not taking radically more space than it
>needed to.

Yea, of course someone would apprciate that... if you put it like that :)

"Do you think it's good to wast space?" - "Hell, no!"

But think about it. Do you need some kind of basic 3d acceleration? If so the pc will have at least a 3-10gb hdd. If you also need about 500mhz there will be a hdd with 10gb or more. If the hdd had to be replaced within those 5 years there will be even more space.

And another thing... how many games will your average customer have installed at the same time? They won't install hundrets of games. If they run out of space and decide to delete your game... would they have bought it? Of course not, they would have deleted the other games (or "browser cache, pr0n, spyware, etc") instead.

Having said that, I'm going to "waste" about 15-20mb. Uh uh... that's like 3-4 hi-q mp3s.

[Reactor]

That was just an example. With a 20gb hdd it would be 0.3%... still no big deal. "But you can only install 300 games"... seriously no one cares

Part of the problem with what you're saying is, you're assuming everyone in the world thinks the way you do. In fact, your posts are littered with innacurate assumptions. You have a couple of guys saying, "We prefer it when games aren't a lot larger than they need to be extracted." and, if a couple of guys have an issue with it, it's fairly reasonable to assume that some percentage of your current (or future) customer/gamers will have an issue with it too. So, assuming that everyone has the same mindset as yourself about the issue might not be the best of moves.

[oNyx]

>Part of the problem with what you're saying is, you're assuming everyone in
>the world thinks the way you do.

Actually, I kinda asume that "everyone" (the majority) thinks the opposite way I do. If you make downloadable games you care about the size of the download, as a webdesigner you care about the size of the graphics and the markup. Who else cares about those things?

>In fact, your posts are littered with innacurate assumptions.

Obviously.

But how often did you hear someone complaining about the size of the installation (forums, reviews, discussions and the like)? I read a review where the author complained about that... once. That was about 4 years ago and the installed game was bigger than 1.5gb.

Did anyone complain about the size of Gish? The textures are tga, the soundeffects wav and the music is ogged. The installed demo is ~27mb in size. Many games are like that, but no one complains. Even you didn't, do you? (go ahead and check the size of some games, you've installed)

[Reactor]

It's interesting how you mock me here,


Obviously.

And then say,


Even you didn't, do you? (go ahead and check the size of some games, you've installed)

Again, as I said, you make another innacurate assumption. For the record, I check many of the games and programs I install, because I work with video and require a certain amount of space to work with. It's true that it's hardly an issue for me downloading a small game and having it extract to a small directory, but that wasn't the point. If I saved all of my game's textures as bitmaps (or some other low-compression, large format) my game would blow out to 2-300megs. Not all indie games are tiny 2meg things, and so, you're original justification to saving in that larger format isn't always the wisest of things to do, in all cases.

To add to this, you assume that gamers in general don't care about installation sizes unless they're ultra huge. Yet, you have two guys saying "Um, it does bother us." My point was simply that it is often a better practice, since you don't know who it is you're selling to (and what they require in the way of space on their HD) to minimise the size of your installation directory. After all, if I download a 2meg game, and expect to only require a slightly larger directory to install it into, I'm often dissapointed when I discover some games blow out and take of large amounts of space. While gamers don't always complain about their installation sizes, almost all of them feel much better if a great game uses less installed real-estate.

Please don't assume I only care because I'm some special case developer. I'm not. I know of many gamers who are watchful of the same thing, and I think it's a fair point to take into consideration.

[Jim Buck]

It could also be that noone complains about the size of the download since they cancel the download once they see how big it will be and move on to download some other game. There is an indirect correlation between file size and number of downloads.

[oNyx]

@Reactor

>Again, as I said, you make another innacurate assumption.

"Even you didn't, do you?" - That was question. Faulty grammar, but still a question ;)

>If I saved all of my game's textures as bitmaps (or some other
>low-compression, large format) my game would blow out to 2-300megs.

A 24bit 512x512 texture is 768kb in size. It would take ages to fill up 300mb with content (390 512x512 textures... yea sure). A 2mb archive could only "blow up" to 30-40mb if the textures are really cheap (cheap enough that you could have used an indexed format instead).

>Not all indie games are tiny 2meg things, and so, you're original justification
>to saving in that larger format isn't always the wisest of things to do, in all
>cases.

I currently aim for 5-7mb (which ends up as 15-20mb on the hdd).

>To add to this, you assume that gamers in general don't care about
>installation sizes unless they're ultra huge.

Well, yea show me a review of a shareware game where the reviewer complains about that :)

You also made "innacurate assumptions". You think it's more important for the user to save some mb hdd space instead of shorter loading times. You also asume that the genre doesn't matter. It does. With playing times ranging from one minute (for one level) to "as long as you like", loading times are important and I get a huge speed gain by using a raw texture format like tga (more than 10 times faster [could be less with C/C++]).

@Jim Buck

It's not about the download size, it's about the size of the installation. Like 5mb download takes 17mb hdd space at the end.

[Reactor]

A 24bit 512x512 texture is 768kb in size. It would take ages to fill up 300mb with content (390 512x512 textures... yea sure). A 2mb archive could only "blow up" to 30-40mb if the textures are really cheap (cheap enough that you could have used an indexed format instead).

Yeah, good point. I did say textures, but there are a number of other things as well. Also, I must have had my head screwed on backwards when I said that- 300megs is... well, insane ;)


loading times are important and I get a huge speed gain by using a raw texture format like tga

It's a trade-off. There are times when it can be beneficial, and other times when the difference will be so minimal, it just isn't worth it.

[oNyx]

>It's a trade-off. There are times when it can be beneficial, and other times
>when the difference will be so minimal, it just isn't worth it.

Indeed. Well, it just looks like the best option right now. Using a compressed format like png or jpg results in quite alot of "converting friction", which I really want to avoid. Loading the bytes, put it into an Image object, pull out the raster, put it into a ByteBuffer, push it through OpenGL... it's just... plain silly, really slow and a lot of memory allocation/deallocation is involved.

So... yea, it was a pretty easy (obvious) decision in my case. Eventually I should have pointed that out earlier. Another assumption I made is that the user has a somewhat balanced pc configuration like 500mhz, 128mb ram, geforce1 (or 2mx), 10-12gb hdd or 800mhz-1ghz, 256-512mb ram, geforce2gt or better, 20-40gb hdd. Big fluctuations are just unlikely (or in many cases technically impossible due to incompatibilities).

The nice thing is that I could reverse the packaging. A "stored" installer with "max" gzipped TGAs. The installer would be some bytes bigger, used disk space is about the size of the installer and loading times should be a bit slower, but still a lot faster than using PNG (despite the fact that the compression ratio is about the same or even better).

[EpicBoy]

I agree with him though. Hard drive space is cheap these days. It's not even a real concern to worry about for most professional development teams. The days of compressing all of your data to save disk space are over.

Load times and installation distribution are the only real concerns and arguments for compression left, and with hard drives getting faster every year even the load time issue is vanishing.

[andyb]

But this is the same argument others use for using DirectX9 or the latest OpenGL functioanlity. Not everyone buys a new PC every year (or can afford to) to take advantage of all the new technology. So why assume that all users, even though they may not have the latest graphics drivers or fastest processors, will have the biggest and fastest hard drives around?

[EpicBoy]

Because they don't need the biggest and fastest. Any hard drive produced in the last 5 years is going to be of sufficient size and speed to make this a non-issue.

[oNyx]

>Not everyone buys a new PC every year

I target 5 year old hardware, which usually has 10gb hdd space (or more) and a reading speed of 15-25mb/s. I also plan to use 20mb (at most). Even if the machine is pretty unbalanced (eg build out of spare parts) and has only a (for that time) tiny hdd like 5gb, it would still only take 0.4% of the capacity... and if it's also incorrectly configured (running with a slow pio mode), it would still only take some seconds to read those 20mb.

Even if you put that "plan to use" space at 80mb, it's still very fast. Most shareware games that take a while to load either generate stuff or do a lot decoding.

edit: ye, beat me to it ;)