Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Revenant100

Doom 1 and 2 Minor DeHackEd Fixes

Recommended Posts

Also available:

This is a minor extension of my sprite fixes. As mentioned in the other thread, there are a handful of errors in Doom and Doom 2 that cannot be addressed by graphic alterations alone. Hence, I've compiled some minor fixes in the form of DeHackEd patches.

To allow for maximum compatibility, the patches are provided as loose DEH files so they can be loaded into DeHackEd should you want to play with the vanilla executables. D1DEHFIX.DEH is intended for Ultimate Doom 1.9, while D2DEHFIX.DEH is intended for Doom 2 1.9. You can pretty much use these patches with any other level or mod as I can't imagine any significant conflicts. Simply run them with the lowest priority in the add-on hierarchy. Most newer source ports have an autoload feature, so I recommend using that.

Here's the current download with both Doom 1 and 2 DeHackEd patches:Image preview of the fixes in effect (see list below):


Since not too much had to be changed, here's the complete changelog:
1. Made the Zombieman's and Cyberdemon's firing frames bright.
2. Made the Heavy Weapon Dude's refiring frame bright.
3. Made the Arachnotron's and Spider Mastermind's initial attack frames (before they begin firing) non-bright.
4. Decreased the duration of the Super Shotgun's muzzle flash so it doesn't overlap with the following reloading frame.

And just as a matter for discussion, I'll also point out something I'm aware of but did not change: I did not make the Cyberdemon's or Spider Mastermind's death frames bright even though they both involve explosions. While there is a precedent for a non-bright monster becoming bright in its explosive death in the form of the Pain Elemental (and the barrel too, technically), it's safe to say that any modifications up to this point that alter the graphics for these two boss monsters were not developed with having the death sequences being bright in mind. To avoid instances of inexplicably luminescent boss deaths in custom levels, I've left the frames non-bright.

And one final note, these changes are purely cosmetic and will not cause demo desyncs. These patches are completely safe to use even while running demos.

Share this post


Link to post

The sad thing about DEHACKED mods is that (edit: or not?) they completely override any custom DEHACKED of a custom wad they're played with (even if they only alter level names), and in this case, it's all just for a few little tweaks in monster brightness. So my point is, this cannot have much use.

Still, it's nice that you made it exist. I personally won't use the patch anyhow, though, because I'm actually more comfortable with the original behaviour - specially that Arachnotrons and SMMs can be spotted in darkness before they start to attack. Unrealistic, but great from a gameplay perspective. Bright zombiemen also felt weird to me when I've DEHACKED-altered them myself, once.

Share this post


Link to post
scifista42 said:

The sad thing about DEHACKED mods is that (edit: or not?) they completely override any custom DEHACKED of a custom wad they're played with (even if they only alter level names), and in this case, it's all just for a few little tweaks in monster brightness. So my point is, this cannot have much use.

This is not correct. Multiple DeHackEd patches can be run in conjunction with one another and they will all take effect. This is even true with the vanilla executables as you can load several DEH files on top of one another in the program before writing the changes to the exe. I tested these fixes with Going Down which includes an embedded DEHACKED lump that changes the automap level names, among other things, and there were no conflicts.

Share this post


Link to post

Alright, you're apparently true - for cases of DEHACKEDs that don't change the same things in different ways. My own crazy DEHACKEDs frequently change monster states etc., so that might be why I've experienced the "overriding" - but I suppose that most of normal DEHACKEDs don't do anything like that (to the arachnotron, zombieman etc.) and your deh patch is pretty neutral in that regard. So it's OK, sorry.

Share this post


Link to post
VGA said:

What does this do exactly?


Fixes inconsistencies with sound priority and singularity. For example, DSSKESIT has the same priority as all of the other sight sounds.

Share this post


Link to post

Does this only matter for ports that have the limited channels that vanilla has?
Which priority is higher? High number or low?
What does singularity mean?

Share this post


Link to post
VGA said:

Does this only matter for ports that have the limited channels that vanilla has?

Yes

Which priority is higher? High number or low?

Lower

What does singularity mean?

To be honest, I don't even remember what it does. I just gave it sounds like SKESIT and GETPOW for consistency.

Share this post


Link to post

IIRC "singularity" means the sound will only play once at a time, and a new instance of the sound will cut off an old instance. See, e.g., the chainsaw's idling noise.

Share this post


Link to post

Well that explains why revenants hordes always scream so goddamn loudly when you agitate them...

Share this post


Link to post
Linguica said:

I don't know if the game actually uses it, though. Like I'm pretty sure the released source totally ignores the sound priority settings, and nothing actually seems to use the singularity settings. Those might have been changed for the Linux version though?

Keep in mind that the linux source doesn't include the original sound library for some legal reason.

Share this post


Link to post
Linguica said:

IIRC "singularity" means the sound will only play once at a time, and a new instance of the sound will cut off an old instance. See, e.g., the chainsaw's idling noise.

I thought that's merely because they're played from the same thing (you). Each thing in Doom only seems to have one channel.

Share this post


Link to post

Sorry to bump this, but I find this talk of sound priority/singularity interesting.

 

Is this something that the vanilla engine ever bothered with, in any version from 1.0 to 1.9? And if so, does Chocolate emulate it?

Share this post


Link to post

I know I did these sorts of fixes for Random Deaths & Decoration quite some time ago because I found lighting up the firing frame for Cyberdemon and delighting the non-firing for the chaingunner and spider enemies looked silly. I'm not lighting up the zombieman's frame because I just don't like the way it looks.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×