RE: [GD-General] Building pak/zip files
Brought to you by:
vexxed72
Menu
▾
▴
RE: [GD-General] Building pak/zip files
|
From: Chris B. <Chr...@ma...> - 2001-12-13 06:21:55
|
I'm currently coding up a zip loader myself. I've been reading over the pkware docs, however I'm finding their descriptions to be difficult to nut out in some cases. I turned to some sample implementations on the net and now it's even more confused. The first thing I read was to walk the whole file, reading the local file descriptors as you go : http://epicboy.flipcode.com/tutorials_ZIP.htm eeek, I can't imagine this scaling to a large resource file! Then after reading the pkware docs, and using a little wisdom it seems more likely that the Central Directory is what I should be using. My intention is the build an STL map that maps file names to data offsets. To do this I need to find the beginning of the central directory, something which seems a little difficult. The only way I've found to do this so far is to jump back about 65k(assuming the file is that big) and then start reading forward comparing each byte to the header 0x02014b50. This might be a bit faster if I knew the tag was 4 byte aligned, but it still seems a little silly to find the main table by a random scan like this. Is there a better way? Many thanks Chris No picking on the disclaimer, it's added at the server. :) -----Original Message----- From: Gareth Lewin [mailto:GL...@cl...] Sent: Friday, 7 December 2001 7:49 AM 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 > NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. |
