Distributing Quake maps (long-ish, wordy and rambling :)

Tom Wheeley (tomw@tsys.demon.co.uk)
Sun, 10 Mar 96 13:16:25 GMT

Date: Sun, 10 Mar 96 13:16:25 GMT
From: Tom Wheeley <tomw@tsys.demon.co.uk>
To: quake-editing@nvg.unit.no
Subject: Distributing Quake maps (long-ish, wordy and rambling :)

In article <Pine.LNX.3.91.960310075200.979D-100000@portal.atak> you write:

> On Sun, 10 Mar 1996, Tom Wheeley wrote:
> > At the minimum I am proposing is a tool not dis-similar to DeuSF or DeuTex
> > which is run locally by the end user. This will process a list of textures
> > which the program `statically links' into a final BSP file.
> This is a good idea, but it shouldn't be too slow, otherwise we will get
> 'binaries' distributed versions of levels as well as 'source' versions.

The test maps are only a meg, so my guess is a max of about 10s on my 386sx
(I'm in a similar position to Raphael -- can't play the damn game ! :)
This time would be larger for more textures. There is (currently) a max of
256 textures now. I don't think it is a significant step, timewise. Slower
than PKUNZIPping the file, probably, but not meaningfully so.

> >
> > This control file could be designed in 3 ways.
> >
> > . structure based, and thus virtually unmaintainable by humans, but easy
> > for programs to fiddle with.
> > . text file, for the most part using the `texture numbers' (for more info
> > on how the textures are referenced, see Quake Specs). This would be
> > created by the map editor, which would interface with the user with
> > the texture names
> > . text file, but uses the texture names when specifying sources. This
> > would be the slowest (but not that slow) to process. It would be easily
> > maintainable by humans though :)
> >
> Or, it could be structure based, but created from a file using the 3rd
> format, for the best of both worlds.
> > Unfortunately, the only magic which can be tested for is for the BSP files and> > so no-way could be established for checking that a miptex lump _is_ a miptex
> > lump (without checking the size difference of the offsets, possibly). Thus
> > raw .MIP (or whatever) files would have to be outlawed, they would have to
> > start with the very simple multiple MIP header (as per the beginning of the
> > miptex lump) of size 1.
> Why not use a different format completely (like BMP or GIF or something)?
> This would probably result in minimal work for level designers and level
> editor programmers, and make the distributed level format more portable
> in the case of the Quake structures changing format.

Well, the texture designers have to create the MIP textures, which are scaled
by 1/2/4/8 respectively. It is up to the texture editors to convert from BMP
or GIF. I don't want to have to use multi-image GIFs here.

> > This idea of processing at the users locale could possibly be extended to the
> > creation of the various abstract stuctures which comprise most of the rest of
> > the .BSP file.
> However, I think that this would slow down the local processing time too
> much, leading to separate binary and source distributions.

It depends on the how fast it is to create some of them. f.e. if a
particularly large lump was quick to process, it would be prefereable to
process this at the end, rather than distribute a large lump. Remember that
`binary' distributions are illegal, and are currently blocked from ftp.cdrom.com
This is just a _possible_ extension, anyway.

> > The MakeTex itself would be in the PAK as Entry 'MakeTex'. Other (possibly
> > standardized) entries could be made such as `Author', 'Description', 'Licence'> > etc. These could be displayed by the MakeTex program.
> I'm not sure if this is completely necessary. If the format of the levels
> within the distributed PAK file is going to be different than in standard
> Quake BSP files, why not simply put the data as part of the new
> distribution level format?

Umm, I'm not entirely sure what you mean. The MakeTex will build a `standard'
BSP file from the more general information in the PAK file. There is no
good place to put `unneccesary' information in the BSP file, as there is in
the PAK files, which have a more complicated directory. You can only put
things in gaps, (like QEU does with version info)

> > There is then the small dilemma of whether to have MakeTex work on the
> > distribution file directly (save disk space) or create a new file completely.
> > If there is sufficient reason for the first option, then perhaps the
> > distributable file would need to be structured almost exactly like a BSP file,> > and the new textures simply appended. This, imho, is not as neat.
> If the full version of Quake supports more than a single PAK file, a nice
> option would be for the user to be all his or her favourite levels in one
> PAK file, which could then be loaded every time Quake starts, then access
> to all the user-created levels would be simple. However, I don't think
> there is any call to directly modify the distribution files, other than
> that it keeps the directory structure and files in the Quake directory
> cleaner.

Yes, I think I would prefer the separate file method. I must say, being
able to specify PPACKs ;) would be very nice. At the moment, you can just put
things in the directory tree, although it doesn't quite have the desired


* TQ 1.0 * 101 Slogans for Quake
57. alt.sex.Quake: Please hit me again....