Date: Thu, 22 Aug 1996 09:21:50 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <199608220721.JAA20428@marvin.nero.uni-bonn.de>
To: quake-dev@gamers.org, bernd@marvin.nero.uni-bonn.de
Subject: Info from John Carmack (final)
To give proper credit - the original Dark Sucker Theory nonsense
that inspired my suggestion has been posted by Mike Hammond on
rec.arts.sf.science in june 1996.
I will be in the USA from August 27th till October 25th. The
QuakeDev pages will be mothballed from next weekend on (one
overdue update to happen then). Thus this is the final q&a
posting for some time.
b.
----- Begin Included Message -----
>From johnc@idcanon1.idsoftware.com Thu Aug 8 14:55 MET 1996
You wrote:
> A bit of design speculations on Current Generation Technology....
>
> Q: on backface culling with dynamic lighting - I agree, the current
> approximation is indeed a far more convincing solution. A neat
> feature even: textures resembling a colored but opaque glass on
> thin walls will let moving light sources shine through.
Yes, it is pretty cool to see people fighting on the floor beneath you.
Totally unrealistic, but neat.
> Q: could the Quake engine be used to render to 24bit fb, using the
> same indexed color mipmaps and palette? Would it make sense using a
> few additional palettes then (e.g. maxbright for light sources
> etc.)?
We had a 16 and 24 bit backend for a while, but it wasn't worth the
effort to maintain the code. 16 bit looked worse, and 24 bit only
looked marginally better. If you make a bad 256 color design, direct
color will help a lot, but a good 256 color design tries to minimize
the palette fitting required.
The next engine will be all direct color, and we will be designing
for it from the beginning, to good benefit.
> Q: Is there any use for a translucency lookup, e.g. byte
> LUT[256][256], to map fb_col == LUT[src_col][dest_col]. Taking
> advantage of sorted spans and z-buffer, one might put translucent
> spans on a stack during front-to-back, and render them afterwards
> back-to-front. For mipmapped sprites/billboards, semitransparent
> water, colored glass. This is ugly (compared to RGBA) and probably
> dead slow even if used with care - not worth the trouble?
For a little while I had translucent alias models in the game. We
didn't have a great use for them, so I took the hack out, but it
may come back in Quake 2. Integrating translucency with the edge
sorting for the main world rendering would be a lot more painfull.
Another thing to think about is how it will work with hardware
accelerators. If you don't stick to a straight blend operation,
the hardware can't do the same thing as the arbitrary table.
> Q: any way to customize particles - i.e., choose a sprite instead
> of a single color for each particle? Is there an entity for each
> particle?
Not currently. There are up to 2048 particles, so no, there isn't an
entity for each one. They have very tight hard coded actions: spread
out, fall slowly, fall fast, fade as a rocket trail, fly as an
explosion, etc.
> A few months ago you mentioned talking to the Rendition people, in
> favor of some disclosure of technical info, with XFree86/GLX/Mesa
> support in mind. Did you ever get around to this?
Yes, I did. The techie type I talk to didn't have any objections at
all to it, but the are an under-the-gun startup company, so I don't
think they are going to have spare time for a while.
> If your handling of dynamic light source brightness uses
> a signed magnitude value, it should be possible to implement
> a "Dark Sucker" entity. This is not meant as a useful
> approximation of illumination in any sense (perhaps
> decreasing the ambient would be better anyway). From (your)
> game design POV - would such an effect fit to a Quake-like
> concept, or would it spoil the immersion?
Probably a good idea. We'll check it out.
John Carmack
----- End Included Message -----