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.
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).
