BSPCOMP v1.0 - DOOM/DOOM II/HERETIC BSP Node compiler (c)1995 Jackson Software

NOTE: This compiler will NOT work for HEXEN wad files... the real mode version
      simply returns a heap overflow and the DPMI version returns a general
      protectio fault... I need more info on HEXEN before I write a node
      compiler that will work with it. (I noticed the BEHAVIOR entry in the
      level info, but this is not the source of error.)

This program is a cross breed between many of the other node compilers out
there.  It incorporates code from DEU, BSP12X, WARM14, and IDBSP, as well as
a few other tid-bits that I threw in.  It will automatically detect which 
type of WAD file you are compiling.

NOTE: A Math-CO is required!!

Usage of BSPCOMP is as follows:

   BSPCOMP {infile[.wad]} [outfile[.wad]] [-h] [-l[levname]] [-e] [-f] [-o]

   infile      The name of the input DOOM, DOOM II, or Heretic Wad file.
   
   outfile     The name of the output Wad file. (tmp.wad is default)
   
   -h          Displays the parameter help screen.
   
   -l[levname] Process level data only (Do not copy other resources into
               outfile.)  If levname contains the name of a valid level,
               only that level will be processed.
   
   -e          Expands the input levels to 200% of their original size.
               This is acheived by multiplying the Thing's and Vertice's
               x and y co-ordinates by 2 before compiling BSP info.

               This is great for those little deathmatch levels that work
               great for two players, but are too small for 3 or 4 players.

               WARNING: When you expand a level, some areas may become to
               large to "jump".  If a certain area of the board requires
               you to jump over a hole in the ground, you may want to
               use DOOM's -turbo parameter.  As for Heretic, I hope they 
               add a -turbo someday.

   -f          Flip the level around its Y axis.  This produces a mirror
               image of the original level.  This adds a new twist to things
               and can even become down right confusing if you are very
               familiar with the way a level used to be!

               Credit:  I copied this idea from WARM14 by Robert Fenske Jr...
                        COOL idea!

   -o          I'm not sure why I added this option!  It causes the compiler
               to do an exhaustive search for the best partition lines.  For
               each call to the compiler's PickNode function, it will
               make NumSegs^2 iterations.  This does produce about
               a 2% reduction in the number of nodes that are generated.
               Sounds ok, but the amount of time spent doing this is many,
               many times greater the its native method.  I have yet to
               notice a differece in game play with or without partition
               optimization. (To put things into perspective, using the -o 
               option will cause the compiler to make several MILLION more
               calculations!!)

               The method normaly implemented by BSPCOMP is based on ID's
               node builder source code.  The program will make 
               40 * NumSegs iterations and will only go back and 
               search through the list again is a good partition line 
               could not be found.  So basically, the way I see it, if
               it's good enough for ID to use on their own levels, it's
               good enough for my node builder!

               The only time this option might do some good, would be if
               you had a level that had a zillion little sectors inside
               one another. At this point, it might be a good idea to
               do some massive searching for the best partition lines. But,
               even then, I'm not sure it would make that big of a difference.

This program was written in Borland Pascal 7.00.  It is mostly Object Oriented
code that is part of a much larger "toolbox" that I have developed over the
span of my Dooming.  I have not released the source code for all of the
stuff that I have written for a few simple reasons... It's not commented, a
good section is not complete or is littered with bugs, and who besides myself
actually programs in PASCAL!?!?!? (I suppose if I had a good C compiler, I
might use C... but I am not real fond of compilers that don't have integrated
debugging environments such as gcc and the likes, and I can't afford Borland
C++ 4.5).

I did try to port this code into Borland C++ 3.1, but was found that the
heap manager leaves much to be desired!!!  It will not even compile a single
large level without leaving the heap so fragmented that crashes with an out
of memory error.

NOTE: The DPMI version of this program BSPCDPMI.EXE will handle any size WAD
      file that you can throw at it, but is roughly 15% slower that its real
      mode cousin.  You should also note that the real mode version is able
      to re-compile the complete DOOM,DOOM II, or Heretic IWAD files without
      running out of memory, and beleive it or not, it does not use any EMS/
      XMS/DISK memory swapping... how's that for efficeint?

      If you want to use the DPMI version, you must ensure that the files
      contained in the DPMIRTL.ZIP are available on the path. (If you
      already have any DOS based Borland products that implement the DPMI
      RTL, you probably alreay have these files)

Future versions of this program will problably include a Reject Data builder,
a lot of 386 assembler code (for greater speed), DOOM->DOOM2->Heretic level
conversion, and other nifty effects (such as the expansion and flip options).

   written by: Joshua Jackson
               Jackson Software

               
