Info from John Carmack (1)

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Mon, 3 Jun 1996 19:03:07 +0200 (MET DST)

Date: Mon, 3 Jun 1996 19:03:07 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <>
Subject: Info from John Carmack (1)

I am going to forward a couple of mails to the list, with
permission. This should have happened way earlier, btw.,
but work got the better of me the last weeks.


This one immediately followed the mail about editing qtest1.

----- Begin Included Message -----

>From Sun Apr 7 20:26 MET 1996
Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3)
X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0)
From: John Carmack <>
Date: Sun, 7 Apr 96 13:25:22 -0500
To: Bernd.Kreimeier@NeRo.Uni-Bonn.DE
Subject: Re: qtest1 editors?

>Problem: billboard object (sprite) support might be removed, or
>incomplete. Billboards allow for good use of partly transparent

They are going to stay in. All of the sprite types you mention are
currently supported, and there is also a sprite type that always
has the XY normal pointing towards the view, which is slightly
different than parallel to the view plane.

>1.1 The trailing zeros in a plane like
> "( 0 816 0 ) ( 0 512 0 ) ( 16 512 0 ) TECH07_2 0 0 0"
>are s_ofs, t_ofs, and flags? I.e. a texture offset s_ofs=16,
>t_ofs=-32, with negate_s, negate_t, and exch_st all set would read


In case you didn't figure it out already, the points that define
the plane are not necessarlily points on the brush, but just three
non colinear points on the plane. I chose this representation
instead of a normal/distance form because it allows me to keep
perfect precision with integral values. I fear floating point creep
in many forms.

>2.1 How does "qbsp" handle two brushes that do not intersect, but
> merely "touch"?

Contacting faces are merged out of existance.

I'm pretty sure that a brush that has no thickness in a given
dimension would clip itself out of existance and not show up at all
in the bsp file, but I'm not positive.

> >Levels carry their own textures with them.
> Would it be possible to include a dummy entry of two long int in
> the BSP header? As a placeholder for an optional list of "15
> BIGDOOR" entries, to be ignored by the engine.

I don't think any app specific data should be stored raw in bsp
files. Store it in a key/value pair in the world entity. An
unrecognized key name will get a warning from Quake, but you can
either define a new variable in defs.qc (when I release the
compiler), or just use a valid string variable key like "netname" or
"weaponmodel". Or perhapse I should just ignore (or make
notification a development option) unknown keys at load time? It is
nice to know when you make a typo...

> I wish you only had... I figured this out last week, and it will
> hamper level design in the most subtle ways. I don't see any
> convenient fix, though.

It was originally a speed issue for building the surface caches,
but a later insight rendered the problem moot. I would like to fix
it, but it probably won't show until Quake 2.

The current limitation that annoys the map guys most is that
texture shifting is by multiples of 16. If I put in The Fix, the
primary benefit would be pixel level shifting, but it would also
allow arbitrary rotation and scaling. That is an easily abused
feature, though...

Overall, natural alignment makes creating good looking maps a lot
easier, because you usually don't have to offset things at all to
get them to line up.

John Carmack

----- End Included Message -----