Oldschool Doom player, new to custom WADs, which are worth downloading?

[DoomNoob]

Okay so I hit my first major snag trying to play something. What's the correct way to play something like Alien Vendetta?

The .exe doesn't work on my 64-bit Windows 10 OS, so I imagine I have to run the files separately through a source port, incorporating together AV.DEH, AV.WAD, and AVMOVFIX.WAD.

I tried the following to no avail:

source_port.exe -iwad doom2.wad -file av.deh -file avmovfix.wad -file av.wad

Just loads regular Doom 2.

 

Is this not the correct way to incorporate files together when loading an iwad with other wads and miscellaneous files?

 

Edit: Looks like maybe the order matters? Seems to work when I put -file av.wad before the other two av files. Not sure how to guarantee those other two files are being loaded however.

[Juza]

I recommend you try ZDL. It's easy to use and works. https://github.com/qbasicer/qzdl/releases/tag/v3.2.2.2-stable

[Nine Inch Heels]

1 hour ago, DoomNoob said:

I tried the following to no avail:

afaik all you need to do load is the av.wad, assuming you use PrBoom+ or any other limit removing source port.

 

By the way, as far as I'm concerned the only ports you'll ever need for single player purposes are PrBoom+, Eternity, and GZDoom, because those cover basically all use cases for just about everybody. PrBoom+ can look just as pixelated as dosbox imo, so if you really need that "VGA-feeling" you can just set that up accordingly.

 

Not saying there is any reason not to try other ports at some point, or have a port like choco for certain "vanilla hackjob wads" that need specific rendering or whatever, but the 3 ports above will cover like 98% of use cases you may have.

Edited November 21, 2018 by Nine Inch Heels

[Capellan]

50 minutes ago, DoomNoob said:

I tried the following to no avail:

source_port.exe -iwad doom2.wad -file av.deh -file avmovfix.wad -file av.wad

.

 

You need

source_port.exe -iwad doom2.wad -file av.wad avmovfix.wad -deh av.deh

 

If you're using prboom+ or similar, you'll also need to specify -complevel 2

 

Dehacked files are loaded differently to wads, and you don't need a separate file parameter for each wad.

 

[DoomNoob]

What do "dehackeds" do exactly and how are they distinct from the functionality of wads?

[Nine Inch Heels]

1 minute ago, DoomNoob said:

What do "dehackeds" do exactly and how are they distinct from the functionality of wads?

they change stuff in wads when loaded along with them, to put it in simple terms

[Master O]

4 minutes ago, DoomNoob said:

What do "dehackeds" do exactly and how are they distinct from the functionality of wads?

 

https://zdoom.org/wiki/DeHackEd

 

--- 

 

Other helpful links:

 

https://zdoom.org/wiki/Installation_and_execution_of_ZDoom

 

https://zdoom.org/wiki/Command_line_parameters  (also applies to GZdoom)

 

https://www.chocolate-doom.org/wiki/index.php/User_guide

 

https://www.chocolate-doom.org/wiki/index.php/Category:WADs

 

https://www.chocolate-doom.org/wiki/index.php/Category:TCs

[DoomNoob]

After reading that, I guess I don't see why such dehacked edits aren't part of the custom loadable wads to begin with

[Nine Inch Heels]

3 minutes ago, DoomNoob said:

After reading that, I guess I don't see why such dehacked edits aren't part of the custom loadable wads to begin with

Because that is where .pk3s and such come in, which didn't exist since forever, but AV is old as dirt. So that's why

[Bauul]

19 minutes ago, DoomNoob said:

After reading that, I guess I don't see why such dehacked edits aren't part of the custom loadable wads to begin with

 

Originally, Dehacked was a program that directly altered the game's executable.  It wasn't merely a file you loaded, you used the program to literally change the makeup of Doom.exe/Doom2.exe to adjust how the game worked.  The .deh file was bundled separately because you had to load the file in Dehacked, make the changes to the executable, and then run the game.  Then when you were done with the wad, you needed to reload Dehacked and restore the .exe to its original form.

 

Over time, source ports became advanced enough that you could merely specify the .deh file in the load order and it would apply the changes on the fly, temporarily applying them to the game.  And then even as even more time went on, source ports became so advanced you could actually bundle the .deh file into the wad itself, and it would automatically load it.  As a result, you very rarely see a separate .deh file any more.

 

