Info from John Carmack (3)

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

Date: Mon, 3 Jun 1996 19:14:57 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <199606031714.TAA05008@marvin.nero.uni-bonn.de>
To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de
Subject: Info from John Carmack (3)

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

>From johnc@idnewt.idsoftware.com Fri Apr 26 20:22 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 <johnc@idnewt.idsoftware.com>
Date: Fri, 26 Apr 96 13:21:10 -0500
To: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Subject: Re: q&a
Content-Type: text/plain; charset="us-ascii"
Content-Length: 2988

You wrote:
> Q's:
>
> 1. I want to forward a posting of yours (to Brian Martin)
> concerning z-fill/z-buffer usage to the QuakeDev list, to settle
> the occasional "z-buffer?" threads. Do you have any objections
> against making any of your mails to us public?

I never say anything that can't be quoted.

> 2. Will billboards (sprites, decals) be mipmapped in 1.0/2.0?

Hadn't planned on it, because it would require alpha channel to
properly mipmap a mixture of transparent and opaque pixels.

> 3. Will the texture names in the BSP mipmaps lump stay? I want to
> use them to store the info needed to add mipmaps to a BSP file w/o
> mipmaps - use of "_wad" optional.

Yes, they should still be there. Are you planning to use miptex
without any pixels as placeholders for another utility to fill in?
I don't really think that is a great idea. Yes, it takes a couple
hundred K to cary the graphics with a level, but it is rarely more
than 20% of a full sized map's disk footprint. We are going to give
free license to redistribute our art in user maps for non-commercial
purposes. Packaging it all into one file makes distribution so
much easier -- people don't need to get both graphics and levels.

> 4. qtest1 and your log seem to indicate that Quake will try to
> preserve view_up as much as possible (except on being
> dead/strifing). Does that mean that there will be no builtin
> support for 360 degree rotations around LOS/no rotate_ccw/cw
> commands to bind to a key?

There is no direct way to do it, but you can set cl_rollangle to 45
or so to get a whole lot of roll...

A linked in input driver can set the view angle to anything it
wants, so HMD can roll arbitrarily.

qc code can set any angle for other objects, but there are some
restrictions on player views, due to the client side short-circuiting
of view control (to reduce latency).

> 5. I am looking at GNUstep, trying to guess the changes of a
> QuakeEd Linux port using GNU gcc ObjectiveC support and the
> (supposedly 85% done) GNUstep libraries. Have you ever considered
> this option? What classes/libs does QuakeEd require?

QuakeEd is written for NEXTSTEP 3.3, while GnuStep is an implementation
of the OPENSTEP spec. I haven't had time to port it to openstep yet,
but it looks like it will take a little effort. NeXT has tools in
NS 4.0 to help, but it still isn't automatic.

> 6. Is there any real gain in not doing the mipmapping down to 1x1?

Yes, I need to keep a cache pointer for each surface and each mip level,
so adding four more mip levels would eat 160k of ram on a 10,000 polygon
level.

> 7. Idle curiosity: what became of the spherically mapped sky?

It is a very squashed sphere now. A true sphere looked like you were
inside a beach ball. Currently on the hardware 3D boards, it is a flat
mapping, but that looks pretty poor. We are probably going to subdivide
on them to get the spherical projection.

John Carmack

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