Re: [GD-General] Building pak/zip files

[Tom S. <tsp...@mo...>]

> 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 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.
I believe the default operation of in calling winzip via the command line is
to add files ( -a ) to an existing archive.  With this in mind i think that
adding the files to a zip one at a time with the compression options set to
your liking ( -e ) would do everything that's been discussed here.  The
performance may be poor calling winzip once for each file to be added, so if
this is a problem look into using "list files" to batch multiple adds into a
single call.  Tom

----- Original Message -----
From: "Chris Brodie" <Chr...@ma...>
To: <gam...@li...>
Sent: Wednesday, December 05, 2001 5:11 PM
Subject: RE: [GD-General] Building pak/zip files


> Elaborate? I'm not sure I follow.
>
> I'm a lone developer with no art team but I still try to work as if I was
a small team. As such a team would want independence between the art
packaging tools and the coder releases. Perhaps I've missed something
though.
>
> Some idea's I've had overnight about this topic:
>
> Zip file tools don't generally give you control over what gets compressed
and what doesn't(I think). This means that some things that you don't want
compressed such as jpeg's or mp3's will need to be double compressed,
slowing load times on these files.
> Then again you can store all files uncompressed, so the zip file acts like
a pak file. In this case some simple things like wav's or large xml
documents(my level files for example) won't be compressed.
>
> It seems the solution to this problem is in either creating(hopefully
finding) a custom zip packing tool that allows you to specify 'store' or
'compressed' on each file or to use a custom file format, which for now I'm
resisting.
>
> In both cases memory mapped files seem to be the best access method for
pakfile style access. I've heard that the combination of pakfiles + memory
mapped files can give you effective loading speed increases of nearly 200%
above the normal C\C++ std functions.
>
> Chris
>
> > -----Original Message-----
> > From: Brian Hook [mailto:bri...@py...]
> > Sent: Thursday, 6 December 2001 4:09 AM
> > To: gam...@li...
> > Subject: RE: [GD-General] Building pak/zip files
> >
> >
> > > I was going to start looking at zip files sooner or later as
> > > well. Currently I just use pkzip to batch build my release
> > > files, I was going to do the same thing with the resources as
> > > well. Just maintain the assets on the file system as the
> > > first search point. Then check in the zip file. Pretty simple.
> >
> > Right, this is what we plan on doing.  We have an abstract FileSystem
> > class, and derived from it are a DiskFileSystem, ZIPFileSystem and a
> > wrapper called a ChainedFileSystem.  The latter does the "Check disk,
> > then check ZIP" type thing (you register FileSystems with it
> > in order of
> > priority).
> >
> > The issue isn't the ZIP file itself, it's automating the
> > build.  I could
> > make a batch file or a make file that builds the appropriate
> > ZIP, but I
> > was hoping there was maybe a slightly more elaborate tool than just
> > doing a Custom Build step in MSDEV and calling a batch file =)
> >
> > Brian
> >
> >
> > _______________________________________________
> > 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.
>
>
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general