Date: Thu, 22 Aug 1996 09:44:10 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier@NeRo.Uni-Bonn.DE>
Message-Id: <199608220744.JAA20866@marvin.nero.uni-bonn.de>
To: quake-dev@gamers.org
Subject: Re: Info from John Carmack (final)
I did not get across the first time my question on a 24bpp renderer
design.
b.
----- Begin Included Message -----
>From bernd Fri Aug 9 17:44 MET 1996
Date: Fri, 9 Aug 1996 17:43:54 +0200 (MET DST)
From: Bernd Kreimeier <Bernd.Kreimeier>
To: johnc@idsoftware.com
Sorry about this, I haven't made myself clear. You wrote:
>> Q: could the Quake engine be used to render to 24bit fb
>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
>> Q: Is there any use for a translucency lookup, e.g. byte
>> LUT[256][256], to map fb_col == LUT[src_col][dest_col].
>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.
I actually meant the questions to be related. Basically, I am
thinking about different ways to combine index color palettes
and mipmaps with 24bit back end and hardware support. My crude
reasoning was like
(a) a well designed translucency (straight blend) might work well
with hardware if a 24bit back end is used
(b) using palettes and index color mipmaps, conversion to RGB
could be done in the mipmap+lightmap processing (surface cache).
(c) once using hardware, this could be extended (different palettes
for mipmaps, skins, RGBA billboards and water)
I understood from earlier explanations that there is no advantage
in 24bpp (and no value at all in 16bpp) with the current design.
However, I am still wondering how well the lightmap approach will
work with hardware support. Depending on your modifications (or
replacements) for the main memory surface cache, isn't a 24bit
backend a better choice - even allowing for additional features?
Related: could the Verite programmable RISC be tweaked to do the
mipmap+lightmap processing on board? Does it make sense to try to
use blending with the current lightmaps?
[...]
regards
b.
----- End Included Message -----
----- Begin Included Message -----
>From johnc@idcanon1.idsoftware.com Thu Aug 22 08:41 MET 1996
From: John Carmack <johnc@idcanon1.idsoftware.com>
Date: Thu, 22 Aug 96 01:40:40 -0500
To: Bernd Kreimeier <Bernd.Kreimeier@nero.uni-bonn.de>
> on a hybrid renderer (indexed color mipmaps
> and RGB surface cache, RGBA billboards with RGBA frame buffer and
> RGBA hardware blends)? Or are you too busy with QuakeWorld?
It was one of those questions that a well worded response didn't leap
from my fingers for, and the mail got buried. I am often getting 50+
emails a fay (ugh), so if it doesn't get answered fast, it rarely does
at all.
Yes, multiple palettes for textures would be a reasonable way of
expanding the dynamic range of a 3d game, because it would still
allow you to do the lighting with lookups, which is not practical for
full 16 bit textures.
I think if I were to do a software only 16 bit game (not planned), I
would just bite the bullet and spend a longer time in the surface
cache generation and do it right with full 16 bit source data.
Matter of taste, not a huge technical issue.
John Carmack
----- End Included Message -----