gzdoom/docs
Randy Heit e5572a1c4e - Updated lempar.c to v1.31.
- Added .txt files to the list of types (wad, zip, and pk3) that can be
  loaded without listing them after -file.
- Fonts that are created by the ACS setfont command to wrap a texture now
  support animated textures.
- FON2 fonts can now use their full palette for CR_UNTRANSLATED when drawn
  with the hardware 2D path instead of being restricted to the game palette.
- Fixed: Toggling vid_vsync would reset the displayed fullscreen gamma to 1
  on a Radeon 9000.
- Added back the off-by-one palette handling, but in a much more limited
  scope than before. The skipped entry is assumed to always be at 248, and
  it is assumed that all Shader Model 1.4 cards suffer from this. That's
  because all SM1.4 cards are based on variants of the ATI R200 core, and the
  RV250 in a Radeon 9000 craps up like this. I see no reason to assume that
  other flavors of the R200 are any different. (Interesting note: With the
  Radeon 9000, D3DTADDRESS_CLAMP is an invalid address mode when using the
  debug Direct3D 9 runtime, but it works perfectly fine with the retail
  Direct3D 9 runtime.) (Insight: The R200 probably uses bytes for all its
  math inside pixel shaders. That would explain perfectly why I can't use
  constants greater than 1 with PS1.4 and why it can't do an exact mapping to
  every entry in the color palette.
- Fixed: The software shaded drawer did not work for 2D, because its selected
  "color"map was replaced with the identitymap before being used.
- Fixed: I cannot use Printf to output messages before the framebuffer was
  completely setup, meaning that Shader Model 1.4 cards could not change
  resolution.
- I have decided to let remap palettes specify variable alpha values for
  their colors. D3DFB no longer forces them to 255.
- Updated re2c to version 0.12.3.
- Fixed: A_Wander used threshold as a timer, when it should have used
  reactiontime.
- Fixed: A_CustomRailgun would not fire at all for actors without a target
  when the aim parameter was disabled.
- Made the warp command work in multiplayer, again courtesy of Karate Chris.
- Fixed: Trying to spawn a bot while not in a game made for a crashing time.
  (Patch courtesy of Karate Chris.)
- Removed some floating point math from hu_scores.cpp that somebody's GCC
  gave warnings for (not mine, though).
- Fixed: The SBarInfo drawbar command crashed if the sprite image was
  unavailable.
- Fixed: FString::operator=(const char *) did not release its old buffer when
  being assigned to the null string.
- The scanner no longer has an upper limit on the length of strings it
  accepts, though short strings will be faster than long ones.
- Moved all the text scanning functions into a class. Mainly, this means that
  multiple script scanner states can be stored without being forced to do so
  recursively. I think I might be taking advantage of that in the near
  future. Possibly. Maybe.
- Removed some potential buffer overflows from the decal parser.
- Applied Blzut3's SBARINFO update #9:
  * Fixed: When using even length values in drawnumber it would cap to a 98
    value instead of a 99 as intended.
  * The SBarInfo parser can now accept negatives for coordinates. This
    doesn't allow much right now, but later I plan to add better fullscreen
    hud support in which the negatives will be more useful. This also cleans
    up the source a bit since all calls for (x, y) coordinates are with the
    function getCoordinates().
- Added support for stencilling actors.
- Added support for non-black colors specified with DTA_ColorOverlay to the
  software renderer.
- Fixed: The inverse, gold, red, and green fixed colormaps each allocated
  space for 32 different colormaps, even though each only used the first one.
- Added two new blending flags to make reverse subtract blending more useful:
  STYLEF_InvertSource and STYLEF_InvertOverlay. These invert the color that
  gets blended with the background, since that seems like a good idea for
  reverse subtraction. They also work with the other two blending operations.
- Added subtract and reverse subtract blending operations to the renderer.
  Since the ERenderStyle enumeration was getting rather unwieldy, I converted
  it into a new FRenderStyle structure that lets each parameter of the
  blending equation be set separately. This simplified the set up for the
  blend quite a bit, and it means a number of new combinations are available
  by setting the parameters properly.


SVN r710 (trunk)
2008-01-25 23:57:44 +00:00
..
BUILDLIC.TXT Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
classes.txt Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
colors.txt Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
commands.txt Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
console.css Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
console.html Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
console.txt Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
console2.html Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
doomlic.txt Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
foo.txt Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
history.txt Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
notes.txt Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
README.asm Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
README.Carmack Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
README.gl Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00
rh-log.txt - Updated lempar.c to v1.31. 2008-01-25 23:57:44 +00:00
zdoom.txt Directory restructuring to make it easier to version projects that don't build zdoom.exe. 2006-02-24 04:48:15 +00:00

README: glDOOM

I never got around to do anything with respect to
a Linux glDOOM port except for assembling a Linux3Dfx
HOWTO (which, at that time, was a prerequisite
to get permission to publicly distribute the
already finished LinuxGlide port by Daryll Strauss).

Linux q2test (and soon LinuxQuake2) demonstrate that
Mesa with the MesaVoodoo driver is quite up to the
requirements for a glDOOM port. If anybody wants to
get into Linux glDOOM, please drop me a line.

There is a Win32 GLDOOM port in the works, by Jim Dose.
Quoting a recent posting by him:

"I haven't had as much time lately to really work on
the conversion. I currently have the renderer drawing
the walls and floors as texture spans as the are in
the software renderer. There's lighting on the walls,
but not the floors, and sprites are being drawn, but
not with the right texture. I figure that this is one
nights work to get the game looking "normal". I haven't
tested the game on less than a p200, so I'm not sure
how it will perform under the average machine, but I
don't expect it to be blindingly fast because of the
number of spans that have to be drawn each frame.
Rendering as polys is definitely the way to go.

The reason I chose to do spans first was because it
left the base renderer intact and I could concentrate
on ironing out any Windows compatibility problems.
Actually, the first version I had running was simply
a blit of the 320x200 game screen through Open GL.
Surprisingly, this actually was very playable, but
certainly wasn't taking any advantage of 3D acceleration.
Once the game was running, I started converting all
the span routines over."

Comment: for merging Linuxdoom with Win32, this is
probably the best source for getting the Win32
environment done - before more significant changes
occur.

"One problem with drawing spans is that the engine
doesn't calculate the texture coordinates with
fractional accuracy, so the bilinear filtering works
vertically, but not horizontally on the walls. I may
try to fix this, but since I plan to use polys for
the final version, it's not really high priority.
Also, spans don't really allow for looking up and
down."

Comment: true looking up/down vs. Heretic-style
y-shearing seems to require either a strange kind
of transofrmation matrix (he probably does not use
the OpenGL transformation at all), or rendering
all the spans as textured rectangular slices
instead of using glDrawBitmap. No, polys are the
way to go.
   
"When I tackle the conversion to polys, one big problem
I'll encounter is drawing floors. Since the world is
stored in a 2D bsp tree, there is no information on
the shape of the floors. In fact the floors can be
concave and may include holes (typically, most renderers
break concave polys down into a collection of convex
polys or triangles). In software, the floors are actually
drawn using an algorithm that's similar to a flood fill
(except that a list of open spans is kept instead of a
buffer of pixels).  This makes drawing the floors as
polys fairly difficult."

A polygon based approach will require significant changes
to the data structures used in the refresh module. I
recommend either separating a libref_soft.so first (a
Quake2 like approach), and creating libref_gl afterwards,
or abandoning the software rendering entirely.

John Carmack wrote once upon a time:
"... the U64 DOOM engine is much more what I would consider
The Right Thing now -- it turns the subsector boundaries
into polygons for the floors and ceilings ahead of time,
then for rendering it walks the BSP front to back, doing
visibility determination of subsectors by the one dimensional
occlusion buffer and clipping sprites into subsectors, then
it goes backwards through the visible subsectors, drawing
floors, ceilings, walls, then sorted internal sprite fragments.
It's a ton simpler and a ton faster, although it does suffer
some overdraw when a high subsector overlooks a low one (but
that is more than made up for by the simplicity of everything
else)."

Well, IMO compiling a separate list of floor/ceiling polygons
after having read the WAD file, and thus introducing this as
a completely separate data structure to the current code base
might be the easiest thing to do. Jim Dose writes:

"One method I may use to draw the floors as polys was suggested
by Billy Zelsnack of Rebel Boat Rocker when we were working
at 3D Realms together a few years ago. Basically, Billy was
designing an engine that dealt with the world in a 2D portal
format similar to the one that Build used, except that it had
true looking up and down (no shearing). Since floors were
basically implicit and could be concave, Billy drew them as
if the walls extended downwards to infinity, but fixed the
texture coordinates to appear that they were on the plane of
the floor. The effect was that you could look up and down and
there were no gaps or overdraw. It's a fairly clever method
and allows you to store the world in a simpler data format.
Had perspective texture mapping been fast enough back then,
both Build and Doom could have done this in software."

Perhaps the above is sufficient to get you started.
Other Issues:

1. Occlusion
DOOM uses a per-column lookup (top/bottom index) to do HLHSR.
This works fine with span based rendering (well, getting
horizontal spans of floors/ceilings into the picture is a
separate story). It isn't really mindboggling with polygon
based rendering. GLDOOM should abandon that.

2. Precalculated Visibility
DOOM has the data used by Quake's PVS - in REJECT.
During Quake development, lots of replacements for the
occlusion buffer were tried, and PVS turned out to be best.
I suggest usind the REJECT as PVS.

There have been special effects using a utility named RMB.
REJECT is a lump meant for enemy AI LoS calculation - a
nonstandard REJECT will not work as a PVS, and introduce
rendering errors. I suggest looking for a PVS lump in the
WAD, and using REJECT if none is found. That way, it might
be feasible to eat the cake and keep it.

3. Mipmaps
DOOM does not have mipmapping. As we have 8bit palettized
textures, OpenGL mipmapping might not give the desired
results. Plus, composing textures from patches at runtime
would require runtime mipmapping. Precalculated mipmaps
in the WAD?

4. Sprites
Partly transparent textures and sprites impose another
problem related to mipmapping. Without alpha channel,
this could give strange results. Precalculated, valid
sprite mipmaps (w/o alpha)?