1This ChangeLog contains a history of changes and development from v5 onward. 2 32006/08/12 4 5I have pulled the CVS from sourceforge, and converted as much as I can to a 6bzr repository - I plan not to distribute via sourceforge anymore (since I 7could not get bsp.sourceforge.net, I was never keen on hosting there). 8 9I have copied over the latest set of gcc warning options from PrBoom, and 10fixed the resulting compiler warnings. 11 122006/08/07 13 14Finally, I have decided to prepare a new release. I have freshened the 15configure script, and fixed some compilation problems on amd64. But I need 16to sort out which is the current development tree, and get away from using 17CVS hosted at sourceforge - waiting for the network to do a diff is no longer 18acceptable in the days of subversion and bazaar. 19 202003/03/03 21 22Changes from Hirogen2: 23- compiling with more warning flags 24- bsp.c: preserve Hexen lumps 25- endian.c: depending on the size of "int", swapshort() or swaplong() is 26 called. This fixes a possible stack corruption on big-endian systems where 27 "int" is 2 bytes, as swapint() converted (always) 4 bytes. 28- level.c, makenode.c: minor prototype & type cleanups 29 302002/05/04 31 32It seems my initial assessment of the fragglescript problem was well short. 33Simply not zeroing the length field for the lump is not enough - BSP overloads 34the lumplist->data field for both lump data and level data (i.e. the linked 35list of level lumps). 36 37It's a classic case of field overloading with a flag field (in this case 38lumplist->islevel) which is a horrid form of programming. So I replaced 39->islevel with ->level, a dedicated field for holding the linked list of level 40lumps (and which can be used in place of ->islevel for boolean tests). This 41frees ->data for its intended use so it can hold the lump data for map lumps. 42Tested on HR.WAD and seems to work fine. 43 442002/04/07 45 46Ok, Andre took the updated man page and reorganised it; merged his improved 47version. 48 492002/04/06 50 51At Andre's insistence, I updated the man page for bsp. I'd forgotten there was 52a man page actually. It wasn't being installed, so I added it to the 53Makefile.am. 54 552002/04/06 56 57Ok, crude approximation of a Zennode-like progress bar in place. 58 592000/08/27 60 61Fixed up a large number of memory leaks. Basically BSP was designed to do 62one level only, and the multi-level support was an afterthought. It 63did multiple levels, but memory-wise it assumed it needn't bother to 64free one level's stuff before moving on the the next. Since it's easy to 65fix, I fixed it. It's now practical to use it for multi-level PWADs. 66Builds doom.wad in < 1.5megs now (as compared to 15megs before). 67 68Added big endian support. Imported the extra code from the xwadtools 69version. I rely on autoconf to detect if the machine is big endian. 70No adverse affects on x86 - I also verified that it compiles if 71WORDS_BIGENDIAN is defined. Can't do a real test myself though. 72 732000/08/26 74 75Support for pipes and stuff was today's business. Added the isatty() 76test from the yadex version of BSP that supresses the spinning 77progress thingy when stdout is redirected. 78 79Added support for input being from a pipe. I'm writing for UNIX damnit, 80so it ought to be usable like other UNIX programs! :-) 81 82For input pipes, it just reads to a temp file, then reads back from the 83temp file. For output I was less sure what to do: there are 3 84senarios: 85 861) output to a file that either doesn't exist, or can be overwritten in any 87 case. 882) output to a file which we only want overwritten once the build is complete 89 and sucessful (e.g. writing the output back to the input filename) 903) output to a pipe 91 92For (3), we need to write to a temp file then copy to the pipe, because 93we have to be able to fseek(3) on the output file to write a Doom WAD. 94For (2), we need to write to a temp file then copy to the output when 95we're done. 96 97In the end, I went for an easy compromise. If the output file already 98exists (includes the case of a pipe), then we write the WAD to a temporary 99file, then copy it to the real output file once we're done. That copes 100with (2) and (3) fine. 101 1022000/08/25 103 104Made a makefile to built the test wads. I copied the test WADs to another 105machine, and ran original DOS BSP 3.0 on them, then made a note of the MD5 106sums of the resulting files. Using these I can check that my version is still 107producing identical results to the original v3.0. 108 1092000/08/23 110 111Checked in the BSP 3.0 source. Immediately ditched the existing makefiles and 112created GNU autoconf/automake ones - much less messy. 113 114First major problem to overcome was the crude existing build system - all the 115.c files were #include'd into bsp.c, which was kinda ugly. And whoever wrote 116this had an obsession with labelling everything "static" even though there was 117only one source file. Fun. 118 119