ZDoom

Then it was changed only in the VC++ project but not the CMake version.

$ unzip -lv zdoom.pk3
Archive:  zdoom.pk3
 Length   Method    Size  Ratio   Date   Time   CRC-32    Name
--------  ------  ------- -----   ----   ----   ------    ----
    3176  Unk:014    1321  58%  02-28-09 21:38  135954ff  acs/strfhelp.o
   10628  BZip2      2594  76%  12-06-08 10:22  5fbb01b8  actors/actor.txt
    1433  Defl:X      391  73%  09-14-08 06:44  3cce5f1f  actors/chex/chexammo.txt
[...]

[quote="Graf Zahl"]The program that creates zdoom.pk3 already can do LZMA and BZip2 but doesn't use these for zdoom.pk3.[/quote]
Actually, it does:
[code]
$ unzip -lv zdoom.pk3
Archive: zdoom.pk3
 Length Method Size Ratio Date Time CRC-32 Name
-------- ------ ------- ----- ---- ---- ------ ----
3176 Unk:014 1321 58% 02-28-09 21:38 135954ff acs/strfhelp.o
10628 BZip2 2594 76% 12-06-08 10:22 5fbb01b8 actors/actor.txt
1433 Defl:X 391 73% 09-14-08 06:44 3cce5f1f actors/chex/chexammo.txt
[...]
[/code]

The program that creates zdoom.pk3 already can do LZMA and BZip2 but doesn't use these for zdoom.pk3.

And I doubt that this is going to change. I suspect that at some time zdoom.pk3 will switch to 7z format because it's far more efficient with data that consists of a large number of smaller text files.

Recompressing the current zdoom.pk3 from Zip to 7z shrinks its size from 445864 to 288875.

[quote="Blzut3"]I'm curious as to if the zdoom.pk3 compression program has been updated to use these formats or if they are actually worse than LZMA, bzip2, and DEFLATE in most cases?[/quote]
If you change the compression method of zdoom.pk3, you make it unreadable by Slumped.

[quote="Graf Zahl"]Skulltag sure won't like this:[/quote]
Where do you see that? :p
[quote="Blzut3"]I'm curious ... if they are actually worse than LZMA, bzip2, and DEFLATE in most cases?[/quote]
Shrink is the same LZW compression used in GIFs. Just as PNG beats GIF, so to do any of the LZ77 variants ZIP supports beat Shrink.

Implode is basically a less "refined" version of Deflate. Like Deflate, it's LZ77, but its smaller window and use of mixed Shannon-Fano and fixed-length bit codes instead of strictly Shannon-Fano/Huffman codes for everything means that it will probably never beat Deflate except for contrived cases designed to let it win.

The Zipdir program has not been updated. These are old and rather inefficient compression algorithms that are no longer actively used. Deflate is just better in almost all situations. They are merely supported so that old Zips from /idgames can be loaded.

Regarding the LGPL, don't forget its precise wording! You can not use this code inside a closed source binary without jumping through hoops to comply with it because the end user must be able to recreate the binary with a changed version of the LGPL code. Or you may just stick to the first revision of explode.cpp...

[quote="Graf Zahl"]Skulltag sure won't like this:

/* SetCodeLengths() and DecodeSFValue() are from 7-Zip, which is LGPL. */

:mrgreen:

(not that I care...)[/quote]
I thought 7-Zip was public domain? (Or does the current version not have those functions.) Also, contrary to what you may think, we have nothing against releasing free open source software. In fact we are releasing our own [url=http://skulltag.com/forum/viewtopic.php?f=1&t=18506]GPL server browser[/url] since we don't have the source to IDESE.

I'm curious as to if the zdoom.pk3 compression program has been updated to use these formats or if they are actually worse than LZMA, bzip2, and DEFLATE in most cases?

First I downloaded the entire archive with an FTP manager and then I wrote a tool that loads a zip, prints information about each entry, then wrote a small batch that ran it over all files in the archive and then I loaded the output into a text editor and searched for the information I was interested in.

There were exactly 4 Zips which contained WADs that were Shrunk, approx. 50-100 (I didn't count) that contained Imploded WADs, none that uses BZip2, LZMA or Reduce for anything. There were also 20 or so Zips which contained Shrunk text files.

[quote="Graf Zahl"]FYI, I just checked the entire levels/ directory of /idgames.[/quote]
I've seen you say things like that before when looking for DECORATE issues or something. My question is, how do you manage to check every one of those thousands of files? Presumably it's not a manual check.

FYI, I just checked the entire levels/ directory of /idgames.

There's quite a few files which use Implode as their compression algorithm and a handful that use Shrink - mostly for text files but even for some WADs. However, there is not one single file in there using one of the 'reduce' methods so maybe they really aren't worth bothering.

Skulltag sure won't like this:

/* SetCodeLengths() and DecodeSFValue() are from 7-Zip, which is LGPL. */

:mrgreen:

(not that I care...)

Okay, I added Shrink support. (Good thing the LZW patent has expired!)

Reduce, however, that code indicates has only been partially tested, and since PKZIP 1.1 doesn't support Reduce (though it does support Shrink and Implode), I would prefer to have a real-world Reduced file to test with before adding it.

Since that linked code also contains decompression routines for the other old methods Shrink and Reduce, wouldn't it make sense to make ZDoom's Zip reader feature complete? I have to admit though that I haven't found and Doom relates Zip which uses these 2 methods yet.

Thank god!

I would have given up on the Info_Zip code. The function call interface of it is nearly impenetrable.

I found some much easier to understand code from [url=http://www.cs.tut.fi/~albert/Dev/gunzip/]GunZip.c64[/url].