More goodies from Romero (DoomEd source, maps, graphics)

Urban Space Cowboy said:

I'm going to hazard a guess of probably not. In Romero's ZIP archive, all those LBMs are dated May 13, 1993.

The idea could be much older then the attempt to use it. See map10, for instance. It is very possible they originally intended to include them in Doom 1, but shelved them for Doom II development and finally abandoned that idea alltogether. Considering the hint for side moving crushers, they clearly had the idea for side moving geometry all along, but never bothered to properly code it. Maybe that was even before they had BSP.
Who knows what we would have gotten, if they had opted for a portal renderer instead, like Dark Forces or Build games did.

gonna do this for all the maps, will take a while though.

greate! but such comparision did't reflect texture and monster/items changes

That comparison is really cool. I tried doing that for the alpha maps and console ports, but I could never get the images to be consistently sized.

ABRACADABRA said:

greate! but such comparision did't reflect texture and monster/items changes

correct, you are welcome to do something to that end yourself though!!

OK, converted them all: http://www.doomworld.com/linguica/romerofiles/mapgifs/

XCOPY said:

kb1, for # is a number, add "level:E#M#" (without quotes, case sensitive) to the second line of each DWD, in case you use idbsp 1.0 (level:MAP## doesn't work for whatever reason). the map lump name will be named according to the line added.

in any case, links are working again.

Thanks, for the info, and the maps!

I wonder how different DEU and other DOS editors would have been, if id had decided to just put the DWD files in the IWAD and build the BSP at runtime.

I wonder how different DEU and other DOS editors would have been, if id had decided to just put the DWD files in the IWAD and build the BSP at runtime.

You mean if id had decided on 5-20 minute load times between levels?  :>   No editors, because no sales.

Xeriphas1994 said:

You mean if id had decided on 5-20 minute load times between levels?  :>   No editors, because no sales.

The idea of BSP builds taking more than a few seconds seems so crazy now people would probably think it a lie. I can remember a few BSP builds in those time ranges myself, back on the old 486 75.

Back then, it was DoomCAD iirc, while bsp-ing a map the editor marked what i think was the area which was computed by overlay an rectangle over this area. So yes, it takes time sometimes. However bsp, lite and vis of a quake map took ages in comparsion.

I remember Doom taking more time than DOS to load. I don't remember exactly, but Doom was more than 5 times slower to load than the OS. Doom is almost an OS itself. I can't imagine nodes building in five minutes when now it takes 2 seconds. That's a lot of time before you see your changes on your map.

Doom was bigger in size as DOS was. A DOS installation, including drivers for the mouse and a soundcard, capable to run Doom fits on a 1.44M disc. :-D

Quasar said:

The idea of BSP builds taking more than a few seconds seems so crazy now people would probably think it a lie. I can remember a few BSP builds in those time ranges myself, back on the old 486 75.

Don't take the DEU node builder as a reference. I remember how long that took. If you compare it with IDBSP, you find out that the latter is a lot faster and even builds the reject map.

Also, Doom maps weren't nearly as complex as some 3rd party maps. It wasn't even feasible before they bumped the visplane limit in Doom v1.666.

Long waiting times in games weren't uncommon at all, and still aren't. Besides the start up time, we were lucky that Doom responded pretty fast indeed.

axdoom1 said:

I remember Doom taking more time than DOS to load. I don't remember exactly, but Doom was more than 5 times slower to load than the OS. Doom is almost an OS itself.

Older versions of doom actually start up with "Doom Operating System v1.2" and suchlike in the loading screen. I don't recall when they stopped but the string isn't in the linuxdoom source.

Has anyone tried running these maps through Revenants DMVIS tool so we can get an even closer look of the development process of these maps?

Has anyone tried running these maps through Revenants DMVIS tool so we can get an even closer look of the development process of these maps?

Here E1M1.wad from doom-maps/doombsp/

saddly it lacks many earlier iterations of the map construction

ChaingunnerX said:

Here E1M1 from doom-maps/doombsp/

It that from the DWD file or from the WAD file. It's interesting, that the order differs slightly from https://github.com/devinacker/dmvis/blob/master/maps/doom/doom.wad_E1M1.gif

It also seems the doombsp orders the lines by sectors, which is apparent in https://github.com/devinacker/dmvis/blob/master/maps/doom2/Doom2.wad_MAP29.gif
We now know that the big sector didn't have that many lines that early.
It's also not visible in the animations that they changed the swastika in E1M4.

And oddly enough, the starting room in map01 is the very first thing drawn, eventhough, they redid it last: https://github.com/devinacker/dmvis/blob/master/maps/doom2/Doom2.wad_MAP01.gif

ABRACADABRA said:

saddly it lacks many earlier iterations of the map construction

One interesting thing, though, is the construction of the zig-zag path before the general shape of the room. I think that says a lot about his goals when creating that map.

Linguica said:

OK, converted them all: http://www.doomworld.com/linguica/romerofiles/mapgifs/

Map06 is so jarring because the original layout feels so unAmerican in its general shape and design.

