DOOM BBS Add-Ons: An 800+ WAD mega dump

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:

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:

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

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:

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:

• 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)

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)

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.

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.

@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?

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 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.

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.

@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 v1.00.725 Beta, July 25, 1995

ÚÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ¿
³ °°°°°°° 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--

  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.

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

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

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

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)

@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.

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.

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 :)

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?

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.

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 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.

@fraggle @ETTiNGRiNDER 

When I can I will upload the doom, heretic and hexen files so you can take a look at them.

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.

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.

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.

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.

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 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.

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

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

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

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.

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.