			WAD Auxiliary Resource Manipulator
	Version 1.1 of January 1995 by Robert Fenske, Jr (rfenske@swri.edu)
         Ported to OS/2 2.1 by Mark K. Mathews (mark.mathews@channel1.com)

	Summary of features:

		Fastest NODES/SSECTORS/SEGS builder on the planet
		Fastest BLOCKMAP builder on the planet
		Fully automatic REJECT resource builder
		Has various utility function options, including
			merging WADS and levels
			extracting resources
			substituting resources
			randoming things
		Works with DOOM I, DOOM II, and HERETIC WAD files
		Full source code
		Compiles and runs under these operating systems:
			MS-DOS, OS/2, SunOS 4.1.x, Solaris 2.x, Linux

	This is release 1.1 of my WAD Auxiliary Resource Manipulator, or
WARM and is an update of my original VNB node builder which I released in
May 1994.  I wanted some kind of catchy name and this is what I came up with.
Its main purpose is to build the NODES, SSECTORS, SEGS, BLOCKMAP, and REJECT
resources from the basic resources that compose a level.
	The programs WARMDOS.EXE (for MS-DOS), WARMOS2.EXE (for OS/2),
WARMSUN4.EXE (for SunOS 4.x), WARMSUN5.EXE (for Solaris 2.x); WARMLNUX.EXE
(for Linux); the corresponding makefiles, this text file WARM.TXT; the six
source files DMGLOBAL.I, WARM.C, WADIO.C, NODES.C, BLOCKMAP.C, and REJECT.C;
and the floating point emulation library EMU387 are included in the WARM11.ZIP
file.
	This release fixes a couple of bugs in my VNB nodes and blockmap
generation routines, increases the speed of node generation by about 30%,
includes a somewhat generic set of WAD I/O routines, includes a fully
automatic REJECT builder, and includes various utility functions that I
created for my own use but may be of use to someone.  It will also work with
either DOOM I, DOOM II, or HERETIC WAD files.  Note that during execution,
any MAP## levels are referred to as E4M## (I was too lazy to do otherwise).
	Executing the program with no command line arguments will display help
regarding the command line.  Note that there are several optional functions
available that are not related to the reject, nodes, nor blockmap creation.
Hopefully, most probably have an obvious function, but I'm not going to bother
to exlain any of them.  They are in this program because I did not want to
mess with more than one program to get all the functionality.
	To use this program on a computer without a math coprocessor requires
having the EMU387 floating point math emulation library.  The environment
variable GO32 must also be set as: "SET GO32=emu <dir>\EMU387" where <dir>
is the directory in which you have the EMU387 file located.
	Thanks to Mark Mathews for porting the code to OS/2, for performing
extensive testing, and for prodding me enough to make me finish this release.

	Since I have not seen any other program that does fully automatic
REJECT generation, I give an explanation of what the builder does in the
following paragraphs.
	The algorithm for generating the REJECT resource is given in the source
code.  Basically, it is built from strictly line of sight determinations
between all sector pairs.  For each sector pair, a check is made as to whether
any one-sided lines block the view of a chosen two-sided line from each sector.
I.e., if one-sided lines block the views of all two-sided lines of one sector
from all the two-sided lines of the other sector, then the sector pair is
deemed not in sight of each other.  Otherwise, the sector pair can see each
other (obviously).  However, the method used is not perfect and will not catch
all instances of line-of-sight.
	For each pair of test points, all potentially blocking one-sided lines
must be checked.  To avoid having to check all the one-sided lines of each
level, the BLOCKMAP is used to greatly limit the search.  Since the BLOCKMAP
is a record of which lines are in each 128x128 block of the map, and since it
is fairly easy to compute which blocks are between a pair of test points, the
BLOCKMAP provides a ready list of only those one-sided lines that are
potentially in the way of line of sight.  Even with this method, the process
is still computationally expensive; for large levels the REJECT computation
takes far longer than the nodes generation.  The program does have an option
to produce just a zeroed REJECT resource, so the possibly lengthy computation
time can be avoided.

	Any comments, etc about WARM can be directed to rfenske@swri.edu.  If
you do find any WAD file that WARM does not process correctly, I especially
want to know about it.