ABRACADABRA said:

saddly it lacks many earlier iterations of the map construction

That's why the computer room is one of the last to be made, it replaced a corridor with a window overlooking the courtyard.

I wonder if they used a version control system for the maps. A look at the complete history of every map would be very interesting.

LogicDeLuxe said:

I wonder if they used a version control system for the maps. A look at the complete history of every map would be very interesting.

Yeah, one interesting thing about the DWD format (besides vertices and sectors being implicit, of course) is that linedefs don't even have a canonical number associated with them - they're just a list. If you set up your tools correctly to make the list ordering deterministic - say, by starting at one corner of the map space and listing every linedef you hit in order - it would be a pretty effective way to do versioning, generate diffs, etc.

I was wondering how Petersen managed to basically combine two maps in order to create the final Map28 because I didn't think DoomEd would have that capability, but then someone pointed out you could basically just smush the two DWDs together and sort it out in the editor.

DoomEd does support having multiple maps open at the same time, and you can copy and paste between them. I think trying to merge two dwds would make more work for him than just copying the geometry and things he wanted over.

Linguica said:

Yeah, one interesting thing about the DWD format (besides vertices and sectors being implicit, of course) is that linedefs don't even have a canonical number associated with them - they're just a list. If you set up your tools correctly to make the list ordering deterministic - say, by starting at one corner of the map space and listing every linedef you hit in order - it would be a pretty effective way to do versioning, generate diffs, etc.

For reference, I talked a bit about this in my comment earlier in the thread.

Seeing how DoomEd works, the peculiarities related to the block sound linedef flag in map 1, 15, 18, 19 and 26 make kind of sense.

axdoom1 said:

I remember Doom taking more time than DOS to load. I don't remember exactly, but Doom was more than 5 times slower to load than the OS. Doom is almost an OS itself. I can't imagine nodes building in five minutes when now it takes 2 seconds. That's a lot of time before you see your changes on your map.

It's *not* a terrible exaggeration, for many reasons people often don't consider:

• Doom provides its own heap implementation, like most OSes do (though not nearly as sophisticated - or efficient).
  
• Doom uses a cooperative multitasking system to schedule processing of tasks (thinkers) with a constant timeslice of 35 Hz. In its iteration in Hexen, these tasks can even be programmed to execute arbitrary code (applications, in the form of ACS scripts, which function as coroutines).
  
• Doom includes low-level code to read mouse, keyboard, and joypad input directly from BIOS, bypassing DOS.
  
• Doom contains its own video refresh code which makes no use of DOS beyond the initial int 21h call to set the mode.
  
• Doom contains specialized code for interacting with specific device drivers like the CyberMan 3D mouse.
  
• Doom implements a simplistic graphical UI system.
  

Not on the order of complexity of, say, Windows 3.11, which is effectively an 8086 virtual machine hypervisor, but it is certainly more complex itself in many ways than the OS it runs on top of. I always say that about the only useful thing DOS really does is what it says on the front cover - it does disk IO for you.

axdoom1 said:

I remember Doom taking more time than DOS to load.

To be fair, almost everything running under DOS took longer to load than DOS itself, especially if we're referring just to MSDOS.SYS, IO.SYS and COMMAND.COM. I remember how I mocked Windows 95's loading time of several minutes (on 4 MB machines) while DOS booted practically instantly even from a floppy. The only thing able to beat DOS at that would be some weird super-custom loader routine, e.g. in some scene demo or unusual application software like Scala MM.

axdoom1 said:I can't imagine nodes building in five minutes when now it takes 2 seconds. That's a lot of time before you see your changes on your map.

I didn't believe that either in 1994, because I had a 486DX (aka built-in FPU). But legend has it that those folks without one (users of 486[i]SX{/i], 386 without 387 FPU etc. really did experience such protracted node-building times.

I once managed to get hold of an 8087 FPU chip that fit into an old PC XT's mobo, and tried software compiled on some ancient Turbo Pascal compiler, with and without 8087 optimizations. The 8087-enabled software was up to 10 times faster, so it's not crazy to read about such large performance discrepancies with and without a FPU.

Quasar said:

It's *not* a terrible exaggeration, for many reasons people often don't consider

Funny - I was going to reply just about the same way, until I saw your post. Don't forget the caching of lumps, not unlike DOS "SmartDrv". Those were the days :) It is difficult for the youngsters to comprehend that the "desktop" GUI, and the bundling of hundreds of utility apps that come with modern OSes are not the OS - they are simply apps running on top of the OS.

It breaks my heart when my dual-core 3.2GHz Win7 work PC is blown away by my single-core 2GHz XP machine, because of all the bloat. It's getting too complex for me to prevent all of these background jobs/tasks from running, just to try to get some performance these days.
Hell, my 486-50 DOS 6.22 machine responded to my keystrokes faster than this Win7 PC. For shame.

Hey, Mr. Romero, do you possibly have any more unreleased game content to share? I'm sure me and many others would be highly interested in this.