Info from John Carmack (7)

Bernd Kreimeier (Bernd.Kreimeier@NeRo.Uni-Bonn.DE)
Mon, 3 Jun 1996 20:13:28 +0200 (MET DST)

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

Last but one. Please note that this is the accumulated log
since march, less than one q&q per week on average. Note the
postscriptum. I will update the Hypermail archive ASAP, and
encourage everybody to add other bits of information they got,
to keep *me* from asking more stupid questions. Thanks.


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

>From Mon Jun 3 18:08 MET 1996
Mime-Version: 1.0 (NeXT Mail 3.3risc v118.3)
Content-Transfer-Encoding: quoted-printable
X-Nextstep-Mailer: Mail 3.3 (Enhance 1.0)
From: John Carmack <>
Date: Mon, 3 Jun 96 11:07:47 -0500
To: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Subject: Re: q&a (4a) ?
Content-Type: text/plain; charset="us-ascii"
Content-Length: 3389

You wrote:
> Q: In the qtest1 palette, there are >= 16 colors all white. Has the
> palette changed, i.e. has it been unfinished? Would it be possible
> to release the current/final version?

We added another range of fullbright explosion colors, I don't think
anything else has changed.

> Q: Would you mind providing a hint on the "sealing" of a map? Does
> this include a processing step like mentioned by Seth Teller,
> fixing small gaps and holes to reduce vis computation and PVS size,
> or is it determining "sky" surfaces?

I don't fix any small gaps, but removing all the crud on the outside
of the level more than halves the data size. After building the BSP
tree of the world, I build a graph of the portals between the leaf
nodes, then do a simple graph flood fill from the outside of the
world. If it ever reaches a leaf with an entity (light, player, etc)
in it, it assumes that it leaked inside the level and writes a
pointfile containing a trail of dots that can be loaded into quake
to find the path that went through the hole.

> Q: on NATs and the new MAP format. You wrote:
> >On the NAT front, I am considering changing the .map definition
> >to use arbitrary texture origin and S and T vectors on each
> >plane, instead of the sofs / tofs / flags values that are
> >currently there.
> I expected something like ( x,y,z,s,t ). Instead, there are two
> additional values in that seem to be always 1.0000.
> This is supposed to be scaling, in addition to sofs/tofs/flags?
> There are "sizing" buttons in the early screenshots of QuakeEd. Or
> am I missing something?

The textures are arbitrary now, but the definition is a bit confusing.

My first thought was "just include S and T vectors on each surface".
That is the simple, straightforward representation, but it is bad
for editing, because every deformation of a brush needs to modify
the vectors. I wound up representing the textures as modifications
off of natural texture alignment. shift and scale on each axis plus
rotation. It feels clunky, and I doubt it is The Right Thing.

> >BTW, I just became aware of Mesa last week, and I am very
> >impressed with it. I hope to contribute something to the
> >project when I have more time. I may compatability check my new
> >editor against it.
> Actually, texture mapping (esp. mipmapping) is not yet complete (as
> of 1.2.8, which is supposed to be the last release for about 6
> months). How about a i586 optimized driver, btw :-)?

Mipmapping isn't crucial. I saw the basic wrap/clamp test running,
and I glanced at the code, so I don't think it is too horribly far

I did notice that the parallel array structure of the texture mapping
polygon rasterizer is going to guarantee cache associativity collisions
on every single scan line.

If I can find some time, I would like to donate some work, but my time
is a pretty damn scarce commodity.

John Carmack

ps: I encourage you to share my comments with the rest of the community
that might be interested, in the hope of preventing my answering the
same questions multiple times...

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