Building a small ZIP file:
Some maps take hours to compile so why not put a couple of minutes into making the .pk3 a bit smaller? It'll make the map less fun if people don't have to wait 2 minutes to play it.
I don't think anyone is trying to use Windows XP's built in archiver which is a good start but there are things beyond Winzip and zib which can push things further.
7-zip is very good at making small ZIP files, just remember to stick to zip, not 7z! The best way to run it on Linux is with the commandline port p7zip, also known as 7za. That way you can have full control over the parameters. There are many options and it is possible to brute force them all (I have done this before but it would take days for some map files) but the best way is to use the options that are most likely to give the smallest file:
- Code: Select all
7za a -tzip -mfb258 -mpass15 mapname.pk3 maps/*
That should give you the maps/ directory that the simplest pk3 would need. I've tried a few of the more popular maps and can get a couple of hundred kilobytes off of some of them this way. If that's 5 more seconds of gameplay for a few hundred people that seems worthwhile.
TGA images:
If you need an alpha channel, TGA is probably the best option but otherwise, why use it? Lossless compression is vital in some applications but Nexuiz isn't for analysing stellar spectra is it? There will always be errors introduced in the rendering of the map anyway, it only works by removing psychovisual redundancy so why not use lossy compression? The engine accepts textures regardless of their file extensions and if the textures are sourced from another artist, it's GPL, you can save it as another file type. I'd seriously think before saving anything in TGA unless you need an alpha channel. In some cases TGA could be smaller, ie, large contiguous regions, but most textures are numerically like photographs so would be smaller as JPEG's.
JPEG images:
The JPEG quality factor is purely arbitrary. 100% is meaningless and generally shows that you know nothing about JPEG compression. 95% might be worthwhile in some cases (perhaps lossless would be better in that case?) but generally 85% will be perfectly satisfactory. The file sizes you get are dependent upon your software. In my experience the GIMP is very good at compressing files and Photoshop can be terrible. This doesn't mean you shouldn't use Photoshop, it just means you'd be better off saving in a lossless format then letting a program that knows about image compression convert it to JPEG. At this stage, don't save as a progressive JPEG but do click any 'optimise' tickbox that may be available.
From here you can get some improvement by rewriting the huffman tables of the JPEG. This is lossless, it just rewrites the compression of the container and might improve it, if not, it'll leave it untouched. jpegoptim is a popular program for doing this under Linux:
- Code: Select all
jpegoptim [filename]
This rarely gives any improvement from the GIMP as they use the same libs. You can however use the --strip-all option to remove EXIF tags (like 'created by the GIMP') from the file. You may wish to leave these in though if you feel strongly about your artworks authorship.
Progressive JPEG's are normally smaller than standard JPEG's. This is where multiple rendering passes are taken to display an image. This will take more CPU power but not any enormous amount by modern standards. This conversion is lossless and is provided by jpegtran, a core utility of libjpeg. Perhaps it's not worth doing for textures due to speed concerns but it seems to have no speed effect upon screenshots for the maps menu adn may save a few Kb.
Sounds:
Not many maps are including sounds but they do have a lot of potential for improving a map. They also have a lot of potential for bulking out a pk3. Stereo is rarely necessary. For music it could be useful, announcers voices should be omnipotent so should stay mono and soundeffects would be downmixed to mono anyway as they'll come from a point source. You might as well keep them all mono unless you have any special need for a second channel. Quality wise, Vorbis is intended for variable bit rate and in general works a lot better that way than at a constant bit rate. UT200x uses 64kbps average and sounds alright for doing so but going up to 128kbps might sound slightly better, then again, how many people treat a game of Nexuiz as a good time to do a double blind comparison between different bit rates?
Some shorter sound effects could come out smaller as .wav files but this is rare. It has been speculated that they might be quicker to load but they will take up more disk time so might make it slower that way. I'd stick to Vorbis as download time is more important.
Sources:
Yes, the GPL says sources must be available but that does not mean that they must be provided in the same archive. You could post them somewhere else and just point people at them. This is unlikely to save you an enormous amount of space though as a .map file is human readable and easily compressible so I'd keep the .map file. It might make a difference though if you're including sources for other content.
The BSP:
BSP files are binary and therefore hard to compress. You could spend time removing unnecessary information from it which might save a bit but a larger amount would be possible if you are having to scale, then relight the BSP. If the scaling breaks the lightgrid, relighting might not fix everything. Instead light the map, then use two scaling phases that do work. No lighting bugs and the .bsp file will be smaller.
Hope this lot helps someone. Add to if you want.
*mod-edit* made sticky
Most users probably wouldn't have bothered looking through all of the cvars to find it.