Alien Vendetta predates all of that though, so the .deh file still exists separately to rest of the files.  This is a good example of how Doom mapping is not a single point in time, but a tapestry of changing customs, technology and protocols over a 25 year period.  Somethings make no sense now, but make perfect sense in the context of when they were created.

[DoomNoob]

Very interesting... thanks for the detailed explanation.

 

I also noticed this in the readme:

 

Quote

[1.8 Avmovfix.wad]
 
Unfortunately we discovered a limmitation regarding map20 and demorecording.
If you attempt a full game run with doom2.exe it will bomb out in map20 
with an error message if the -maxdemo parameter is set high enough.
To avoid this we included an altered version of map20 as avmovfix.wad,
its basically map20 w/o the hughe mountain area. Such a high -maxdemo
valu is only of interest for a possible maxkill movie run, even episode
recordings work fine with no fix added.

Note that his one is only of interest for demorecorders in compet-N context,
and should be ignored if using a port such as zdoom.

 

From https://doomwiki.org/wiki/Parameter I see that:

 

Quote

-maxdemo

(recording)

doom -record <demo> -maxdemo <kilobytes>

This defines the maximum size in kilobytes for a demo recording, instead of the usual value of 128 (which is roughly 15 minutes for a single-player game). If the limit is reached while recording, the game ends with a Demo <demo>.lmp recordedmessage in the command line.

 

Why might a big map have anything to do with a specified max demo size? I assume people set a huge value for recording full playthrough but then somehow big maps break something during recording?

 

Is it saying that it's only a problem for reaaaallllly long runs where you're trying to kill everything? What value would cause such a break?

[Edward850]

It has nothing to do with map size explicitly, but demo length (and thus play time). Vanilla doom originally set a fixed size for the demo buffer to record to, and aborted once the buffer was full. Predictably, multiplayer recordings filled this buffer faster due to more player inputs per tic. Maxdemo changes the size of the buffer, thus allowing for longer recordings.

All ports made this dynamic and no longer need the maxdemo parameter, including chocolate doom if you disable the "Vanilla demo limit" option.

 

The issue with AV is because of the actual size of the map itself and everything in it required a lot of memory itself, and Doom was only designed to use a specific amount of memory from heap. Trying to allocate all the resources for both the demo buffer and the level itself required more than what the memory heap was designed to provide. Again, not a problem if you're using something like PRBoom+ or chocolate doom.

Edited November 21, 2018 by Edward850

[DoomNoob]

16 hours ago, Edward850 said:

It has nothing to do with map size explicitly, but demo length (and thus play time). Vanilla doom originally set a fixed size for the demo buffer to record to, and aborted once the buffer was full. Predictably, multiplayer recordings filled this buffer faster due to more player inputs per tic. Maxdemo changes the size of the buffer, thus allowing for longer recordings.

All ports made this dynamic and no longer need the maxdemo parameter, including chocolate doom if you disable the "Vanilla demo limit" option.

 

Hmm I don't see such an option in Crispy Doom... unless these max demo issues are just resolved by default in Crispy, PrBoom, GZDoom, etc? 

 

Only issue being that if someone were to replay that demo back in regular Dosbox Doom it'd crash or be unloadable, etc?

[Edward850]

I'd imagine crispy has resolved by default, yes. As does prboom and gzdoom. 

I'd suspect yes, if the demo is too large vanilla won't be able to play it back, however this is not a problem because chocolate, crispy and prboom will. 

 

Note not gzdoom. An important note that unless you're playing a map set or mod explicitly made for gzdoom, demos from it aren't generally accepted. They are incompatible with all other ports, it can't playback vanilla demos itself, and it's own demos won't even stay in sync after a few updates.

[DoomNoob]

2 minutes ago, Edward850 said:

I'd imagine crispy has resolved by default, yes. As does prboom and gzdoom. 

I'd suspect yes, if the demo is too large vanilla won't be able to play it back, however this is not a problem because chocolate, crispy and prboom will. 

 

Note not gzdoom. An important note that unless you're playing a map set or mod explicitly made for gzdoom, demos from it aren't generally accepted and are incompatible with all other ports, including itself after a few updates.

 

Last sentence made me lol.

 

