One more file format suggestion

Lauri Alanko (
Thu, 14 Mar 1996 17:23:03 +0200 (EET)

Date: Thu, 14 Mar 1996 17:23:03 +0200 (EET)
From: Lauri Alanko <>
Subject: One more file format suggestion

Hello! As there has been talk about a file format suitable for distributing
levels etc., here are some of my thoughts about this.

The general problem seems to be that there are many different pieces of data
that can be modified, but there are only a few forms in which Quake will
read this data. Therefore a system is needed which converts editable and
distributable pieces of data into Quake-readable pieces of data.

It is my thought that there is no reason to limit this system merely to maps
and textures. Couldn't there be a general resource location system which
allows the "statical linking" of almost anything that people are likely to

So, basically, when someone distributes an add-on, be it a level, a model
texture or whatever, it should contain information about:
1. What should be created from these add-ons (eg. a .bsp level file)
2. What else is required to create them (eg. textures, entities)

In addition, the end-user should supply information about:
3. Where the required "libraries" are located (eg. a .pak file)
4. How all the things are joined to create the final product (eg. qube 2.0)

The end-user should have a reference table where the "linker" can find
the locations of the pieces of data needed to create the final product. This
would be a text file, easily editable. Something along these lines...

texture water { //Grab the texture straight from the .pak file
pak id1.pak
bspfile maps/test2.bsp //This is looked up in the packfile now.
bspentry 02 //This would probably be the default anyway...
mipname *04mwat2

texture water { //The mipmap is composed from bitmaps
mip1 maps/textures/_04mwat2.bmp //in the linking process. Slow but
mip2 maps/textures/_04mwat2.bm2 //handy if one is editing the texture
mip4 maps/textures/_04mwat2.bm4 //all the time.
mip8 maps/textures/_04mwat2.bm8

texture water { //This would maybe be the most common way
bspfile maps/test2.bsp //to do it, grab the texture from a level.
mipname *04mwat2

Then when the new level is distributed (probably in some format that
includes all the visilist calculations), there is a header or something
which tells to use the symbolic texture name "water" in certain areas. When
the final map is "linked", the end result will be a level where water looks
like whatever the _end user_ has customized it to look like.

This kind of "resource locating" could be used for anything else. A level
could contain a symbolic entity "ogre", which defaults to progs/ogre.mdl,
but could be redefined by the end user to contrib/progs/bgates.mdl.
Or someone might just distribute an entity list and tell in the header
which map it is for.

A system this flexible would have advantages. Given proper configuration,
it should be possible to create a new 2 meg level from a 50k distribution
file with a single command. Also, the end user could (but wouldn't have to)
change the outlook of the distributed level by simply changing some
definitions and relinking. No need for Qeutex.

Okay, there are disadvantages, too. The linking process could take a
lot of time. If all the end user's textures are in .bmp files it may take a
while to create proper .bsp entries from them. But the end user _could_ have
everything neatly "precompiled" in a .pak file, in which case it shouldn't
take too long just to copy the necessary entries and add a few from the
distribution. In any case the end user could have his files in whatever
format he prefers.

This would require a very sophisticated "linker" program, which would
read the end user's reference table and invoke the proper tools to change
pieces of data from one format to another (eg. a model texture and a full
model into another model where the texture has been replaced).

And finally, any of this will be damn near useless until the file formats
that Quake will support have been confirmed.

So my idea is a system where every conceivable piece of data could be
identified and automatically put in the right place to compose the final
product. Silly me.

Comments? How much of this would be conceivable?

Lauri Alanko