RE: [GD-General] Building pak/zip files
Brought to you by:
vexxed72
Menu
▾
▴
RE: [GD-General] Building pak/zip files
|
From: Roland <ro...@wi...> - 2001-12-07 21:33:53
|
Hey ZIP gurus out there.... I wrote some of these 'file-system-in-a-zip' classes myself, but one thing bothered me a bit: according to the AppNote.txt there are several compression methods which could potentially be used by WinZip (et altera). The most common apparently are 0 (no compression) and 8 (deflate). What about the others? Is there code available which deals with them? Is it necessary to deal with them? I'm asserting wildly if the method is unknown (other than 0 or 8) and before I use a resource ZIP/PAK in release mode, I verify each file to be accessible. Of course this could all be avoided if I would generate the ZIP/PAK file myself and make sure that only 0 and 8 are used... which would mean YATTW (yet another tool to write)... What are you guys doing? cu roland > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On > Behalf Of > Brian Sharon > Sent: Thursday, December 06, 2001 2:04 PM > To: Gareth Lewin; gam...@li... > Subject: RE: [GD-General] Building pak/zip files > > > Ooops, you're right, I was going off the code in "unzip.c" > that ships with zlib (in the contrib\minizip directory) - > it seeks backwards because it's assuming that there might > be a comment field. But like you say, you should be able > to assume that you don't have comments in a game-based zip. > > --brian > > -----Original Message----- > From: Gareth Lewin [mailto:GL...@cl...] > Sent: Thursday, December 06, 2001 12:49 PM > To: gam...@li... > Subject: RE: [GD-General] Building pak/zip files > > Hmm, you might want to look at the zip file definition > again (http://www.pkware.com/support/appnote.html). > If you seek to the end of the file, make sure you don't > have comments or Zip64 code ( Both a logical requirement > for a game based zip file ) then the last 16 bytes will be: > <quote> > number of this disk: (2 bytes) > The number of this disk, which contains central directory > end record. If an archive is in zip64 format and the value > in this field is 0xFFFF, the size will be in the > corresponding 4 byte zip64 end of central directory field. > number of the disk with the start of the central directory: > (2 bytes) > The number of the disk on which the central directory > starts. If an archive is in zip64 format and the value in > this field is 0xFFFF, the size will be in the corresponding > 4 byte zip64 end of central directory field. > total number of entries in the central dir on this disk: (2 bytes) > The number of central directory entries on this disk. If an > archive is in zip64 format and the value in this field is > 0xFFFF, the size will be in the corresponding 8 byte zip64 > end of central directory field. > total number of entries in the central dir: (2 bytes) > The total number of files in the .ZIP file. If an archive > is in zip64 format and the value in this field is 0xFFFF, > the size will be in the corresponding 8 byte zip64 end of > central directory field. > size of the central directory: (4 bytes) > The size (in bytes) of the entire central directory. If an > archive is in zip64 format and the value in this field is > 0xFFFFFFFF, the size will be in the corresponding 8 byte > zip64 end of central directory field. > offset of start of central directory with respect to the > starting disk number: (4 bytes) > Offset of the start of the central directory on the disk on > which the central directory starts. If an archive is in > zip64 format and the value in this field is 0xFFFFFFFF, the > size will be in the corresponding 8 byte zip64 end of > central directory field. > </quote> > Also you should be able to assume that you don't use > multidisk spanning. > _____________________ > Regards, Gareth Lewin > Lead Programmer > Climax Development > Fareham Heights > Standard Way > Fareham > P016 8XT > > > -----Original Message----- > > From: Brian Sharon [mailto:bs...@mi...] > > Sent: 06 December 2001 18:47 > > To: Thatcher Ulrich; Tom Spilman > > Cc: gam...@li... > > Subject: RE: [GD-General] Building pak/zip files > > > > > > Things like WinZip will (by default) try to compress > > everything, so you > > would want to set command line flags to disable compression for > > uncompressible things like sound files. > > > > And I can't imagine a zip implementation that wouldn't add > > files to the > > end of the zip in the order that you insert them, because the > > alternative (shifting files down) would be so inefficient. > > > > But the worst part of zip files is that the catalog lives at an > > unspecified distance from the end of the file, so opening > an archive > > means seeking to somewhere near the end and walking > around looking for > > the catalog. If you're really worried about speed, you > > probably want to > > have a post-process step where you generate another copy of > > that catalog > > in a spot where it can be loaded quickly...like placed on the > > DVD, right > > in front of the zip archive. > > > > --brian > > > > -----Original Message----- > > From: Thatcher Ulrich [mailto:tu...@tu...] > > Sent: Thursday, December 06, 2001 6:21 AM > > To: Tom Spilman > > Cc: gam...@li... > > Subject: Re: [GD-General] Building pak/zip files > > > > On Dec 05, 2001 at 05:41 -0600, Tom Spilman wrote: > > > > Zip file tools don't generally give you control over what > > > > gets compressed and what doesn't(I think). > > > > > > Actually i don't think this is necessarily true > > > > It doesn't actually matter -- zip tools generally will > choose the best > > method of compression for each file, so .jpg's or .mpg's will be > > stored uncompressed. > > > > > nor that you cannot > > > specify the order of the contents of the zip file. Check out > > > http://www.winzip.com/wzcline.htm which adds command > line support to > > WinZip. > > > > Infozip's command-line zip apparently stores things in > the order you > > specify. Also, it's open source under a X-style license, > so you can > > hack stuff in or incorporate the code in your project. > There's also > > zlib from the same project, designed for embedding. We > use zlib at > > Oddworld for unpacking resource files. > > > > http://www.info-zip.org/ > > http://www.gzip.org/zlib/ > > > > -- > > Thatcher Ulrich <tu...@tu...> > > http://tulrich.com > > > > _______________________________________________ > > Gamedevlists-general mailing list > > Gam...@li... > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > > > > _______________________________________________ > > Gamedevlists-general mailing list > > Gam...@li... > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general > > > > _______________________________________________ > Gamedevlists-general mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general |
