Re: Forward: Intermediate file format

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Wed, 13 Mar 1996 23:11:43 +0100 (MET)

From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Date: Wed, 13 Mar 1996 23:11:43 +0100 (MET)
Message-Id: <>
Subject: Re: Forward: Intermediate file format

Forward of my reply....

From: bernd@NeRo.Uni-Bonn.DE (Bernd Kreimeier)
Subject: Re: Intermidiate File format nessecary??
Date: 13 Mar 1996 12:45:14 GMT

In article <> (Mads Dydensborg) writes:

> From: (Mads Dydensborg)
> After reading the Unofficial Quake Specs, (Thanks to Olivier Montanuy and
> cowriters), I'm left with the impression, that a BSP file, may not be the
> best format to work with, during the *design* of a new level : When
> creating the BSP file, surfaces may be split, new vertices and edges created,
> etc. Oppisite to DOOM, where the SSEGS etc, where additional information.
> Is this a correct understanding?

Yep. While the details of the BSP lookups will probably change significantly
until the final release of the shareware version, this particular detail
might not. It comes to my mind that distributing the preprocessed
lookup information (equivalent to SSEGS) while not using an level editing
information (equivalent to LINEDEFS) will make creating derivative works
and modification of both proprietary and free maps more difficult. Which
might or might not be done intentionally.

> If yes, would it serve all purposes to agree on a format for exchanging
> files under development? In this way, (if possible), a format for
> editing could include ways to name mip-textures, etc. etc., and thereby maybe
> even reduce the size of Quake add on levels : Collections of textures
> could be distributed, and semicompiled levels could be distributed and
> compiled by each user into BSP maps, from a tool designed for this.

Indeed. There are a lot of related issues (reference resource databases and
management of contribution repositories, the need of a CSG description
of a level for editing purposes, conversion issues of old resource
files aka WADs), and the fact that it will be futile to develop anything
sophisticated with only qtest1 in mind. Still any good proposal is
virtually worthless without a portable and commonly accepted reference library
supporting I/O based on any such non-id file format.

It will take some time. And most people will ignore even a decently
supported solution, solely because it is not used by id.

> Am I completly off track here? Probably.. :-)
I don't think so. Good point indeed. You might find some further
discussion of this on the Quake Developers mailing list
(, send mail w/o Subject:, body: info quake-editing)


"Problem solving is hunting. It is savage pleasure, and we are born to it."