home *** CD-ROM | disk | FTP | other *** search
/ Quake 'em / QUAKEEM.BIN / doom_ii / program / edmap140.exe / WARM11.TXT < prev    next >
Encoding:
Text File  |  1995-07-16  |  4.5 KB  |  78 lines
  1.             WAD Auxiliary Resource Manipulator
  2.     Version 1.1 of January 1995 by Robert Fenske, Jr (rfenske@swri.edu)
  3.          Ported to OS/2 2.1 by Mark K. Mathews (mark.mathews@channel1.com)
  4.  
  5.     Summary of features:
  6.  
  7.         Fastest NODES/SSECTORS/SEGS builder on the planet
  8.         Fastest BLOCKMAP builder on the planet
  9.         Fully automatic REJECT resource builder
  10.         Has various utility function options, including
  11.             merging WADS and levels
  12.             extracting resources
  13.             substituting resources
  14.             randoming things
  15.         Works with DOOM I, DOOM II, and HERETIC WAD files
  16.         Full source code
  17.         Compiles and runs under these operating systems:
  18.             MS-DOS, OS/2, SunOS 4.1.x, Solaris 2.x, Linux
  19.  
  20.     This is release 1.1 of my WAD Auxiliary Resource Manipulator, or
  21. WARM and is an update of my original VNB node builder which I released in
  22. May 1994.  I wanted some kind of catchy name and this is what I came up with.
  23. Its main purpose is to build the NODES, SSECTORS, SEGS, BLOCKMAP, and REJECT
  24. resources from the basic resources that compose a level.
  25.     The programs WARMDOS.EXE (for MS-DOS), WARMOS2.EXE (for OS/2),
  26. WARMSUN4.EXE (for SunOS 4.x), WARMSUN5.EXE (for Solaris 2.x); WARMLNUX.EXE
  27. (for Linux); the corresponding makefiles, this text file WARM.TXT; the six
  28. source files DMGLOBAL.I, WARM.C, WADIO.C, NODES.C, BLOCKMAP.C, and REJECT.C;
  29. and the floating point emulation library EMU387 are included in the WARM11.ZIP
  30. file.
  31.     This release fixes a couple of bugs in my VNB nodes and blockmap
  32. generation routines, increases the speed of node generation by about 30%,
  33. includes a somewhat generic set of WAD I/O routines, includes a fully
  34. automatic REJECT builder, and includes various utility functions that I
  35. created for my own use but may be of use to someone.  It will also work with
  36. either DOOM I, DOOM II, or HERETIC WAD files.  Note that during execution,
  37. any MAP## levels are referred to as E4M## (I was too lazy to do otherwise).
  38.     Executing the program with no command line arguments will display help
  39. regarding the command line.  Note that there are several optional functions
  40. available that are not related to the reject, nodes, nor blockmap creation.
  41. Hopefully, most probably have an obvious function, but I'm not going to bother
  42. to exlain any of them.  They are in this program because I did not want to
  43. mess with more than one program to get all the functionality.
  44.     To use this program on a computer without a math coprocessor requires
  45. having the EMU387 floating point math emulation library.  The environment
  46. variable GO32 must also be set as: "SET GO32=emu <dir>\EMU387" where <dir>
  47. is the directory in which you have the EMU387 file located.
  48.     Thanks to Mark Mathews for porting the code to OS/2, for performing
  49. extensive testing, and for prodding me enough to make me finish this release.
  50.  
  51.     Since I have not seen any other program that does fully automatic
  52. REJECT generation, I give an explanation of what the builder does in the
  53. following paragraphs.
  54.     The algorithm for generating the REJECT resource is given in the source
  55. code.  Basically, it is built from strictly line of sight determinations
  56. between all sector pairs.  For each sector pair, a check is made as to whether
  57. any one-sided lines block the view of a chosen two-sided line from each sector.
  58. I.e., if one-sided lines block the views of all two-sided lines of one sector
  59. from all the two-sided lines of the other sector, then the sector pair is
  60. deemed not in sight of each other.  Otherwise, the sector pair can see each
  61. other (obviously).  However, the method used is not perfect and will not catch
  62. all instances of line-of-sight.
  63.     For each pair of test points, all potentially blocking one-sided lines
  64. must be checked.  To avoid having to check all the one-sided lines of each
  65. level, the BLOCKMAP is used to greatly limit the search.  Since the BLOCKMAP
  66. is a record of which lines are in each 128x128 block of the map, and since it
  67. is fairly easy to compute which blocks are between a pair of test points, the
  68. BLOCKMAP provides a ready list of only those one-sided lines that are
  69. potentially in the way of line of sight.  Even with this method, the process
  70. is still computationally expensive; for large levels the REJECT computation
  71. takes far longer than the nodes generation.  The program does have an option
  72. to produce just a zeroed REJECT resource, so the possibly lengthy computation
  73. time can be avoided.
  74.  
  75.     Any comments, etc about WARM can be directed to rfenske@swri.edu.  If
  76. you do find any WAD file that WARM does not process correctly, I especially
  77. want to know about it.
  78.