This file outlines the changes from DKB 2.0 through DKB 2.02.


Version 2.01:

1. Bug in smooth triangles fixed (caused problems with TILES.DAT).

2. Degenerate Triangles (some of which are in the data file SLANTBOX.DAT)
   are ones with two of three points the same.  This is a "line" entity,
   and as such it is a nonsensical 3-D object and makes the program choke.
   Code added to detect and report line numbers that contain such objects.

3. Supersampling is made to be nonrandom on a run-by-run basis.  There is
   still a random jittering of the supersamples, but it happens based on
   the x-y coordinates of the object (similar to the way textures are
   "randomly" spread on object surfaces).  This makes for very consistent
   jittering of the samples and almost no "flying dots" or randomly scattered
   pixels as consecutive frames of an animation are rendered.

4. Misspelling of "Paraboloid" in the file PARABOLO.DAT corrected.

5. Removed usage message for an unimplemented option, -n.


Version 2.02:

1. Some functions were broken up into smaller parts to ease compilation memory
   requirements, and so nearly all functions can be globally optimized with
   MSC 6.0.  A couple of functions in parse.c and iff.c are still too large
   to globally optimize, but these are in the overlaid modules (see below)
   and the program only spends a fraction of its time in these functions once
   at the beginning of the trace, so I didn't feel it was worth breaking them
   into smaller routines.  Everything related to the actual scene tracing
   IS fully optimized, however.

2. ALL returns of malloc() (system memory allocation request) are checked for
   consistency, so no more silent crashes should occur from lack of memory.
   If any such thing does happen, it is probably related to stack usage.
   Stack size is reduced from 32K to about 12K.  The tracer's actual stack
   usage is quite moderate, since most things are malloc'ed.  Should be ok,
   but if not, read the READ.ME file for more on what to do...

3. RAW, IFF, and GIF Images are checked for a maximum size.  In the IBM/MS-DOS
   version, this limit is 64K pixels.  This translates into just a tad over
   320 x 200, but could be interpreted as 256 x 256 or 200 x 320, so long as
   the total of (rows * colums) is less than or equal to the maximum size.
   For the Amiga and Unix versions this can be unlimited, but is currently
   set at 640x480 and 800x600, respectively.  In actual use you probably will
   want to reduce the input image size, in order to have enough memory to
   allocate more than one image per scene.

4. Various minor things in many functions fixed to keep "LINT" and the pickier
   "C" compilers happy (added typecasts, etc...).

5. This version is compiled under MSC 6.0 rather than Turbo-C 2.0.  I had
   a friend who has this compiler crunch it down for me, and I was amazed!
   It runs 20% or so faster than the Turbo-C version (both using a math
   coprocessor) by my time trials.  MAKEFILE's are included for each, the
   MAKEFILE is for MSC and the MAKEFILE.TC file is for Turbo-C.  Also I
   am using the MS-LINK overlay feature now to share memory on the tokenizer,
   the parser, and the raw/iff/gif image readers.  This should give a bit more
   memory to the tracer to run in.  In theory the overlaying process should
   work for Turbo-C 2.0 as well because it seems to be just the linker that
   performs this, but I haven't tried it yet.  Look at the DKBMSC.LNK file to
   see how to do this.

6. Not a change, but note the utilities are compiled in 8086/No 8087 mode to
   be universal.  If you have an 80286 and/or 80x87 you may want to recompile
   them with the /G...2 and /FPi87 options (286 opcodes, 80x87 inline) for
   MSC (done by selecting the alternate CFLAGS in the MAKEFILE).  For Turbo-C,
   use the -1 -a options (286 opcodes, word alignment) by also selecting the
   alternate CFLAGS.  You will also have to select the alternate (floating
   point library) form of LINKFLAGS in the MAKEFILE if you have an 80x87 and
   are using Turbo-C.