fablog3.txt

The source code of Doom legacy for windows

=====================================================================
faB log of changes on DOOM LEGACY, was discontinued from release
v1.25 of Doom Legacy, until December 1998, after two months of
quick and dirty coding a win32 port and a 3Dfx accelerated version.
---------------------------------------------------------------------
THE DOOM LEGACY PROJECT		        Contact: <[e-mail]>
=====================================================================

Project:  DOOM Legacy
Web site:  http://www.newdoom.com/doomlegacy
Log author: Denis Fabrice


----------------
from October to December 1998,
 worked mainly on the 3Dfx accelerated version
----------------

about 6 weeks ago (Sep98):
==========================
 - started getting grips with VisualC++
 - started DirectDraw..
 - I don't remember..

about 5 weeks ago (Oct98):
==========================
 - downloaded glide3 API, read the doc, run the examples, did some
   quick 'modify' the examples and see what it does.

about 4 weeks ago (Oct98):
==========================
 - started a workspace in VisualC++ with my test programs for Glide.
   test1: displays a simple rotating cube with colour gradients
   test2: displays the same, with another cube, and add a z buffer
   test3: finally tested the texture mapping, yipee! downloaded a
	  simple 256x256 XOR pattern as a texture. Just do for x,
	  for y, and for each pixel colour is x XOR y. Nice little
	  pattern :)


about 3 weeks ago (Oct98):
==========================
 - started displaying level as dots, used some matrices which didn't
   work, after some unhappy coding, finally used the transformations
   of Doom, all I want is see the level on my screen. It works.

about 2 weeks ago (Oct98):
==========================
 - drawing the level as lines, crash, 2d clipping of Banshee card
   stops about 2050.0f to the right out of the display, of course
   this is total lame, should clip to the frustum. Well, grDrawPoint
   never crash, but with grDrawLine it does... grr..

about a week ago (Nov98):
=========================
 - bought a wonderful book called 'Procedural Elements for Computer
   Graphics', David F. Rogers, WCB/McGraw-Hill

 - working on the frustum clipping, using Liang-Barsky algorithm,
   optimised for 90deg left-right top-bottom fov, still use the
   z near clipping with nice little clipZ routine from Carl's
   warp project. Had big problems, thought the clipping found in
   the book 'Procedural Elements for Computer Graphics' didn't
   work, was very happy when some days later I found out I had
   a stupid error with precedence of operators and a cast.. ouch.
   Without the book's algorithm I don't think I would have a nice
   frustum clipping until some long time ahead. I'm not a math
   head, I have about half the math knowledge of the basic school
   maths because I did half of the school as 'artistic' courses,
   where there are basically no maths. Still, I'm pretty happy
   with what I have accomplished : wall polygons are created from
   segs of subsectors, are converted into polygons, polygons are
   clipped to the view frustum, and then split in triangles that
   are rendered.

   There is still drawing out of the screen: the frustum's 90deg
   left-right fov is projected to the screen width, but then the
   top-bottom fov goes beyond the top and bottom of the screen.
   Simple solution : I may simply scale each Y (updown) coord of
   the polys with a scale, before entering the frustum clipping,
   the 'crunching' back the up-down 90deg fov to the screen height
   and everything will look normal, since I scaled the y coords
   up before 'crucnhing' them smaller with the projection, that
   is , so that the up-down frustum just fit in the screen height.
   The scale is probably a factor like 320/200, screen width div
   screen height. I'll see that later.

   Now I want to play with the floors. The upper/lower walls are
   not done, but it's easy, just two special cases of the actual
   wall rendering, where the top/bottom coords are different.

this week (Nov98):
==================
 - I started the floors, I take the coords of the base of the segs
   that are supposed to enclose the subsectors. Deception here:
   I finally found out that segs are made only for linedefs parts
   and that subsectors, although defining convex spaces, only
   define the wall parts, since the floors are just filled in-between
   the walls, Doom doesn't need convex subsectors where no part
   of linedef is to be drawn.

   Solutions: I thought splitting the concave sectors (well there are
   often concave) in convex polygons, and use them to render the
   floor. This is really bad, I'm sure it involves a lot of overdraw
   and well, John Carmack says for the U64 version they did per-
   subsector convex polygons for the floor/ceiling and he calls that
   'The Right Thing'.

   I decided to try Carmack's 'Right Thing'! :) The BSP doesn't hold
   the information for the convex floor/ceil polygons, so I found out
   that I had to go through the BSP, and add subsectors where they
   miss, and also recursively split a convex polygon with each BSP
   partition line, so that I get the right convex polygons for each
   subsector leaf. I have to check when Doom BSP has skipped a sub-
   sector where they were no segs, I have to add one with 0 segs, but
   the convex polygon I have at this stage. The software renderer
   will ignore subsectors with 0 segs. I will add a polygon pointer
   to each subsector that will be used by the 3dfx planes renderer.
   Also, where subsectors contained enough segs to outline the convex
   polygon, they were put in no special order, so with the method
   I explain, I get convex polygon with vertices defined in clockwise
   order (started as anti-clockwise , but had many problems with the
   BSP partition lines orientation).

14-Nov-98:
==========

   I am _VERY_ lucky, that I started some months ago a map editor
   that I never finished, as I write today, I have been able to test
   my method of subdividing a convex polygon using the BSP stored in
   wads, and debugging all the output, step by step to the map view
   of my 'editor'. Without it, I think I would not have done the
   floors correctly until a minimum of one month more.

15-Nov-98:
==========

   Got the thing working. I start with a convex poly the size of the
   min/max boundaries of the entire map. The poly is a simple rectangle.
   With each BSP node, the poly is split in two other convex polygons,
   one front of the partition line, one to the back, the RenderBSPNode
   then calls hilmself recursively for the front side with the front
   poly, and then the backside with the back poly. The front or back
   poly is then split again with each node, until we fall into a leaf
   of Doom's BSP, a subsector.

   Actually the convex polygon I get is most often larger than the
   subsector, because it encloses some 'void' space out of the sub-
   sector, so I have to clip the convex poly with each seg of the
   subsector to get the final convex poly. TO do today..

   Another problem I just found, is with some maps using the trick
   of deep water, where linedfes have each side point to the same
   sector. It results into a 'broken' BSP, at some point, you would
   get a subsector, but instead, you get a node, that splits the
   convex poly, but it is useless, the poly is already pf the sub-
   sector size, however it seems the BSP compiler added it because
   it thought the subsector was not convex, because one of the
   segs did not point to the same sector...

   I had to fix, so for now, if a split can't be made, that is, the
   BSP partition line is _OUT_ of the convex poly, and doesn't split
   it, then I return the frontpoly as the poly, and backpoly is NULL.

   Maybe the maps with this effect won't display properly where the
   effect is, but thanks to the BSP recursion, the other parts of
   the map must be displayed properly, as long as the BSP partition
   line does not use one pf the 'deep water' subsector segs.

   01:24:08

   Subsector final convex polygon is now 'cut' with the subsector
   segs, so that the 'void' space, behind the segs is cut out.
   There's still a problem sometimes with 2 points at the same
   place..


02/Dec/98 22:40
===============

yesterday I sent the very alpha to James Toyski who recently bought
a voodoo2 card.