Yeah I guess mentally so far I've sort of placed GZDoom in its own sort of category. 

 

The impression I get is "use PrBoom+ for all WADs when possible, and GZDoom when it's required," and anything in the latter is sort of confined to its own ecosystem. Is that a fair assessment?

[Nine Inch Heels]

10 minutes ago, DoomNoob said:

The impression I get is "use PrBoom+ for all WADs when possible, and GZDoom when it's required," and anything in the latter is sort of confined to its own ecosystem. Is that a fair assessment?

Roughly how I go about things myself, so I'd say "yes".

 

Worth noting though that GZDoom demos doesn't mean it's an instant disqualifier for a demo, but the problem is that virtually every update to it desyncs demos recorded in older versions, and nobody ever cares to keep fuckin' 2 year old versions of it around for the odd case of watching an older demo. It's also the reason almost nobody ever speed-/max-runs GZDoom-maps professionally, because chances are nobody gets to watch those anymore at some point. And even though demos can be a good tool to learn and improve mapping, because watching somebody play your stuff really helps, it's always an annoying hassle to make sure you run the same versions if you wanna use demos as a way to give valuable feedback.

/rant

[DoomNoob]

3 minutes ago, Nine Inch Heels said:

Roughly how I go about things myself, so I'd say "yes".

 

Worth noting though that GZDoom demos doesn't mean it's an instant disqualifier for a demo, but the problem is that virtually every update to it desyncs demos recorded in older versions, and nobody ever cares to keep fuckin' 2 year old versions of it around for the odd case of watching an older demo. It's also the reason almost nobody ever speed-/max-runs GZDoom-maps professionally, because chances are nobody gets to watch those anymore at some point. And even though demos can be a good tool to learn and improve mapping, because watching somebody play your stuff really helps, it's always an annoying hassle to make sure you run the same versions if you wanna use demos as a way to give valuable feedback.

/rant

 

Is there a particular reason more people don't just use screenrecorders instead of recording in-game demos if things like desyncs are a prevalent issue?

[Nine Inch Heels]

Just now, DoomNoob said:

 

Is there a particular reason more people don't just use screenrecorders instead of recording in-game demos if things like desyncs are a prevalent issue?

Yes there is. Screenrecordings are much, much less compact than a demo.lmp is, and videos can easily disappear off the net for one reason or another. Hence, the DSDA only accepts demos, and not links to videos. Plus it's easy to validate a run when you have a demo, but it's basically impossible to validate a video. So for speedrunning purposes demos are mandatory, because those can not only be watched, but also "read" for things like cheating (such as passing of a tool assisted run as a normal run).

 

Clearly if all you want is to just give feedback, might as well just record and upload to Youtube, but for speedruns you better have a demo.

[DoomNoob]

Which MIDI devices do people like using?

 

Seems kind of tricky to get things to sound similarly among all the different source ports.

 

Right now I'm using SDL with PrBoom but Native MIDI with Crispy Doom because then they sound a little more consistent, at least I think?

Edited November 21, 2018 by DoomNoob

[Kira]

It's a tricky one to answer as far as I'm concerned. Some pwads will use midi that sound better with one device or another. At the moment I opt for fluidsynth because it's one where the music volume is just about right for me and I don't have lag when it loops, but people may have more elaborate solutions that should sound way better.

I sort of remember a project to improve midi instruments from 2 years ago or so, but maybe I'm mistaken.

[KVELLER]

1 hour ago, DoomNoob said:

Which MIDI devices do people like using?

 

Seems kind of tricky to get things to sound similarly among all the different source ports.

 

Right now I'm using SDL with PrBoom but Native MIDI with Crispy Doom because then they sound a little more consistent, at least I think?

 

I personally use an external program called VirtualMIDISynth for MIDI playback, plus some soundfonts so it sounds better. It gets integrated into Windows once installed, so Native MIDI generally "calls" it whenever necessary.

[Master O]

5 minutes ago, Kira said:

It's a tricky one to answer as far as I'm concerned. Some pwads will use midi that sound better with one device or another. At the moment I opt for fluidsynth because it's one where the music volume is just about right for me and I don't have lag when it loops, but people may have more elaborate solutions that should sound way better.

I sort of remember a project to improve midi instruments from 2 years ago or so, but maybe I'm mistaken.

 

