deathz0r Posted September 19, 2023 (edited) 19 hours ago, Redneckerz said: All i am doing is looking at your date of DOPE (December 1993) and saying it can change something from the WAD file. It is very likely that i quantify changing objects in a WAD with altering a WAD file, in which case, i am dumb. Too often in these matters i have this shitty shtick of saying something related but not absolute, whereas your research revolves around absolute statements. I initially wrote something to this and eventually I decided "nah fuck it I'll just check USENET rather than simply continue with being suspicious". I can confirm that DOPE v1.01 was released around February 6th, with v1.1 (have not found it) being released on February 10th. I can not find a correct date for v1.2, but given the "file date" difference between v1.01 and v1.2 my estimated guess is February 15th - coincidentally, my copy of DOPE12.ZIP is dated February 22nd. This discussion post from USENET implies that an earlier version was released at some point by February 3rd, but I doubt that it was much earlier than this. On the flip side, there is a map viewer that is dated January 5th 1994 simply called DOOM Utilities, made by Bill Kirby (who made a name for himself with his Wolf3D map editor being released shortly after the release of Wolf3D) whose date can be confirmed by this USENET post. I've attached DOOM Utilities to this post. As for the remaining editors/resources of information from January, everything else can be confirmed by extant USENET posts: DMAUD 0.2 Jumble 1.02 (announcement post deleted, just like everything else posted by Hank Leukart) IWADDUMP.ZIP (not an announcement post, but a discussion post that correlates close enough with the file dates, author email is also listed in the credits for DOPE documentation) RanDOOM 1.0 (other posts by author regarding RanDOOM can be found with this search, more importantly I can confirm the author's name) DTEDIT 1.0 (all other versions except for v2.0 can be found with this search, while v2.0 can be found here) Unofficial DOOM Specs v1.0 (once again, announcement post deleted) DEU 2.00 DEU 3.01 Renegade Graphics DoomED 0.5 (discussion post, doesn't appear that an announcement post was ever made - this discussion post regarding v0.6 implies that Joe Pantuso didn't have USENET access at this time) Additionally, there's this snippet of source code that doesn't appear to be related to anything that was released. 19 hours ago, Redneckerz said: And yes, i am aware of that text file - But that's exactly why i am speculating about the source file, if they used some kind of script or not. The last thing though, the first WADS had their nodes generated by hand - <- How does one do this, considering the state of editors at the time. Apologies, you had a perfectly reasonable question there with your previous post that I brushed off too quickly - that's on me! I'll just leave a quick info dump for now, in chronological order: This USENET post from David Simpson from January 13th is the earliest thing I can find with trying to decode the NODES lump. IWADDUMP (January 15th) has this in its source code snippet, not descriptive but it's a starting point: typedef struct{ int x,y; /*how big is this????*/ int a,b; int p[8]; int l,n; }NODE; Unofficial DOOM Specs v1.0 (January 21st) does not mention anything useful regarding nodes. Unofficial DOOM Specs v1.1 (February 21st) has the following information regarding the NODES lump: Spoiler [3-8]: NODES ============ There are ((number of SSECTORS) - 1) NODES. Each NODE has 14 (integer) fields: 1. X coordinate of nodeline's start 2. Y coordinate of nodeline's start 3. X offset to end of nodeline 4. Y offset to end of nodeline thus 64, 128, -64, -64 would be a nodeline from (64,128) to (0,64) 5/6. Y coordinates bounding the nodesq1 on the right side of the nodeline. 7/8. X coordinates bounding the nodesq1 on the right side of the nodeline. 9/10. Y coords bounding the nodesq2 on the left side of the nodeline. 11/12. X coords bounding the nodesq2 on the left side of the nodeline. 13. Is a NODE or SSECTOR number for nodesq1. If bit15 of this 2-byte field is set, it means that the nodesq1 contains the SSECTOR whose number is in the remaining bits. If the bit15 is not set, then nodesq1 is a previously listed NODE. 14. As with field 13, for nodesq2 on the left. Each node is thus a "sum" of two other rectangular horizontal spaces, each of which contains either a NODE or a SSECTOR. So there is a heavy iterative aspect to this structure. The final NODE is always the size of the entire level. When a SSECTOR is being "contained", the X and Y coordinates of the nodesq are such that every SEG in that SSECTOR is completely within the nodesq. If a NODE is being "contained", then the coordinates will bound the furthest extent of that (recursed) NODE. So what are the nodes for? I don't know yet. Stopped working on it a while back. Will finish sooner or later. Also, need to create an algorithm to generate the segs, ssectors, and nodes, given the vertexes and linedefs. NewDEU 4.2 (February 25th) has this in the source code for reading the NODES lump: /* read in the nodes information */ dir = FindMasterDir( Level, "NODES"); NumNodes = dir->dir.size / 28; Nodes = GetMemory( NumNodes * sizeof( struct Node)); BasicWadSeek( dir->wadfile, dir->dir.start); for (n = 0; n < NumNodes; n++) { BasicWadRead( dir->wadfile, &(Nodes[ n].x), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].y), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].dx), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].dy), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].miny1), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].maxy1), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].minx1), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].maxx1), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].miny2), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].maxy2), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].minx2), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].maxx2), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].tree1), 2); BasicWadRead( dir->wadfile, &(Nodes[ n].tree2), 2); } With regards to ORIGWAD, while the text file does not explicitly mention anything we can note that the Unofficial DOOM Specs v1.2 (March 6th) mentions Jeff Bird in the acknowledgments section for more information regarding nodes are built: Spoiler [1-1]: Acknowledgements ======================= I have received much assistance lately from the following people. They either brought mistakes to my attention, or provided additional information that I've incorporated into these specs: Ted (tedv@geom.umn.ed) - I had the THING angles wrong. Unforgivable. Matt Tagliaferri (matt.tagliaferri@pcohio.com) - I forgot to describe the TEXTURE1/2 pointer table. Also, gave lots of help with linedef types. Raphael Quinet (quinet@montefiore.ulg.ac.be) - The author of the NEWDEU editor; new info on linedef types and attributes, special sectors. Robert Fenske (fenske@swri.edu) - part of the VERDA team, gave lots of help on linedef attributes and types, blockmap list, special sectors, and other stuff John A. Matzen (jamatzen@cs.twsu.edu) - instrument names in GENMIDI. Jeff Bird (jeff@wench.ece.jcu.edu.au) - good ideas and suggestions about the nodes. Sorry if I left anyone out. Thanks for all the help! [4-8]: NODES ============ This is what we need to figure out! The nodes are branches in a binary space partition that divides up the level and is used to determine which walls and floors are in front of others, thus "clipping" the walls behind from the virtual view. The nodes/ssectors/segs resources are used exclusively for these display purposes, and seem to be precalculated to ease the burden on the game engine. There are ((number of SSECTORS) - 1) NODES. Each NODE has 14 (integer) fields: (1) X coordinate of partition line's start (2) Y coordinate of partition line's start (3) DX, change in X to end of partion line (4) DY, change in Y to end of partion line thus 64, 128, -64, -64 would be a partition line from (64,128) to (0,64) (5) Y upper bound for the first bounding-box (6) Y lower bound (7) X upper bound (8) X lower bound (9) Y upper bound for the second bounding box (10) Y lower bound (11) X upper bound (12) X lower bound Each node has two "children", each of which is either a node or a ssector. The bounding box is just big enough to contain whatever is in the "child", e.g. if the child is a ssector with 1 seg, then the bounding box will be just big enough to contain the extents of the seg (and thus a bounding "box" can have zero width, for a horizontal or verical seg) If the child is a node, the bounding box will be just big enough to hold both of its children. (13) a NODE or SSECTOR number for the first bounding box. If bit 15 is set, then the rest of the number represents the child SSECTOR. If not, the child is a recursed node. (14) a NODE or SSECTOR number for the second bounding box. So there is a heavy iterative aspect to this structure. The final NODE is always the size of the entire level. I am optimistic that a valid set of nodes/ssectors/segs can be generated from a set of vertices and lines by some automatic algorithm, but so far it isn't happening. Once this problem is solved, we will be able to create levels from scratch! CROSS has MAKE-LVL.TXT, which for some reason I can't find the USENET post that this is copy+pasted from. There's this USENET post from March 11th which is a copy of "Explaining the NODES", a text document that I haven't searched for at this point. With all of this information, you can eventually brute-force something as all data in the NODES lump are 16-bit signed integers, mostly related to X/Y co-ordinates except for the last two, which are for referencing child nodes. What I do find interesting is that the source code for NewDEU 4.2 does explicitly reference the last two integers as "trees". I haven't spent time digging through USENET posts for further information, but February 1994 would be a good month to sift through as January 1994 doesn't have anything of interest other than a couple of questions. I have not found a copy of v1.1 of the Unofficial DOOM Specs, so I have no idea if any information is included that would be relevant. EDIT 2: Once again, Supergames Volume 2 delivers on the goods and has a copy of the v1.1 specs. EDIT: Another interesting thing I found is this USENET post which indicates that David Simpson was able to make a hand-made level as early as January! I'm surprised that they didn't upload it anywhere to flex that they made the first custom level. 19 hours ago, Redneckerz said: Now, it begs to wonder if there are any levels out there that are built with BSP 0.9.. (Disclaimer: I didn't read any texts, i am at work.) The only possible WAD I can think of was DYLAN2.WAD given Dylan Cuthbert's working relationship with Colin Reed, but I did a node rebuild on that with BSP 0.9 and the data had changed. 19 hours ago, Redneckerz said: Hand on my chest that i am not! When it comes to this kind of things i often ask a whole lot of things that is only tangibly related to the source material. This isn't just to fuck with you, its just for clarity. All good, it just threw me off a fair bit seeing it several times in a single post :) 22 hours ago, thestarrover said: Is it maybe a custom/modified version of another editor? No, however the amusing thing is that WADED has a very similar UI layout, though the first version of that was released three months later. DMUTIL01.ZIP Edited September 19, 2023 by deathz0r David Simpson USENET posts, DOOM Specs v1.1 6 Quote Share this post Link to post
Redneckerz Posted September 19, 2023 (edited) Own history tidbits: Inspired by the above, i took a scour over the usenet archives myself - and found some goodies too. DEHACK: Several months later, in June 1994, Matt Fell of the Unofficial Doom Specs wrote Hacking The Doom.EXE, an article on how to read the THINGS and FRAME tables and so on. Included were 5 QBASIC programs that would dump these tables into a human readable format. These were started on March 4, 1994 (the THING table), so around the time most of the structures sans NODES were known. As you can tell, there is no NODES.BAS. This isn't unlike the program Alistair Brown made which actively generated all the needed structures, but it provided a less technical audience a way to inspect Doom's inner structure without a hex editor. As such these QBasic programs provided a more general starting point for players as opposed to programmers (who would scour over DEU instead). I have dumped the timestamps and what each DEHACK file does directly from the .BAS file as its just human-readable text. DEHACK 1 - The text strings which form the first part of the data segment. - written 3/17/94, last revised 6/13/94 DEHACK 2 - The THING TABLE - written 3/4/94, last revised 6/13/94 DEHACK 3 - The FRAME TABLE - written 3/5/94, last revised 6/13/94 DEHACK 4 - The SPRITE NAME LIST - written 6/13/94 DEHACK 5 - The SOUND TABLE - written 6/13/94 ' These crude programs extract information from the DOOM.EXE or DOOM.WAD ' files and store it into a TXT file, suitable for perusing or printing. ' If you want to print the results, you might have to reformat it. Please ' don't waste reams of paper. Thanks. ' All of these only work on the 1.2 registered doom.exe, because I use ' simple byte offset numbers, not search strings. DEHACK (June 15, 1994) HEX HACKER: I once wrote about Doom Hockey, a very early WAD by Seth Cohn that patches up the Doom.exe binary before DeHacked did. This is what it did: Spoiler Comes with a pre-Dehacked binary patch, PATCH.HKY, which is utitlizing an executable called HACK.EXE. PATCH.HKY is generated by a utility called Hex Hacker 1.01 and which will ''patch''/rename the Doom engine to NORMAL.EXE, utilizing similar methods like DoomHack. It is a pre-DeHacked, pre-DeusF form of patching. The WAD is utilizing a voodoo doll as a puck to implement a new game mode. Included in the archive is HACK.EXE - Hex Hacker. As it turns out, Hex Hacker has had some history of its own: A Usenet post dictates it was released on December 15, 1993 as DOOMHACK.ARJ and as a Save Game Editor. Sadly, that specific archive is gone, as the only available file with this name is something differently entirely. Save Game Editors modified a Doomsave.dsg file to tamper with the contents - This is before much of the WAD structure was even understood. Hex Hacker directly edits the binary. The HACK.EXE from Doom Hockey is even earlier - December 12, 1993. This would mean this was released a mere two days after Doom's release, making it one of the earliest third party programs for Doom. Matt Fell (of the Unofficial Doom Specs) posted a full patch on June 15, 1994 in a USENET post for usage with HACK.EXE. Its called EFFECTS.PAT and has to be launched from a batch file (called EFFECTS.BAT) against Doom.exe 1.2: Spoiler =====this is the text of EFFECTS.BAT=====cut this line!================== @echo off echo Special Effects! echo. echo I'm going to patch doom.exe (after I back it up to doomnorm.exe) echo To switch back to normal doom, run this batch file again. echo Note this only works with the registered 1.2 doom. echo For information on what's different, read the file effects.pat echo. pause if not exist doom.exe goto bailage if exist doomnorm.exe goto normal echo Copying doom.exe to doomnorm.exe copy doom.exe doomnorm.exe echo Patching for Special Effects. hack.exe effects.pat doom.exe > nul goto end :normal echo Copying doomnorm.exe to doom.exe del doom.exe copy doomnorm.exe doom.exe del doomnorm.exe goto end :bailage echo Please run this patch from the DOOM directory :end ===========here ends EFFECTS.BAT====cut this line!======================= ==========this is the text of EFFECTS.PAT======cut this line!============= /*************************************************/ /* Patch File for Special Effects! */ /* Only works with registered 1.2 doom */ /* First back up DOOM.EXE */ /* Then, usage: hack effects.pat doom.exe */ /* Or, simply run EFFECTS.BAT! */ /*************************************************/ /* This demonstrates SOME of the things that are */ /* possible by patching the doom.exe file. Look */ /* for an a file on ftp called DEHACKER.ZIP or */ /* see the article "Hacking DOOM.EXE" on */ /* alt.games.doom - this article will probably */ /* end up in the coming soon doom specs 1.4 */ /* --=--Matt Fell (matt.b...@acebbs.com)--=-- */ /*************************************************/ 08B475 66 /* Imps walk on air WORKS */ 08B4CE 44 /* Regular troopers inviso WORKS */ 08B4D4 76 /* Sargeants look and sound like players */ 08B4DC 77 /* BUT THEY DON'T MOVE */ 08B4EC 7D /* WHY NOT? */ 08B4F4 19 08B4FC 7B 08B500 7F 08B504 86 08B508 2A 08B564 02 /* Demons are slooooow WORKS */ 08B844 1E /* Cacodemon shoots 'lost souls', sort of */ 08B845 01 /* BUT THEY DISAPPEAR IMMEDIATELY, LAME. THIS IS LIKE WITH */ 08B870 28 /* THE SARGEANTS. MAYBE IT HAS TO DO WITH FIELDS 4-5 IN THE */ 08B871 01 /* FRAME TABLE (AND MAYBE IT'S NOT 2 2-BYTE INTEGERS, I */ /* NOW THINK IT MIGHT BE A SINGLE CODE-POINTER) */ 08B8D6 03 /* Baron's fireball's sloooooow, like floating worms WORKS */ 08B8F8 01 /* You can shoot rockets out of the air WORKS */ 08B8F9 00 08B924 73 08B944 14 ==========here ends EFFECTS.PAT=======cut this line!====================== Doom Cheat Patch (by Ziria) was a very early patch that patched your executable for various enhancements: Maximum health of 65535%, starts out with BFG9000 (on reg. version), max shells, and so on. As it turns out, this too used HACK.EXE. It was found on the DOOMMISC directory of the Sprint OS 5 disc, the text file indicates 1.1 was released on FTP and 1.0 was the first release. The patch files, despite their weird extension can be viewed in Notepad. Doom Cheat Patch 1.1 (March 13, 1994) Doom Cheat Patch 1.2 (March 15, 1994) DOOM UTILITIES: Originally, Bill Kirby had an early idea of modifying a WAD, per his January 14, 1994 USENET post: Here's the system I came up with, although I don't have my editor working just yet: My editor will output a .DU (DOOM Utilities) file which contains only the things you changed in the .WAD file. You can then install this into a registered version .WAD file using a little command line utility called DUINST.EXE When I modify a .WAD file I don't erase anything, I just add to it. This will allow you to restore any modified .WAD file just by running RESTORE.EXE on it. So to distribute any changes, you include the .DU file and the DUINST and RESTORE programs. Sadly Bill Kirby didn't finish this through. The only released version 0.1 is merely a viewer. Like Dooze, it is very much built off the Unofficial Doom Specs. REJECT.EXE: We all know RMB by Jens Hykkelbjerg, right? A REJECT builder that speeds up line-of-sight calculations. IDBSP did this (But this is not mentioned on the Wiki, nor does REJECT builder), and RMB does this to this very day. But alongside RMB, there was REJECT.EXE by Lee Witek. This too was found on the Sprint OS 5 disc. Includes source under the GPL v1 license. Witek wrote REJECT for a simple reason: I wrote REJECT10 originally for one purpose: to speed up starwar1.wad which ran too slowly on my machine to be playable. After processing the wad with REJECT10 it plays at a decent speed. This is something that IDBSP does not do (I'm not convinced IDBSP uses true LoS calclations either). REJECT had some criticism from some people, stating that it doesn't do LOS calculations. Witek replied this with the following: REJECT10 *DOES* generate valid REJECT resources is as much as they have the required effect of reducing the amount of work (ie line of sight calculations) which has to be done by the DOOM engine therefore making the game faster. Just because it does not use the same algorithm as id used to create their levels does not (IMHO) make REJECT10 invalid. The method REJECT10 uses IS simplistic, I must admit, but it is also effective on most levels. There are some levels on which it is not suitable such as those with large open courtyard type arrangements, but no one is forcing you to use it. However, it was mentioned that REJECT.EXE tends to screw up with monster behavior. I haven't tested this. Several early WADS used REJECT.EXE in its intended way of speeding up calculations, sometimes with DEU2C (Which is one of those DEU edits Deathzor mentioned) There is a REJECT 2.0 mentioned, but it was never released. There were two versions: Reject 1.0 (June 1, 1994), released on June 5 1994 Reject MP (October 28, 1994) - On surface, this is the same as Reject 1.0, but with a different timestamp. The CRC's are identical, despite a 1 byte difference in many files. Reject 1.1 (November 19, 1994) VNB: Even lesser known than REJECT.EXE is VNB by Robert Fenske, the author of VERDA. This is not only a REJECT builder, it is also a NODES builder. VNB thus stands for Verda Node Builder. VNB is interesting from a historical perspective because Fenske started this around March 1994, so around the time DEU5BETA released its first nodesbuilder. Several WADS have used this. The text file contains a lot of interesting perspective, including creating the nodebuilder out of the Unofficial Doom Specs and it includes some source files too: Well, I've finally gotten around to finishing my node builder. I started it last March, but got interrupted during April and half of May. The program builds the NODES, SSECTORS, SEGS, and BLOCKMAP resources of a PWAD file, IWAD file, or VERDA patch file. (VERDA is our level editor whose lastest version will be released one of these days.) This release is version 1.050. The program VNB.EXE, this text file VNB.TXT, and the four source files DMGLOBAL.I, VNB.C, NODES.C, and BLOCKMAP.C are included in the VNB.ZIP file. The program is fairly quick and, except for a couple of instances produces, fewer NODES and SEGS than id Software's generator (which suprised me since I had expected id to have their generator highly optimized). The program can process E2M7 from DOOM.WAD (the largest level) in about two minutes on my 486/33. The BLOCKMAP generator is extremely fast and processes any level in under a second. Executing the program with no command line arguments will display help regarding the command line, but essentially after processing an input file, the program can either rewrite the input file or write to a different output file. I wrote the node generator from the description of the nodes given in Matt Fell's Unofficial DOOM Specs; the blockmap generator algorithm is my own idea. I did most of the coding and debugging on a Sun, hence the code will compile and run on either a Sun or a PC. I didn't handle the byte-swapping in the most elegant way, but I don't want to take the time to make it any cleaner. It isn't on /idgames. VNB 1.050 (May 25, 1994) (Announcement post on Usenet) WARM: Robert Fenske wouldn't be done yet, as he would release another node and REJECT builder - WARM, or WAD Auxiliary Resource Manipulator. As writing this post becomes very long, i just list the one version that is on /idgames: WARM 1.6 (January 31, 1996) In much the same manner there is JBSP. I find that even the /idgames directory has a lot of undocumented stuff, not so much the earlier days perse, but still very useful. Addendum: @deathz0r i know you just mentioned things like Doom Utilities as i was writing this post (since yesterday). You mentioned not finding the USENET post where MAKE-LVL.txt from CROSS.WAD is from. That is this USENET post. It refers to a custom program he made using a modified PWAD writing routine from NewDEU. Sadly that program has been missing. PS: I gotta love that David Simpson post and how blind i am - I found this one yesterday too, but unlike you who actually reads a post in full, i merely glanced over it and looked at the time stamp. I didn't read ''I doubt it is the first since i made one a month ago'', can you imagine?: But yeah, David Simpson's WAD is a strong contender then for first WAD. And, unless we would contact him or Alistair, lost to time. PPS: The authors of Jumble, Empty Productions, were working on a map editor called JADE (Or Just Another Doom Editor) as early as January 1994. Considering not much of the Doom structure was known back then, it remains curious what JADE could do. USENET post reference (January 13, 1994). The Doom FAQ mentions: JADE - Just Another DOOM Editor. 640x480x256 color VESA standard support. Level editor with Mouse support. - FEATURES / Special Effects - - Map transformations : MIRROR BEND RIPPLE SKEW STRETCH TIGHTWAD SQUASH BUBBLE "AutoMake" - Integrated JUMBLE. - Perspective View of Level. (Possibly with Texture mapping) Edited September 19, 2023 by Redneckerz Reference to JADE 4 Quote Share this post Link to post
Redneckerz Posted September 19, 2023 (edited) Double post but this is by sheer accident, again from the Sprint OS 5 CD. Unless i am completely blind, this isn't on Usenet. EDIT: I am blind. Jason Hoffoss didn't had a USENET account yet, so Paul A Hagstrom released it, on March 31, 1994. Posted for Jason Hoffoss, I'll take email responses until his account is up and running.. ===== Included text ===== That's right. I have written a node generator for DMapEdit, and am releasing the routines for it. They don't quite seem to work right, but I'm hoping that with the source for it out there for everyone to look at, someone might be able to figure out what the problem is. It is a little complex, isn't obscenely commented, and my programming style is a little unique, but it is a good example of some of the more difficult programming problems out there. It's called "NODE_GEN.ZIP". It contains 2 files, a C source, and an informational text file about the C source. So, anyone interested, knock yourself out. Be advised, however, that it isn't a stand alone program. If you are not a programmer, then it's useless to you as it is. If you are just starting to learn to program, don't blame me if you head explodes from trying to understand these routines.. BTW, DMapEdit v1.2 is coming along. It should be released sometime sorta soon. Anyway, later.. -Jason Hoffoss DMapEdit author ===== End included text ===== Jason Hoffoss's NODE_GEN: If DEU5BETA (March 17, 1994) contains the earliest known nodegenerator, then NODE_GEN.C is fairly close too, being made on March 30, 1994. It was released by Jason Hoffoss, author of DMAPEDIT. He released this standalone node generating algorithm as an auxillary piece of information. Compiling it doesn't instantly land you a fully functioning nodesbuilder, but it gives you a good idea of how to merge this algorithm with the other parts of the WAD. Hoffoss indicates that a fully working version will also be released. It may very well be that DMAPEDIT 2.0 has this, but on its own, this is a fantastic piece of early code that highlights how people were making these. It also gives an idea how Alistair Brown made his WAD to begin with. EDIT: DMAPEDIT 2.0 did release with a node generator. It seems to generate nodes: void generate_nodes(void); void add_node_list(int far *list, int *index, int line, int v1, int v2); uint nodize(uint size, int far *list); int resolve_space(int line, int size, int far *list, int far *left_list, int far *right_list, int *lx1, int *ly1, int *lx2, int *ly2, int *rx1, int *ry1, int *rx2, int *ry2, int test); void add_node_list2(int far *list, int index, int line, int v1, int v2, int *x1, int *y1, int *x2, int *y2); int make_seg(int line, int v1, int v2); int calc_line_cross(int *y, int x1, int y1, int v2, int v3, int v4); uint calc_angle(int x1, int y1, int x2, int y2); int adjusted_angle(uint angle, int x1, int y1, int x2, int y2); void adjust_limit(int x, int y, int *xmin, int *ymin, int *xmax, int *ymax); void error(char *msg); void fatal_error(char *msg); But the text file is more interesting. It describes how it has minor errors still, and how it was tested on CROSS.WAD. Furthermore, it explictily mentions that at this time frame, only Hoffoss, The DEU crew, and ID Software have made Node builders. Because of it, i include it in its entirety here in code, because it retains the structure: -------------------------------- NODE_GEN.C Written by Jason Hoffoss Copyright (C) 1994 Jason Hoffoss -------------------------------- Notice: I give hereby give permission to everyone to copy, distribute, and use these routines, in part or as a whole, so long as it is stated that I am the original author of these routines. Routines based or derived from these routines should also state that they are based or derived from my routines. You may not sell these routines, but you can sell programs with routines based or derived from these routines, or incorperating these routines, if these routines comprise less then 20% of your program. Ok, so here is an algorithm I wrote to generate nodes. It has all the routines and structures it need run inclusive, however it is not a stand alone program. If you try to just compile it, you will get an error stating that the function "main" was not found. Simply adding the function "main" and compiling it again will also not work. It will compile at that point, but it will not have any data from which to generate the nodes. It doesn't contain any routines for reading a wad file, either. The purpose of these routines is to be informative, and to be used in other programs. The main entry point to generate nodes is (of course) "generate_nodes()". WARNING: These routines don't fully work yet. I don't know what's wrong with them exactly, but I am sure it's something minor. Therefore, the third purpose of releasing these routines is so that hopefully someone can figure out what I'm doing wrong. From the information currently available on nodes, it is working fine. When you give it to doom to use, however, it doesn't work so desirably. Sometimes you get "hyper-junk" walls. I have also gotten a "M_Player located in unknown special sector #29" (and it isn't a sector problem, either.) I think there's something else that needs to be done that no one has mentioned yet. My favorite map to use for testing node generation is CROSS.WAD. Being the simple map that it is, it's easy to see how everything fits together. These routines will pick the same first nodeline as the author used, however all nodelines thereafter are picked differently. Why? Better balance on the two sides. If anyone has ideas on a better way to tell which nodeline should be used, let me know, eh? Anyway, using CROSS.WAD, we end up with 6 nodes, 7 sub sectors, and 28 segments (no splits). Here's a diagram of what it generated: +++++ + + + + +++ single sided linedef + 6 + + + --- double sided linedef + + +B+++---+++++ ... imaginary node bounding limit + + + 5 + A-F nodelines: letter is at tail of line +A+++++++...........+++++++++ + | F + 1-7 Sub Sectors + 2 E 0 | 1 + +++++++++...........+++++++C+ + + Line Sidedef Dir Vertexes + 3 + +++++---+++D+ A 0 0 -> 0 -> 1 + + B 2 2 -> 2 -> 3 + + C 10 10 <- 10 -> 11 + 4 + D 12 12 <- 12 -> 13 + + E 20 20 ^ 18 -> 1 + + F 22 24 v 8 -> 11 +++++ Ok, so you start off in sub sector #2, facing right. Once you enter Sub Sector #0, by crossing linedef #20 (which is nodeline E) you only see what's in front of you if you still are facing right. The 2 imaginary node bounding limits on either side of you are no longer updated, and you just see hyper-junk there. However, if you turn enough so that your gun points straight at a corner where nodeline F crosses nodeline A or C, then it detects sub sector 5 or 3, and will draw those walls again. I can see these symptoms, but I don't know what is causing them. So, what I think I really need is to know how a program would use a BSP tree to detect what walls to draw. Anyone ever write a program to use BSP trees? I can't see how it one would even use such information.. Anyway, enjoy this little node generator. When I get it working properly, I'll will release it too. If anyone else has written a node generator, could I get a copy to examine? As far as I know, only myself, the authors of DEU, and the team at ID have written node generators. Post any comments about this to Alt.games.doom. -Jason Hoffoss DMapEdit author NODE_GEN (March 30, 1994) Edited September 19, 2023 by Redneckerz 2 Quote Share this post Link to post
fraggle Posted September 19, 2023 This is kind of a tangent, but since we're talking about this kind of really early stuff - a while back I went digging through old stuff from textfiles and Usenet myself and collected as many versions of the different Doom FAQs that I could find. The result is here - each of the files has Git history, so you can look at the old versions and even use Blame to see when particular parts were changed. Maybe at some point I'll see if I can find the time to collect some of the source code from these early tools and do the same thing. 10 hours ago, deathz0r said: Jumble 1.02 (announcement post deleted, just like everything else posted by Hank Leukart) It really sucks that all his posts are gone. I even went digging through the dumps on archive.org to see if I could find copies of them, but they aren't there either. Particularly frustrating because obviously it was him that posted the old versions of the FAQ. 4 Quote Share this post Link to post
Redneckerz Posted September 19, 2023 11 minutes ago, fraggle said: This is kind of a tangent, but since we're talking about this kind of really early stuff - a while back I went digging through old stuff from textfiles and Usenet myself and collected as many versions of the different Doom FAQs that I could find. The result is here - each of the files has Git history, so you can look at the old versions and even use Blame to see when particular parts were changed. Maybe at some point I'll see if I can find the time to collect some of the source code from these early tools and do the same thing. By all means, please do. The more data the merrier - I rather prefer a cove of data before we do the minin'. I should stress that (and this is even before this thread even was made) that a ton of stuff is already on /idgames or on 3ddownloads just waiting to get dissected. 1 Quote Share this post Link to post
ETTiNGRiNDER Posted September 20, 2023 @iddq_tea Would you like me to help post this to archive.org like I did with WADS of WADS so it has a safe(r) place to be than Mediafire? 2 Quote Share this post Link to post
iddq_tea Posted September 20, 2023 6 hours ago, ETTiNGRiNDER said: @iddq_tea Would you like me to help post this to archive.org like I did with WADS of WADS so it has a safe(r) place to be than Mediafire? Oh, absolutely! I will add the link to my original post if you do. 1 Quote Share this post Link to post
ETTiNGRiNDER Posted September 20, 2023 1 hour ago, iddq_tea said: Oh, absolutely! I will add the link to my original post if you do. Great! For the purposes of upload metadata, is there any sort of publisher info anywhere on this? It doesn't look like there are any on the insert or disc judging by the photos, but maybe the side label? Some of these discs really are that anonymous though, especially the weird rare ones. 1 Quote Share this post Link to post
iddq_tea Posted September 21, 2023 (edited) 16 hours ago, ETTiNGRiNDER said: Great! For the purposes of upload metadata, is there any sort of publisher info anywhere on this? It doesn't look like there are any on the insert or disc judging by the photos, but maybe the side label? Some of these discs really are that anonymous though, especially the weird rare ones. I will take a look later today, remind me if I forget. More than likely it's anonymous, but it's worth taking a closer look just in case. EDIT: I have no idea where the CD currently is, it has a tendency to get lost before turning up again months (or even years) later. I'm currently quite sick and it's difficult to comprehend things, I can try searching for it more thoroughly some other day. Edited September 21, 2023 by iddq_tea 3 Quote Share this post Link to post
Redneckerz Posted September 23, 2023 (edited) @deathz0r i was wondering: What are the 7 hacks of DEU you found? I know of ADE II and DEU II but i love to see a write up on these. Perhaps the following below you didn't know. Or perhaps you did. In that case the follow is just a write up for later inclusion on the wiki :) EDIT: What was to be only a post on HFDE became a rather large post on various old editors with some lineage to DEU or fairly obscure. I hope this post provides some resource for other historians out there. The Cream of the Crop collection has a lot of these old editors. HFDE: Because, inspired by your hunting, i have been doing some searching too and i found a very peculiar one - HFDE, Hack of A Famous Doom Editor. Joe Wilcox of Simply Silly Software (A rather known entity within Doom) made this hack based off DEU 5.21. GUI improvements were the biggest change, and HFDE was first used internally. It also shows that on November 25, 1994, it could build a Doom 2 PWAD. The legendary Hank Leukart used HFDE/2, a public version for Doom 2, for his level Hank's Lair and there is also HFDE/H, for Heretic. Its text history is thus interesting to include: WHAT'S IS HFDE/2 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ HFDE/2 started with DOOM, when I found that out of all of the DOOM editors available, DEU 5.2 was the best, but the interface was very clumsly. So I created HFDE (a complete hack of DEU with a new GUI) and myself and several close friends used it to build our PWADS. When DOOM 2: Hell on Earth came out, I wait patiently for DEU 5.3 to come. A promised new GUI and full DOOM 2 support were worth the wait. Well, 3 months later, DEU 5.3 is still held up, so I started a quick convert on HFDE. Thus HFDE/2 was born. Well, I passed it around to a few friends on the internet, and everybody loved it. So, I did more work on it, cleaned it up, fixed alot of bugs and decided to give it a real release. But I'm a busy programmer so in order to keep HFDE/2 changing and growing I hope to build it in to a public project (much like nethack). Hopefully, the users of HFDE/2 will join in and help mold it into the best editor around. CURRENT VERSION INFORMATION ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ + HFDE/2 is currently at version 1.00.03! December 12, 1994 þ Fixed bug in insert Linedef that forced it to always try and split a sector þ Rewrote the LoadFTextures code so it would pull in ALL of the floor & ceiling texture names. þ Documentation updated. - version 1.00.02 December 04, 1994 þ First Public release þ Dissapearing Select object bug fixed. þ Sprite viewer fixed þ Item names fixed þ Complete Sector type and linedef type info added (from DOOM 2 specs) - version 1.00.01 November 30, 1994 þ Internal version þ Stairs from Sector code finally working correctly. þ tites, info screens, and text changes made. - version 1.00.00 November 25, 1994 þ HFDE successfully builds a DOOM 2 PWAD. þ All code update to load/edit/save using the new DOOM 2 wad file. þ several small bugs fixed. The download i have is HFDE/2 Version 1.00.03, December 13, 1994. HFDE/2 v1.00.03, December 13, 1994 IDE: Joe Wilcox continued on and also released IDE, short for iD Edit. It also builds upon DEU 5.1 and 5.2 and has hacked in Doom 2 and Heretic support along with a improved GUI. It defaults to using Heretic.WAD. The latest version on /idgames is beta 1.00.725, of July 25, 1995. Sadly there isn't much history included here. IDE v1.00.725 Beta, July 25, 1995 MKD2EDIT: Mark Klem (also known as Mark A Klem) is a rather legendary MIDI musician, who in the early days of 1994-1995, also did some levels. But as it turns out, Mark also created his own level editor, based off DEU 5.21. Known as MKD2EDIT, this hack added Doom 2 support to DEU. Several levels were made using it, but far as i can tell, there was only one release, from October 28, 1994. ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿ ³ °°°°°°° MKD2EDIT v1.0 °°°°°°°° ³ ÀÂÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÂÙ ³ Map editor for DOOM ][. ³ ³ Modified version of DEU 5.21 ³ ³ Access ALL of the new WALL ³ ³ textures, FLOOR/CEILING ³ ³ textures and ALL the new ³ ³ Enemies, MegaSphere, Super ³ ³ Shotgun, Sector types, Line ³ ³ Def types, and Specials. ³ ³ Read MKD2EDIT.DOC for info. ³ ÚÁÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÁ¿ ÀÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÙ 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 MKD2EDIT v1.0 Map Editor by Mark A. Klem for DOOM ][ - Hell on Earth by id Software, Inc. 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 Changes from DEU5.21 in MKD2EDIT v1.0 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 Yes, this is a modified version of the original DEU v5.21. To respect the DEU Authors wishes, this Editor was not named DEU v6.00, I believe they are currently working on version 6 at this time. This version allows you to access all of the new Wall textures, plus, ALL of the new Floor and Ceiling textures as well. All the new Enemies, the Super Shotgun, and the Mega Sphere can be used also. Enjoy making your DOOM ][ WADs. I know I am. --MK-- MKD2EDIT v1.0, October 28, 1994 WAD Master: But Klem didn't stop there, but together with [ice] also released WAD Master 5 months later. It is a fully featured editor, with a texture editor, patch editor, even a COLORMAP editor (in beta) is included. It also includes a level editor, based off DEU with the node builder removed and includes a 3D previewer ala DoomCAD and interactive texture alignment The modifications are detailed in WM.DOC: 9. The Level Editor -------------------- The level editor is actually a revamped version of DEU by Raphael Quinet and Brendon J. Wyber. If you don't know how to use DEU, you will need to obtain a copy of the documentation from your local BBS or an ftp site. Following is a list of changes/additions to the original DEU code: - The nodes builder has been completely removed. You will have to use an external nodes builder to rebuild the nodes in your level before Doom can use them. I highly recommend getting a copy of BSP by Colin Reed. BSP is the best nodes builder I have seen. - Cheesy 3D preview mode. I don't have this complete yet, but it will give you the general idea. Top-of-the-line Cheese! - Interactive Texture Alignment(ITA). Select 2 joined linedefs and align the textures. This one's not fully complete yet either, but usually works fine. - Changed the 'Select Texture' box. Size of patch is displayed as well as the number of patches in the texture. Moved some of the text around so more of the texture can be seen in 320x200. - When you select a sprite, the sprite is displayed in a window just as the textures are. I did this because of the next change I made... - Textures & sprites from loaded PWADs are now shown. Before, DEU would crash if you had any kind of graphic replacements in any loaded wads. - Texture & sprite drawing routines totally re-written. The new routines are faster, smaller, and use less memory. And they're faster. - 90% of the graphics routines had to be re-written for Watcom. - Added a check for 'medusa' textures. A 2-sided linedef with a normal texture with more than one patch is a no-no. Now, you don't have to worry about that. This check is performed when you select Check | Check Textures. - Only 2 graphic modes are supported now: 640x480x16 (with 320x200x256 fallback), and 640x480x256. - All input boxes for height, light level, etc... have a +8, -8 step by pressing the up or down arrows. Helps when making stairs, etc... - Lotsa descriptions changed, stuff moved around, better organization... - And of course, all of the new Doom 2 things, linedef types, and sector types have been added. It is very complete. It does include a batch file, B.BAT, that tells you how to build the BSP nodes (It assumes BSP.EXE) will be used: REM This is an example BATCH file of how you may want to REM run your nodes builder after editing a level. REM @echo off cd\doom2 bsp map02.wad copy tmp.wad map02.wad doom2 -warp 2 -file map02.wad < NUL WAD Master version 1.01b, March 9, 1995 WADMSTR: The same name as the editor above, it is made by two completely different people. In fact, it is an early program (March 2, 1994) whose editor (DEDIT.EXE) could only save THINGS, but did allow viewing of the NODES. So this gives a timeframe of when the NODES lump atleast could be viewed. It was made by Richard Hawkins and John Milton as WDMSTRx. What i have is version 0.5, as WDMSTR05.zip. Again found on the Sprint OS disc. It includes: Spoiler WADMASTR series Version 1.00 This set of tools/utils is the first in a line of WAD packing/editing tools which are capable of taking a doom WAD file and splitting it into many named pieces. This release also includes the means to take these pieces and reassemble them into a doom.wad file again. With this doom editing method, the number of anything is not fixed (including patterns, etc.) Furthermore, to change any item in DOOM, it's file simply needs to be altered/added/deleted. Thus, if you have a new set of sounds you want to use to replace the old ones, simply replace the relevant files in the unpacked wad directory and re-pack verything. The sizes of the new files are completely IRRELEVANT. For this release, there are only the most basic of utilies. They are: WADDIR {WADFILE} Extracts all filenames from a .wad file and writes a series of lines to standard out. (It also adds some comment-like lines starting with #.) The fields are: DOSNAME WADNAME SIZE DOSNAME is used in conjunction with UPWAD and PWAD to determine the path to put/take a file in the dos tree. WADNAME is the .wad filename used inside the .wad file. SIZE is totally unused by any of the other utilities and is only introduced for the sake of the user. Any DOSNAME with a trailing \ denotes a directory to be created (and using an editor, the filenames of subordinate files can be placed in such a directory). Any WADNAME with a trailing \ indicates that the name is a TAG (not a directory, but not a file either - more a marker so DOOM can find a subsection quickly or seperate levels). (See DOOMDIR) If WADFILE is omitted, doom.wad is assumed. UPKWAD {-v} {-q} {-o directory} {-s} WADDIR {WADFILE} Extracts the files specified by the contents of WADDIR, which is in the format output by the WADDIR command. Only the files specified are extracted, but they must be in the same order as the directory of the .wad file involved. If WADFILE is omitted, doom.wad is assumed. If -v is specified, the command becomes verbose. If -q is specified, the command becomes quiet (not displaying error messages, but statistics are still displayed at the end). If -s is specified, the command does not display statistics at the end. PKWAD {-p} {-v} {-q} {-o directory} {-s} WADDIR {WADFILE} De-extracts the files specified by the contents of WADDIR, which is in the format output by the WADDIR command. Only the files specified are integrated. If WADFILE is omitted, doom.wad is assumed. If -v is specified, the command becomes verbose. If -q is specified, the command becomes quiet (not displaying error messages, but statistics are still displayed at the end). If -s is specified, the command does not display statistics at the end. -p creates a PWAD (patch) file using the directory structure provided. DEDIT This is the editor for this system. It should be executed at the base of the tree where the UPKWAD was performed (but it is not necessary to do so there). DEDIT is a mouse-driven (only) editing mechanism which can display all things, lines, vertices, nodes, and corresponding ssectors and segs. Currently only THINGS can be saved, however, the number of things may vary between loading and saving. Object selection is performed by clicking the left mouse button over a particular thing or vertex. Dragging will move that item. Double-clicking over a thing will produce a thing editing menu. Pressing the right mouse button produces a main menu to the menu system. The menu items are reasonably self-explanatory. The following keystrokes are recognized: 1,3,4,7: Toggle the display of things, lines, vertices, and nodes respectively. ALT-1, ALT-2, ALT-MINUS: Descend left, right, and ascend the node BSP tree respectively. F1: Load a level F2: Save the things in a level KEYPAD PLUS: Zoom in KEYPAD MINUS: Zoom Out ALT-P: Pan the map ALT-C: Toggle coordinates INSERT: Insert a thing HOME: Center on mouse Special files: DOOMDIR: This is a WADDIR output of the standard doom.wad which has been modified so that a standard directory structure can be given to UPWAD and PWAD. It is suggested that it be used for the purposes of standardization. It is also suggested that packages of doom things use variations of this DOOMDIR as a standard means of packaging so that replacements can be made easily. WADMSTR 0.5, March 2, 1994 (USENET post announcement) Laura Beyer's Level Editor (LDLC): Some of you may remember Laura Beyer's Doom - A infamous PWAD that was sold as a commercial addon with debateable quality maps. But there was also a level editor. It uses BSP 1.2x (BSP12x) as a nodes builder. It was distributed as LBCREATE.ZIP and it is on the Sprint OS disc. It also includes a map, SHADOWS.WAD, from November 25, 1994 as a demonstration map. It was a payware program: What is on the disc is the demo version. One was ought to order the registered version. The demo version disables saving. Below is the layout of SHADOWS.WAD, exported from SLADE (Open in separate window to see the background, it turns black in forum): Laura Beyer's Level Editor (LDLC), demo version for Windows, November 19, 1994 SuperWADED: SuperWADED was to be a enhanced WADED clone by Matthew Ayres who was 18 years old at the time. There has only be one release available, 1.967 Alpha of June 26, 1995. Its only a THINGS editor at this point. The history suggests there was an earlier version on a book by Sam's Publishing: --------------- A good portion of WADED was rewritten to make SuperWADED. There's still a lot of work to do, but it's MUCH easier to work with now. -=[ v1.83 beta ]=- Oh boy, here's where we left off... pretty stable version, but it had its flaws if you weren't familiar with it. -=[ v1.87 beta ]=- Special registered versions for Sams Publishing. You shouldn't have this unless you bought the book. It's the same as v1.83 (I think... hmm, well there might be one tiny little fix. I'm not gonna say what it is, nahnah... ok so I can't remember what it was anyhow.) -=[ v1.9xx alpha ]=- Code revamped. Worked on it on and off a lot over the past few months. Recently working on it a lot. -=[ v1.967 alpha ]=- Released alpha version with only THINGS mode working. Ayres did promise a lot features, however: More alpha's with more modes and features enabled. Probably in this order: Load, Save, LINES, SECTORS, DRAW MAP VERTICES, DRAW MAP LINE(S), DRAW ROOM, Help, Check, Make Sector, Sector Define, Move VERTICES/LINES/SECTORS. Also soon to come: Cut & Paste, allow many maps opened at once, other nifty things, and 3D preview... But obviously, it never came to be. SuperWADED v1.967 Alpha, June 26, 1995 viDOOM: Unlike most of the above, this is actually a late DOS release, starting at August 5, 2000. Made by Ian Cowburn, viDOOM carries a GPLv2 license. This is a from-scratch level editor that can edit all Doom games, but can also support BOOM and ZDOOM extensions. These aren't included here, but viDOOM was mean't to be configurable from scratch. It doesn't have a node builder, but it suggests to use BSP. It has some extensive help files. It seems this editor never got any popularity. As for the reason why viDOOM was made: Quote Why bother? Good question. Anyone who has ever used them will know there are a number of very good DOOM editors available (links to lots of them can be found at Doomworld and all good FTP servers). However, I always felt a bit clumsy using them, and in true hacker fashion I decided writing one I could use would be easier then reading the instructions for the others. Hence viDOOM. I reasonably like the way viDOOM works, so I release it on the off chance other people may too. viDOOM 0.02, August 13, 2000 The Doom Editor (DEDIT): The last one is a doozy, it is a Doom Save Editor. It has a file date of December 12, 1993. Doom Save Game editors were the earliest form of modification (see also DSGEDIT). It was made by The Harrison Hackers: This file contains the DOOM editor which will give you a variety of neat stuff (maps, light visors, keys, health, weapons (yes!!!!!), ammo, god mode (more later), rad suits, invisibility, etc. ). Notes: 1. DOOMEDIT.EXE _must_ be in the \doomdata directory. 2. The PLASMA CANNON and BFG9000 are NOT available in the shareware version. 3. God Mode is activated by selecting FULL INVISIBILITY. God mode is not equiv. to unlim ammo... but it makes killing by chainsaw just that much safer! 4. Play around with it, it's fun... it's exciting.. it's the DOOM EDITOR!!!! (version 2) (v1 sucked) 5. Happy slaughtering!!! Hugs and kisses, The Harrison Hackers: kaseeley@sage.cc.purdue.edu fisheric@mentor.cc.purdue.edu burdicdj@mentor.cc.purdue.edu blabus@sage.cc.purdue.edu The Doom Editor, version 2.0 (December 12, 1993) Edited September 23, 2023 by Redneckerz 5 Quote Share this post Link to post
thestarrover Posted September 23, 2023 1 hour ago, Redneckerz said: Doom Save Game editors were the earliest form of modification There is also this Aesopian Doom Editor 1.01 by Jason Dunn released on December 22, 1993 for Doom 0.99. (Supergames volume 4 but also in volume 2) 3 Quote Share this post Link to post
Redneckerz Posted September 24, 2023 (edited) @deathz0r and @Never_Again and @thestarrover Speaking of David Simpson's illustrious first WAD: Obviously the idea of an original WAD way before ORIGWAD and without being an ID-edited level is very interesting to me, so i set out to find some more evidence to David's original comment that he made the first WAD. I found the original post where he claims he created the first original WAD. It is interesting to see how Simpson was figuring things out as they go. Still no level, but there is a possible creation date: January 27, 1994. (Usenet post) David asked in a Usenet post from January 13, 1994 for info on how the NODES structure worked: A possible and quite feasible solution to finding difference between the two .WAD files (shareware and not) is to look at the indices at the end of the .WAD files. These index certain things within the file (graphics, sound, maps, etc.) and many of the items in the full version do not exist in the shareware version. A good example is the BFG9000, which has a name like BFUG9 something or other. Well it's there anyway. Someone also brought up a question on how to distribute altered and new maps to Doom. The best method I have come up with is to distribute (either seperately or with a map editor) a small program that just simply inserts a new map into .WAD file. This can simply be done by placing the new map into its spot in the .WAD file and then by changing all of the pointer references at the end of the .WAD file that reference the map and probably all of the pointers after them (it is highly unlikely that new maps will be exactly the same size as the one it will replace). This small program should also give the ability to replace the distributed livel with any of the levels in Doom. It may be also possible to not have to overwrite the old level being replaced. Since the pointers just point to a place in the file, just place the new level after the exiting level and change the pointers. To go back to the old level, just change the pointers back and voila! it's back. Now, if anybody knows exactly how the NODES section of the map is set up and what each integer does, please send me mail. The only thing I know so far about it is that integers 0, 6, 7, 10, and 11 are X coordinates, integers 1, 4, 5, 8, and 9 and Y coordiantes, integers 12 and 13 are some sort of index number and that each entry is 28 bytes long. Another Usenet post from January 19, 1994 shows Simpson making improvements and having figured most things out on the structure of a WAD, yet still struggling with understanding the NODES structure: If there is anyone out there that knows what the NODES section in the map definitions is used for and how it is setup, I would really like to hear about it. I've got most everything else figured out, but the NODES are confusing the hell out of me. What I do know about them is that each entry is 28 bytes (14 ints) set up like this: X Y ? ? Y Y X X Y Y X X Index Index, where the X's and Y's are coordinates on the map, the Indices are some sort of refernce number (to SSECs, I believe) abd I have no clue what the ?s are (but haven't looked at those too much yet). I really can't tell if specific points are made by combos of the X and Y coordinates or if they diffine lines or what. Perhaps more importantly, what are the NODES function? The January 27, 1994 Usenet post actually talks about REJECT (and doesn't mention the term nodes, so it was easily missed to time) and not understanding what this seems to do, but it does mention the following: However, I think I've figured out just about everything else, although I don't have comprehensive lists of such things as LINEDEFS functions and items. I have in fact created my own level (by hand in a hex editor). It was just a single room which had two distinct levels and a couple of objects. I never did get the exit switch to work right, but I did make a wall into an exit that would work by running into it. So around this time, Simpson understood the NODES and proceeded to craft his very own level. It isn't sure what Simpson mean's with two distinct levels, but most likely it isn't about an upper floor and a lower floor, rather one room with two seperate subrooms. Atleast that's my impression of it. So i reckon inbetween January 13 and January 27, 1994, Simpson figured out how NODES worked and crafted his own level in a hex editor, predating ORIGWAD by more than a month (January 13-27 to March 7). It is baffling to me however that Simpson didn't think his achievement was worth sharing to the world, yet mentioned having made that level in a March 11, 1994 Usenet post on ORIGWAD, because for all we know now, Simpson may have beat ORIGWAD by a significant margin. The only way we could confirm this is ask Simpson himself provided he is still alive (And same goes for Alistair Brown). All in all this is interesting enough to put on the wiki. Edited September 24, 2023 by Redneckerz 7 Quote Share this post Link to post
fraggle Posted September 24, 2023 I now have a history repository built from the releases of BSP that I've been able to locate. You can get some nice blames of the source files (example) that show how the code changed over time. Thanks to everyone in this thread for locating some of the old versions. Obviously it's an incomplete history; if you have copies of versions that are not in that list please let me know. It's particularly frustrating that I've been unable to find the earlier v2.x releases (bsp20x, bsp21x, bsp22x). The repository is autogenerated so expect the history to be entirely rewritten as I incorporate new things. In particular I've just noticed that the source dating back to v2.3 appears to have been tracked in CVS so I'll be able to get more fine-grained history. I'm in the process of doing the same thing for DEU and its forks. If you have obscure versions of that, let me know. 7 Quote Share this post Link to post
thestarrover Posted September 25, 2023 (edited) 16 hours ago, fraggle said: It's particularly frustrating that I've been unable to find the earlier v2.x releases (bsp20x, bsp21x, bsp22x). I have the following files: BSP20X.RAR. BSP21X.RAR, BSP22X.RAR, BSP23X.RAR (versions 2.0, 2.1, 2.2, 2.3) Are these the files you are looking for? BSP20.TXT This is BSP version 2.0 dos extended, written by Colin Reed: creed@graymatter.on.ca. Please send all comments and/or questions about BSP to Lee Killough (killough@rsn.hp.com), since Colin Reed is too busy now. ----------------------------------------------------------- New to 2.0x: Multilevel support!!! Automatically builds all levels in wad. Does not strip textures or other lumps from wads anymore!!! Supports HOM-free transparent doors: Simply make the sector referenced by the doortracks have a sector tag of >= 900. No need to remember sector numbers and type them in on a command line -- just use any sector tag >= 900 to permanently mark the sector special. See TRANSDOR.WAD for an example of sector tags in the 900's being used to create HOM-free transparent door effects. ----------------------------------------------------------- Changes from 1.4x to 1.5x: Replaced GO32.EXE with newer version, to support Windows and DPMI. ----------------------------------------------------------- Changes from 1.3x to 1.4x: Lee Killough: Fixed bug which caused BSP to "do nothing" on systems where GO32.EXE was not in the user's path. Added -factor option to allow changing the heuristic used by the node picker. Factor can be any positive integer, and the larger the factor, the more costly seg splits are. A factor of 17 is the default and behaves just like earlier versions of BSP. Changing the factor can sometimes prevent visplane overflows in wads. But then again, some wads have just too many visible 2s linedefs for the node builder to make a difference. If you have visplane overflows, experiment with the -factor option before giving up. ----------------------------------------------------------- Changes from 1.2x to 1.3x: New version due to performance enhancements by Lee Killough (killough@rsn.hp.com). Runs at least 3 times as fast as before, due to changes in PickNode. Same results are obtained, but with greater speed. Differences from 1.2x: PickNode() rewritten to maximize performance. New PickNode() algorithm features pruning strategy which allows inner loop to exit as soon as a seg is detected as being worse than the best so far. All floating-point arithmetic inside inner loop has been eliminated. GetVertexes() changed and Reference() removed, replaced with a faster vertex renumbering algorithm which also removes lines of length zero. IsLineDefInside() tuned by eliminating bit mask variable. Functions are static, to reduce code size by permitting total inlining. Various other minor performance enhancements ----------------------------------------------------------- Changes from 1.1 to 1.2x: New version 1.2 due to bug found by Mark Harrison that caused some problems with flipped segs having their textures buggered up. The GO32 dos extender has been pre-pended to the executable. ----------------------------------------------------------- This builds a BSP node tree for your DOOM wad files. Usage: BSP [-factor nnn] <input file> [<output file>] If no output file is specified 'tmp.wad' is written. ----------------------------------------------------------- This ZIP includes the fullly commented source code for all you Doom editor/utility writers out there. ----------------------------------------------------------- A known problem is a conflict between the GO32 dos extender and QEMM's DPMI... put 'set GO32=nodpmi' in your autoexec.bat to avoid problems. ----------------------------------------------------------- Future enhancements (possibly, depending on demand): * Ability to specify level(s) to build separately * Reject map build * Automatic visplane overflow protection (no, really!) BSP21X.TXT This is BSP version 2.1 dos extended, written by Colin Reed: creed@graymatter.on.ca. Please send all comments and/or questions about BSP to Lee Killough (killough@rsn.hp.com), since Colin Reed is too busy now. ----------------------------------------------------------- Changes in 2.1x: Lee Killough 06/03/97 Fixed design bug which caused invisible barriers or disappearing Things. Problem was in how segs parallel to a partitioning node line were partitioned -- they were partitioned according to sidedef, rather than vertex, orientation w.r.t. the node line. Flipping the affected seg's linedef usually fixed the problem. Now a parallel seg is properly partitioned either on the left or right side of a node line depending on whether the two segs are in the same direction or not, not whether they are both flipped or not. Credit should go to Jan Van der Veken <h5019065@khk.be>, for providing me with a demo wad which clearly illustrated the disappearing Things bug. Added special effects features: If a linedef has a sector tag >= 900, then it is treated as "precious" and will not be split unless absolutely necessary. This is good to use around borders of deep water, invisible stairs, etc. Furthermore, just for grins, if the linedef's tag is 999, then the sidedefs' x-offsets set an angle adjustment in degrees to be applied -- you can look straight at a wall, but it might come right at you on both sides and "stretch". ----------------------------------------------------------- New to 2.0x: Multilevel support!!! Automatically builds all levels in wad. Does not strip textures or other lumps from wads anymore!!! Supports HOM-free transparent doors: Simply make the sector referenced by the doortracks have a sector tag of >= 900. No need to remember sector numbers and type them in on a command line -- just use any sector tag >= 900 to permanently mark the sector special. See TRANSDOR.WAD for an example of sector tags in the 900's being used to create HOM-free transparent door effects. ----------------------------------------------------------- Changes from 1.4x to 1.5x: Replaced GO32.EXE with newer version, to support Windows and DPMI. ----------------------------------------------------------- Changes from 1.3x to 1.4x: Lee Killough: Fixed bug which caused BSP to "do nothing" on systems where GO32.EXE was not in the user's path. Added -factor option to allow changing the heuristic used by the node picker. Factor can be any positive integer, and the larger the factor, the more costly seg splits are. A factor of 17 is the default and behaves just like earlier versions of BSP. Changing the factor can sometimes prevent visplane overflows in wads. But then again, some wads have just too many visible 2s linedefs for the node builder to make a difference. If you have visplane overflows, experiment with the -factor option before giving up. ----------------------------------------------------------- Changes from 1.2x to 1.3x: New version due to performance enhancements by Lee Killough (killough@rsn.hp.com). Runs at least 3 times as fast as before, due to changes in PickNode. Same results are obtained, but with greater speed. Differences from 1.2x: PickNode() rewritten to maximize performance. New PickNode() algorithm features pruning strategy which allows inner loop to exit as soon as a seg is detected as being worse than the best so far. All floating-point arithmetic inside inner loop has been eliminated. GetVertexes() changed and Reference() removed, replaced with a faster vertex renumbering algorithm which also removes lines of length zero. IsLineDefInside() tuned by eliminating bit mask variable. Functions are static, to reduce code size by permitting total inlining. Various other minor performance enhancements ----------------------------------------------------------- Changes from 1.1 to 1.2x: New version 1.2 due to bug found by Mark Harrison that caused some problems with flipped segs having their textures buggered up. The GO32 dos extender has been pre-pended to the executable. ----------------------------------------------------------- This builds a BSP node tree for your DOOM wad files. Usage: BSP [-factor nnn] <input file> [<output file>] If no output file is specified 'tmp.wad' is written. ----------------------------------------------------------- This ZIP includes the fullly commented source code for all you Doom editor/utility writers out there. ----------------------------------------------------------- A known problem is a conflict between the GO32 dos extender and QEMM's DPMI... put 'set GO32=nodpmi' in your autoexec.bat to avoid problems. ----------------------------------------------------------- Future enhancements (possibly, depending on demand): * Ability to specify level(s) to build separately * Reject map build * Automatic visplane overflow protection (no, really!) BSP22X.TXT This is BSP version 2.2 dos extended, written by Colin Reed, Lee Killough Please send all comments and/or questions about BSP to Lee Killough (killough@rsn.hp.com). ----------------------------------------------------------- Changes in 2.2x: Lee Killough 10/97: Added -vp option to reduce the chances of visplane overflows, without loss of detail. Using -vp causes node line picker to choose node lines in a way that is empirically known to reduce or eliminate visplane overflows (see visplane.txt). No guarantees, though!!! Added -vpwarn option to warn about possible visplane overflows (see visplane.txt). -vpmark option also added, which leaves permanent marks in the form of player 1 starts. It's a good idea to write to a separate output file when using this option!!! You can then use an editor, play each alternate player start, and see if each one causes visplane overflows, and then remove it. Usually no- clipping must be used, at least to step out from the wall, since it inserts player starts without regard to collisions, and it uses walls as a basis for visplane calculations. Added -noreject option, to allow building nodes without messing up an already-built reject map. Added -thold option to change the visplane threshold. May be used to report more potential visplane overflows if the -vpwarn or -vpmark approximations estimate too few visplanes. Default threshold is 128. Changed the way level markers in the lump directory are handled, to accomodate DCK3.61, EdMap, and perhaps other editors. Some editors, such as DCK3.61, do not always set the length field in a level marker to 0, and EdMap requires that the offset field in a level marker be equal to the offset of the first resource. ----------------------------------------------------------- Changes in 2.1x: Lee Killough 06/97 Fixed design bug which caused invisible barriers or disappearing Things. Problem was in how segs incident to a partitioning node line were partitioned -- they were partitioned according to sidedef, rather than vertex, orientation w.r.t. the node line. Flipping the affected seg's linedef usually fixed the problem. Now an incident seg is properly partitioned either on the left or right side of a node line depending on whether the two segs are in the same direction or not, not whether they are both flipped or not. Added special effects features: If a linedef has a sector tag >= 900, then it is treated as "precious" and will not be split unless absolutely necessary. This is good to use around borders of deep water, invisible stairs, etc. Furthermore, just for grins, if the linedef's tag is 999, then the sidedefs' x-offsets set an angle adjustment in degrees to be applied -- you can look straight at a wall, but it might come right at you on both sides and "stretch". ----------------------------------------------------------- New to 2.0x: Multilevel support!!! Automatically builds all levels in wad. Does not strip textures or other lumps from wads anymore!!! Supports HOM-free transparent doors: Simply make the sector referenced by the doortracks have a sector tag of >= 900. No need to remember sector numbers and type them in on a command line -- just use any sector tag >= 900 to permanently mark the sector special. See TRANSDOR.WAD for an example of sector tags in the 900's being used to create HOM-free transparent door effects. ----------------------------------------------------------- Changes from 1.4x to 1.5x: Replaced GO32.EXE with newer version, to support Windows and DPMI. ----------------------------------------------------------- Changes from 1.3x to 1.4x: Lee Killough: Fixed bug which caused BSP to "do nothing" on systems where GO32.EXE was not in the user's path. Added -factor option to allow changing the heuristic used by the node picker. Factor can be any positive integer, and the larger the factor, the more costly seg splits are. A factor of 17 is the default and behaves just like earlier versions of BSP. Changing the factor can sometimes prevent visplane overflows in wads. But then again, some wads have just too many visible 2s linedefs for the node builder to make a difference. If you have visplane overflows, experiment with the -factor option before giving up. ----------------------------------------------------------- Changes from 1.2x to 1.3x: New version due to performance enhancements by Lee Killough (killough@rsn.hp.com). Runs at least 3 times as fast as before, due to changes in PickNode. Same results are obtained, but with greater speed. Differences from 1.2x: PickNode() rewritten to maximize performance. New PickNode() algorithm features pruning strategy which allows inner loop to exit as soon as a seg is detected as being worse than the best so far. All floating-point arithmetic inside inner loop has been eliminated. GetVertexes() changed and Reference() removed, replaced with a faster vertex renumbering algorithm which also removes lines of length zero. IsLineDefInside() tuned by eliminating bit mask variable. Functions are static, to reduce code size by permitting total inlining. Various other minor performance enhancements ----------------------------------------------------------- Changes from 1.1 to 1.2x: New version 1.2 due to bug found by Mark Harrison that caused some problems with flipped segs having their textures buggered up. The GO32 dos extender has been pre-pended to the executable. ----------------------------------------------------------- This builds a BSP node tree for your DOOM wad files. Usage: BSP [-factor nnn] <input file> [<output file>] If no output file is specified 'tmp.wad' is written. ----------------------------------------------------------- This ZIP includes the fullly commented source code for all you Doom editor/utility writers out there. ----------------------------------------------------------- A known problem is a conflict between the GO32 dos extender and QEMM's DPMI... put 'set GO32=nodpmi' in your autoexec.bat to avoid problems. ----------------------------------------------------------- Future enhancements (possibly, depending on demand): * Ability to specify level(s) to build separately * Reject map build If they are the right files I can upload them here. Let me Know :) Edited September 25, 2023 by thestarrover BSP text files added 0 Quote Share this post Link to post
fraggle Posted September 25, 2023 6 hours ago, thestarrover said: If they are the right files I can upload them here. Let me Know :) Those are exactly what I'm looking for! Can you please share? And out of curiosity where did you get them from? 0 Quote Share this post Link to post
thestarrover Posted September 25, 2023 33 minutes ago, fraggle said: Those are exactly what I'm looking for! Can you please share? And out of curiosity where did you get them from? BSP20X.RAR BSP21X.RAR BSP22X.RAR Downloaded from http://www.owlserver.de:2080/ftp/pub/echo/games/g_idsoft.add.dm2/ sometime ago. The site seems to be offline, or very slow to load. I downloaded the full site. There are files ( wads and utilities) for Doom, Doom 2, Heretic, Hexen. 3 Quote Share this post Link to post
ETTiNGRiNDER Posted September 25, 2023 23 minutes ago, thestarrover said: Downloaded from http://www.owlserver.de:2080/ftp/pub/echo/games/g_idsoft.add.dm2/ sometime ago. The site seems to be offline, or very slow to load. I downloaded the full site. There are files ( wads and utilities) for Doom, Doom 2, Heretic, Hexen. Did you happen to notice if any of the Heretic/Hexen stuff looked like it was files not commonly available on places like idgames/wad station/etc? 1 Quote Share this post Link to post
fraggle Posted September 25, 2023 1 hour ago, thestarrover said: BSP20X.RAR BSP21X.RAR BSP22X.RAR Thank you!! Now incorporated into the history. The site you linked looks very interesting but I wasn't able to download any files from it - I get a 403 access denied error. The DEU history is also now available, though it's a work in progress. 4 Quote Share this post Link to post
thestarrover Posted September 26, 2023 @fraggle @ETTiNGRiNDER When I can I will upload the doom, heretic and hexen files so you can take a look at them. 2 Quote Share this post Link to post
Lollie Posted September 26, 2023 This thread gets so much deeper into the weeds of Doom wad-making history than I ever could have expected, awesome to read. @iddq_tea Is there any chance you could share the entire ISO of this disc? I tried running Menu.exe via Dosbox-X, but it seems to be pretty useless and crash-prone on its own. 1 Quote Share this post Link to post
iddq_tea Posted September 26, 2023 3 hours ago, Lollie said: This thread gets so much deeper into the weeds of Doom wad-making history than I ever could have expected, awesome to read. @iddq_tea Is there any chance you could share the entire ISO of this disc? I tried running Menu.exe via Dosbox-X, but it seems to be pretty useless and crash-prone on its own. I no longer possess a CD drive (those files were copied in 2017, I still had my old laptop) so it take some time for me to create an ISO. I don't remember if I ever tried launching a wad through MENU.EXE, I probably only checked that it boots up at all (not getting any crashes though, what did you do to trigger it?) But I see what the problem is, I think it expects a specific directory structure, and I don't remember the exact CD structure anymore since I unzipped all the files and separated them 6 years ago. When I find the CD and get my hands on a portable disc drive, I'll make a new rip and write down the steps needed to use the MENU executable. 3 Quote Share this post Link to post
thestarrover Posted September 26, 2023 On 9/25/2023 at 1:51 AM, fraggle said: I'm in the process of doing the same thing for DEU and its forks. If you have obscure versions of that, let me know. Right now I don't remember if it has been already mentioned, but Joe Wilcox (Simply Silly Software) released in May 1994 ( according to the date of DEUH.EXE) an hacked version of Deu 5.1 called DEUH 1.0 ( Beta version) DEUH.DOC ================================= This is a beta release Please use it at your own risk ================================= Welcome to DEUH 1.0· (also known as DEU 5.1 hack version 1.0). This new 'Hack' of DEU has many improvements over it's original. See the file WHYAHACK for a story on why I hacked this. I would like to give credit to the following people for their work on DEU 5.1, and BSP. Raphael Quinet & Brendon J. Wyber for DEU 5.1 Colin Reed for BSP. If you haven't guessed, this hack contains code from both of the above. In fact one of the major features is that DEUH contains the node builder in BSP. Translation: Perfect PWADS. Before I go in to quickly explaining the new features in a bit a detail (like how to use them), let me say this. DEUH can ONLY (I repeat ONLY) use the BGI driver SVGA256.BGI! Also, I know of a bug in the video init. code. Please only use the following values for VIDEO in DEUH.INI.... 02 - 640x480x256c 03 - 800x600x256c 04 - 1024x768x256c Also, this is a beta. It's constantly changing, and being redesigned. I know of several bugs. I will include a full list at the end of this file. I will also release the source with the final release, but if you want it sooner, just email me. Ok, on to the show. NEW FEATURE #1: Improved interface.... I have greatly improved the interface used by DEU. A quick list of improvements are... ˛ Mouse in SVGA modes ˛ Easier to read displays ˛ Better ZOOM and Grid handling ˛ Better mouse support in general. Mouse is SVGA! That's right. I have added a full featured software mouse cursor. Now you can see what your doing without that ANNOYING fake cursor. In fact, don't use the FAKE CURSOR...It's not supported, and I have not removed it yet. Also, the ruler is no longer supported. The LINEDEF display's now show length of the linedef. I have updated all of the displays, and improved either they look (in my opinion) or the amount of information they give. For example, the LINEDEF display tells you the length. The Sectors display show what linedefs effect the sector (and what effect they have on it). The things can now show the actual sprite for the object as well as a easy to read compass rose for direction (this is changing in the next release...) I have improved the ZOOM and Grid handling abilities in DEU. The grid can now be hidden while objects still snap to it. You can quickly switch between ZOOM factors, and even the grid color can be customized. A BIG change, is the grid is hidden while the map scrolls. This GREATLY increases scroll speeds. Let's talk about the new mouse/keyboard support. Here is the new mouse button layout... Left Mouse Button - Like DEU... Mark and UnMark an object Shift+Left Mouse Button - Like DEU... Drag a selection box Alt+Left Mouse Button - Deletes currently selected object. Right Mouse Button - Like DEU drags an object. Shift+Right Mouse Button - Edits the selected object (will be changed to CTRL in next version). Notice when you press and hold the ALT key, the cursor changes color to RED. This is to show the change. When you are editting Vertexes, you can press BACKSPACE to switch from Mark/Unmark mode to AutoLink mode. In AutoLink, when ever you select 2 vertexes, DEUH will automaticly create a linedef between them. When you are editting Things, you can press BACKSPACE to switch to Stamp mode. When in stamp mode, pressing the mouse button will create a new instance of the last things you had selected. Press BACKSPACE to switch back (same for Autolink mode). Notice the little info box at the bottom right hand corner of the screen. It tells you your current location in the map, as well as button modes, etc. When editting LINEDEF's, you have 2 new keys. You can press "F" to flip the linedef (same as Flip LineDef in F8). If you hold SHIFT while pressing "F", will swap the sidedefs, but keep the vertexes where they belong. You can also press "." to split the linedef and add a vertex. Anytime you create a LINEDEF, DEUH will test to see if it splits a sector. If it does, DEUH handles this automaticly. But there is a bug. DEU's (and DEUH's) SplitSector routine fail is there are any sectors inside that are split. I'm working on this... Some other neat keyboard commands are... ALT-1 through ALT-0 and SHIFT-ALT-1 through SHIFT-ALT-0 will quickly change the ZOOM factor to 1:1 through 1:10 and 1:11 through 1:20. It also centeres around where the mouse is pointer to. ALT-G hides the grid, but keeps all objects snaping to it. ALT-[-] (read: Alt minus) and ALT-[+] will scroll through the grid color. I will added a command to the INI to allow you to set it from the start. Oh.. you can also now view all the sprites from inside the editor. When in Things mode, press ALT-I (misc menu) and select view sprites. More changes are coming to the interface (an no, the Make Stairs from Sector option is now finished; It's partly there, but not done yet.) so if you have a suggestion, please email me. NEW FEATURE #2: BSP 1.1x built in. That right, I threw the node builder in DEU 5.1 out (it did not work) and have merged BSP 1.1x in. Let me tell you, it was not easy, and still has a few bug. They are... ˛ You can't press ESC to abort like you are told. ˛ If you opt to to rebuild, then DEUH does not save the data correctly. THIS ONLY OCCURES if you get the "You must rebuild" message. You can still change textures, etc and not have to rebuild. ˛ After building a PWAD, you have to exit. It's not freeing out all of the memory it is using. ˛ It's limited to building PWADS no larger than 160k. I could build my larget PWAD, but still can't build Episode 2 Mission 7. Working on it through. ˛ The fill bar at the bottom of the window does not represent amount of time left (or % done). It can flip over any number of time. All it says is "Look at me.. I'm working". But, the good news is, DEUH creates perfect PWADS. Although it's not as fast as BSP (BSP is uses a DOS-Extender and works much faster) it does work. NEW FEATURE #3: Revision Tracking... DEUH will now keep multiple backup copies of your pwad. Anyone know has ever tried to create a pwad should love this feature. Currently, you have to restore them by hand but in the next build, DEUH will have the REVERT command added. These files use the name .. filename.Rxx, where filename is the name of your pwad, and xx is the revision number. You must turn on 2 settings in DEUH.INI: "revisions=TRUE" turns revision tracking on (DO NOT TURN IT OFF IN THIS BETA.. BIG TIME BUG that trashes the WAD) "maxrevisions=xx" tells DEUH the max. # of Rxx file it can create before it should loop around. The revision tracker uses the .Rxx file's time&date stamp to keep track of which is the newest. NEW FEATURE #4: Better memory SWAP support. DEUH will swap more things out to disk, thus allowing you to work on larger maps. EMS support is being designed. COMING SOON: ------------ Here is what I will be working on over the next week or two (besides trying to correct any bugs). ˛ Finished the Create Stairs from Sectors, and added the Create Hidden stairs from Sectors. ˛ Allow DEUH to save sectors out to a file, thus creating pre-defined rooms, etc. ˛ Allow DEUH to build E2M7, and imporve the swap routines (even add EMS). ˛ Several little interface changes. ˛ Finished Revision Tracking support ˛ Add the ALT-T hotkey that will shell DOOM so you can test the wad. ˛ Who kowns... any suggestions. HOW TO MAKE A COMMENT, REPORT A BUG, ETC. ----------------------------------------- DO NOT CALL ME, or SIMPLY SILLY SOFTWARE. I will not support DEUH over the phone (I have enough trouble supporting DM). If you have a comment, bug, or suggestion, then please E-MAIL me at joewilcox@aol.com HOW TO GET THE SOURCE CODE -------------------------- It's free, just email and ask. I will release the code with the actual release of DEUH. Until then, you need to ask for it. ============================================================================= T H I S I S A B E T A - R E M E M B E R T H A T ============================================================================= btw: These are not the final docs... DEUH_B01.ZIP ( Power Duke CD) . Also included, unzipped, in few other CDS. 2 Quote Share this post Link to post
fraggle Posted September 26, 2023 Thanks - I did see that version I think; unfortunately I'm looking for versions that have source code though, as it's a source code history that I'm trying to build. Anyone have versions of DETH? I've only been able to find three (2.3, 3.6, 4.24). There were definitely more released. 1 Quote Share this post Link to post
thestarrover Posted September 26, 2023 41 minutes ago, fraggle said: Thanks - I did see that version I think; unfortunately I'm looking for versions that have source code though, as it's a source code history that I'm trying to build. Anyone have versions of DETH? I've only been able to find three (2.3, 3.6, 4.24). There were definitely more released. I found on my archive these versions: 2.1, 2.2, 2.5, 3.0, 3.5, 3.7 (unzipped), 3.85, 3.87, 3.89, 3.92, 4.14b, 4.16b. 1 Quote Share this post Link to post
Redneckerz Posted September 26, 2023 1 hour ago, thestarrover said: Right now I don't remember if it has been already mentioned, but Joe Wilcox (Simply Silly Software) released in May 1994 ( according to the date of DEUH.EXE) an hacked version of Deu 5.1 called DEUH 1.0 ( Beta version) DEUH.DOC Nope, it hasn't, that's a great discovery. This sounds like this was the predecessor of HFDE, which was for Doom 1. Perhaps this was made shortly prior? Without HFDE though, we can't know for sure. But using DEU 5.1 as basis for DEUH on May 15, 1994, when DEU 5.2 and 5.21 were released May 22, 1994 is either unlucky timing or mere coincidence. I can also see a slight irony in using BSP as your nodesbuilder versus DEU's own considering BSP's nodesbuilder contains (albeit a little) code from DEU itself. 1 minute ago, thestarrover said: I found on my archive these versions: 2.1, 2.2, 2.5, 3.0, 3.5, 3.7 (unzipped), 3.85, 3.87, 3.89, 3.92, 4.14b, 4.16b. By all means, upload these! In fact, if you have any other DEU hacks laying around (DEU II, ADE II and the like are known and on /idgames though) or any other editors, please share them aswell. For instance, 1DEU2 (Like MKD2EDIT, a DEU hack that adds Doom 2 support) by VT101 would be useful to have. The more the merrier. This thread and the 25 PWADS archaeology thread contain a wealth of information and i am happy that this research has been done, stuff like this is invalueable for the ages. 1 hour ago, fraggle said: Thanks - I did see that version I think; unfortunately I'm looking for versions that have source code though, as it's a source code history that I'm trying to build. Anyone have versions of DETH? I've only been able to find three (2.3, 3.6, 4.24). There were definitely more released. In case you missed it, @deathz0r published a rather complete official DEU collection in this post, going back when it was still called NEWDEU aswell (The last NEWDEU was 4.31). With that collection and your history (and hopefully Deathzor's post on the 7 DEU hacks he found), the entire DEU article on the wiki can be pretty much rewritten to a much higher standard. 3 Quote Share this post Link to post
thestarrover Posted September 26, 2023 (edited) Included in the zip: all the DETH versions I was able to find on my archive, another copy of DEU5BETA.ZIP found on a Mediashare cd, DEU II by Adler and three versions of DIE -Doom Image Editor. DETH +EXTRA.zip Edited September 26, 2023 by thestarrover 3 Quote Share this post Link to post
Redneckerz Posted September 27, 2023 11 hours ago, thestarrover said: Included in the zip: all the DETH versions I was able to find on my archive, another copy of DEU5BETA.ZIP found on a Mediashare cd, DEU II by Adler and three versions of DIE -Doom Image Editor. DETH +EXTRA.zip And you left in a surprise, namely 1DEU2 :) Very interesting, thank you. How did you find that one? So that's the Adler one, somehow in my brain i thought ADE II was the one and DEU II, but that's DEU2C by Admiral and Sonic. For readers out there, ill list out the details: Executable is from September 4, 1994. 1DEU-II.TXT: DEU II (V1.0) - Doom Editor Utility for DooM II: Hell on Earth -------------------------------------------------------------- DEU II by ADLER based on DEU 5.21 for DooM DEU2INFO.TXT and LINEDEF.TXT by AIRWOLF this program will enable you to edit doomII.wad. however, due to a bug in DEU it is possible that this program affects your doom II IWAD, so make a backup first. anyway, you know what you're doing, don't you, and won't complain if strange happenings spoil your pleasure of DOOM editing? ADLER the F*CKER LINEDEF.TXT: New Linedefs of DooM II ----------------------- DEU II does not direct support the new Linedefs of DooM II. To insert the new DooM II - Linedefs choose: EDIT LINEDEF -> CHANGE TYPE -> ENTER DECIMAL VALUE DEU2INFO.TXT: DEU II (V1.0) - Doom Editor Utility for DooM II: Hell on Earth -------------------------------------------------------------- DEU II by ADLER based on DEU 5.21 for DooM DEU2INFO.TXT and LINEDEF.TXT by AIRWOLF Use this DEU only with the new DOOM2.WAD from DooM II. Features of DEU II: - Editing of all 32 DooM II Level - Use all new DooM II Graphics - Place 8 new Monsters - Place 1 new Weapon (Super Shotgun) - Place 1 new Bonus (Megasphere) - Place various new Decoration-Things - Create PWAD-Files to run with DooM II Changes to DEU 5.21 ------------------- DooM II works no more with Episodes and Mission. DEU II needs only a Level-Number to edit a Level. Example: Type "E 7" to edit Level 7 Please note that the old DooM-IWAD or PWAD Files NOT compatible with DEU II. Make sure the MAIN-Entry in DEU2.INI points to the DOOM2.WAD. DooM II-Level: -------------- 1-29 = normal Game-Level 30 = Final Game-Level 31 = Secret Level 32 = Super Secret Level New Linedefs ! -------------- This Time DEU II does NOT suport the new Linedefs of DooM II direct ! See the LINEDEF.TXT how you can use the new Linedefs. Use the new Level ----------------- To use the PWAD-Levels from DEU II type: DOOM2 -FILE [pwadname] Manual for DEU -------------- Use the Manual from DEU 5.21 for DEU II 2 Quote Share this post Link to post
fraggle Posted September 27, 2023 20 hours ago, Redneckerz said: In case you missed it, @deathz0r published a rather complete official DEU collection in this post, going back when it was still called NEWDEU aswell (The last NEWDEU was 4.31). Thank you! There were a few there that I didn't already have; I've incorporated those into the history now. But a note to @deathz0r that DEU52.ZIP is not actually DEU 5.2; it's just another copy of 5.21 with the wrong name. I haven't been able to find a copy of 5.2 either but I reconstructed the (probable) source by comparing the 5.2 and 5.21 GCC ports. 16 hours ago, thestarrover said: Included in the zip: all the DETH versions I was able to find on my archive, another copy of DEU5BETA.ZIP found on a Mediashare cd, DEU II by Adler and three versions of DIE -Doom Image Editor. DETH +EXTRA.zip Thank you! This is also helpful - it means I now have a mostly-complete history of the DETH 2.x source history. It's a shame that with the 3.0 release they started shipping the source code separately. Here's DETH 2.3 as a repayment of sorts. I saw it wasn't in your .zip. deth23.zip 3 Quote Share this post Link to post
Redneckerz Posted September 27, 2023 (edited) 51 minutes ago, fraggle said: Thank you! There were a few there that I didn't already have; I've incorporated those into the history now. You are welcome. I have noticed that DEU 2.00 was released one time as DEU200.zip (Find here under February 1994), but in the DEU collection by Deathzor it is DMEDUT.ZIP, with a timestamp of January 26, 1994. It also doesn't have source code. Just as a heads up :) DEU 1.00 was never publically released. DEU 3.00 the first one with source code. Edited September 27, 2023 by Redneckerz 1 Quote Share this post Link to post
fraggle Posted September 27, 2023 27 minutes ago, Redneckerz said: DEU 1.00 was never publically released. DEU 3.00 the first one with source code. Yes, I saw that DEU.TXT in the older versions explained that. On 9/26/2023 at 11:07 AM, thestarrover said: DEUH_B01.ZIP ( Power Duke CD) . Also included, unzipped, in few other CDS. Side note, I just found another DEU5 beta on this CD (duum_1/grafix/deu5_b4.zip), so that's another one I can add to the history. It might be worth checking if there's anything else of interest on that CD. 3 Quote Share this post Link to post
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.