ProfitPress Mega CDROM2 …eeware (MSDOS)(1992)(Eng)/ProfitPress-MegaCDROM2.B6I/GRAPHICS/MISC/DKBTRACE.ZIP/WHATS.NEW

Text File | 1990-08-09 | 6.9 KB | 127 lines

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


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.


Version 2.03:

1. IBM Version utility DUMP2RAW adjusted its output file extension based on
   Amiga or IBM being defined.  The wrong one (Amiga) was left uncommented.
   This caused the output files to be named .red, .grn, and .blu.  It was
   intended for the IBM the extensions be .r8, .g8, and .b8, for compatibility
   with PICLAB's "RAW" format.

2. MAX_CONSTANTS raised from 100 to 250.  This should now allow more lengthy
   color definition files to be included regularly in BASICSHA.DAT without
   giving the dreaded "Too many constants" error during parsing.

3. The good 'ol Microsoft Overlay Linker (NEVER buy a M-S product that has
   a version number ending in .00!!) turns out to be what caused a wierd
   problem writing TARGA files at 800x600 resolution.  The problem appeared
   as though horizontal chunks of 20-30 lines were randomly skewed to the
   left and right, and the problem somehow did not affect the DKB/QRT "RAW"
   file output format.  Strange.  Well, anyway the program is no longer
   overlaid, so it will take SLIGHTLY more memory to run.  However, the output
   will be correct.  I have not had any problems running with 550K free RAM.

   (Note: Version 2.03 was not generally available for distribution, so don't
   feel bad if you missed it...)

Version 2.04:

1. The Microsoft compiler uses signed characters by default.  The Turbo-C
   compiler and the Amiga Lattice compiler both used unsigned chars.  This
   is corrected by using the /J option of MSC which changes the default to
   unsigned chars.  This was causing color shades to be all but ignored when
   using the display (-v +d) options (caused dull looking colors on screen)
   but the trace data output files (.TGA, etc.) were correct.

2. An astute user, Albert Waltner, caught an error in the original FRACTINT
   GIF reader, GIF.C, at line 188, and reported it to me.  It caused the
   'conditional expression is constant' compiler diagnostic.  This was caused
   by comparing an unsigned char to < 0, which you really can't do.  The "C"
   compiler was then converting this impossible condition to "FALSE".  I
   believe I have figured out what the authors were trying to do originally
   (looking for EOF or -1 returned) and have corrected it.

3. The noise() functions we use evaluate the way the compiler deals with float
   numbers, and has differing results based on the type of "C" compiler used.
   This can sometimes cause the noise() functions to generate slightly dif-
   ferent results that prior versions did.  More specifically, sparse clouds
   in BOZO mode, and either uninteresting or crowded marble textures.  You may
   need to play around with the COLOUR_MAP thresholds or TURBULENCE values to
   obtain the best results.  This is neither a compiler nor program bug per
   se, but it explains why some scenes may look different now, and I felt that
   it should be mentioned.