RE: [GD-General] Building pak/zip files
Brought to you by:
vexxed72
Menu
▾
▴
RE: [GD-General] Building pak/zip files
|
From: Brian S. <bs...@mi...> - 2001-12-06 22:03:37
|
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...]=20 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).=20 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>=20 number of this disk: (2 bytes)=20 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)=20 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)=20 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)=20 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)=20 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)=20 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>=20 Also you should be able to assume that you don't use multidisk spanning. = _____________________=20 Regards, Gareth Lewin=20 Lead Programmer=20 Climax Development=20 Fareham Heights=20 Standard Way=20 Fareham=20 P016 8XT=20 > -----Original Message-----=20 > From: Brian Sharon [mailto:bs...@mi...]=20 > Sent: 06 December 2001 18:47=20 > To: Thatcher Ulrich; Tom Spilman=20 > Cc: gam...@li...=20 > Subject: RE: [GD-General] Building pak/zip files=20 >=20 >=20 > Things like WinZip will (by default) try to compress=20 > everything, so you=20 > would want to set command line flags to disable compression for=20 > uncompressible things like sound files.=20 >=20 > And I can't imagine a zip implementation that wouldn't add=20 > files to the=20 > end of the zip in the order that you insert them, because the=20 > alternative (shifting files down) would be so inefficient.=A0=20 >=20 > But the worst part of zip files is that the catalog lives at an=20 > unspecified distance from the end of the file, so opening an archive=20 > means seeking to somewhere near the end and walking around looking for = > the catalog.=A0 If you're really worried about speed, you=20 > probably want to=20 > have a post-process step where you generate another copy of=20 > that catalog=20 > in a spot where it can be loaded quickly...like placed on the=20 > DVD, right=20 > in front of the zip archive.=20 >=20 > --brian=20 >=20 > -----Original Message-----=20 > From: Thatcher Ulrich [mailto:tu...@tu...]=20 > Sent: Thursday, December 06, 2001 6:21 AM=20 > To: Tom Spilman=20 > Cc: gam...@li...=20 > Subject: Re: [GD-General] Building pak/zip files=20 >=20 > On Dec 05, 2001 at 05:41 -0600, Tom Spilman wrote:=20 > > > Zip file tools don't generally give you control over what=20 > > > gets compressed and what doesn't(I think).=20 > >=20 > >=A0=A0=A0=A0 Actually i don't think this is necessarily true=20 >=20 > 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=20 > stored uncompressed.=20 >=20 > > nor that you cannot=20 > > specify the order of the contents of the zip file.=A0 Check out=20 > > http://www.winzip.com/wzcline.htm which adds command line support to = > WinZip.=20 >=20 > Infozip's command-line zip apparently stores things in the order you=20 > specify.=A0 Also, it's open source under a X-style license, so you can = > hack stuff in or incorporate the code in your project.=A0 There's also = > zlib from the same project, designed for embedding.=A0 We use zlib at=20 > Oddworld for unpacking resource files.=20 >=20 > http://www.info-zip.org/=20 > http://www.gzip.org/zlib/=20 >=20 > --=20 > Thatcher Ulrich <tu...@tu...>=20 > http://tulrich.com=20 >=20 > _______________________________________________=20 > Gamedevlists-general mailing list=20 > Gam...@li...=20 > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general=20 >=20 > _______________________________________________=20 > Gamedevlists-general mailing list=20 > Gam...@li...=20 > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general=20 >=20 |