https://www.doomworld.com/forum/topic/95697-dmxopl-v210-happy-holidays-nov-27/

 

Also, GZdoom now has native support for that particular midi improvement patch.  See the above thread for further info.

[Kira]

11 minutes ago, Master O said:

 

https://www.doomworld.com/forum/topic/95697-dmxopl-v210-happy-holidays-nov-27/

 

Also, GZdoom now has native support for that particular midi improvement patch.  See the above thread for further info.

That's the one, thank you! Now I suppose I have to set some time aside and look up how to use it properly with prboom+.

[galileo31dos01]

58 minutes ago, DoomNoob said:

Which MIDI devices do people like using?

 

Seems kind of tricky to get things to sound similarly among all the different source ports.

 

Right now I'm using SDL with PrBoom but Native MIDI with Crispy Doom because then they sound a little more consistent, at least I think?

 

I stayed since day 1 with soundblaster OPL3 in Crispy and/or ZDoom, stock midis just sound really good imho. In PRBoom+ (or GL, which is what  I use), I have opl2 selected by default even if most midis sound not as good as in OPL3, but SDL or fluidsynth don't strike me at all aside from specific cases. 

[Bauul]

4 hours ago, DoomNoob said:

 

Is there a particular reason more people don't just use screenrecorders instead of recording in-game demos if things like desyncs are a prevalent issue?

 

To add a little more explanation to the demo subject, the way Doom records demos is to literally just record the player inputs: e.g. "press forwards for X frames, press left for X frames" etc. (or "tics" to use the proper terminology).  When you play a demo, the demo basically plays the game for you, taking over your controls.  The big benefit is this results in a tiny file: literally just a row of times and actions.  The reason syncing is so fragile is that your copy of the game has to treat the demo's inputs in exactly the same way as the original player's game did.  For example, in the original player's game, that imp decided to wait 68 tics before throwing a fireball.  When you play back the demo, your game has to also decide that the imp is going to wait exactly 68 tics before throwing a fireball.  Every single microscopic action has to play out in exactly the same way.

 

Unsurprisingly it's pretty tricky to continue improving a source port and ensure it acts in exactly a consistent way.  The ZDoom developers (and subsequently the GZDoom developers) long ago decided it was better to improve the game than stick rigidly to old standards, whereas PRBoom+ made a point of putting in the work to ensure things still worked.  Different priorities for different ports.

 

In subsequent games like Quake, id software developed a much more robust demo method: it wouldn't record player inputs, but actual player positions and actions, along with the positions and actions of every single other enemy and item.  You wouldn't have to rely on your game deciding that imp was going to throw a fireball at 68 tics, the demo would force it to.  It was actually built using the multiplayer functionality: the same method that your game in a deathmatch knows when an enemy player shoots a rocket was used to control the enemies.  If ports like GZDoom ever get a fully functional client/server multiplayer model, we may see a rise of fully cross-version compatible GZDoom demos.

Edited November 22, 2018 by Bauul

[KVELLER]

1 hour ago, Bauul said:

In subsequent games like Quake, id software developed a much more robust demo method: it wouldn't record player inputs, but actual player positions and actions, along with the positions and actions of every single other enemy and item.  You wouldn't have to rely on your game deciding that imp was going to throw a fireball at 68 tics, the demo would force it to.  It was actually built using the multiplayer functionality: the same method that your game in a deathmatch knows when an enemy player shoots a rocket was used to control the enemies.  If ports like GZDoom ever get a fully functional client/server multiplayer model, we may see a rise of fully cross-version compatible GZDoom demos.

 

I had no idea that was a thing. It's a really interesting system.

[Roofi]

Eternal Slumber Party 1 and 2.

[DoomNoob]

How do you all like to make wads / make levels / etc?

 

Does anyone ever mess with the Doom source code any? Does it take anything crazy to do something simple like add debug variables to the automap? (As an example)

[Nine Inch Heels]

doom editing tutorials exist. I suggest you check those out before asking like 100 questions that could be answered by looking at these tutorials. Currently people use SLADE, Doombuilder X, or GZDB (bugfix) to make maps. SLADE is mandatory for custom music, sprites, enemies and textures and the builders are usually better mapping tools than SLADE, even though it has a built in builder as well.