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 \EMU387" where 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.