Revenant100 Posted January 13, 2015 (edited) Also available: Doom 2 Minor Sprite Fixing Project - v1.8 Release (updated 11/15/16) Heretic Minor Sprite Fixing and Widescreen-Friendly Project - v1.0 Release 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: These fixes are now part of the Doom 2 Minor Sprite Fixing Project. Please see that thread for the current download link. 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. 5. Fixed non-solid one-legged hanging corpse object clipping into ceiling. 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. Edited November 28, 2022 by Revenant100 0 Share this post Link to post
scifista42 Posted January 13, 2015 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. 0 Share this post Link to post
Revenant100 Posted January 13, 2015 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. 0 Share this post Link to post
scifista42 Posted January 13, 2015 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. 0 Share this post Link to post
uhbooh Posted March 23, 2016 Sorry about the bump, but here's a DeHackEd patch that fixes sound priority. You can add this to your patch if you want. http://www.mediafire.com/download/yj4g4eyagr5oi43/SNDFIX.DEH 0 Share this post Link to post
VGA Posted March 23, 2016 uhbooh said:Sorry about the bump, but here's a DeHackEd patch that fixes sound priority. You can add this to your patch if you want. http://www.mediafire.com/download/yj4g4eyagr5oi43/SNDFIX.DEH What does this do exactly? 0 Share this post Link to post
uhbooh Posted March 23, 2016 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. 0 Share this post Link to post
VGA Posted March 23, 2016 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? 0 Share this post Link to post
uhbooh Posted March 23, 2016 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. 0 Share this post Link to post
Linguica Posted March 23, 2016 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. 0 Share this post Link to post
Rayziik Posted March 23, 2016 Well that explains why revenants hordes always scream so goddamn loudly when you agitate them... 1 Share this post Link to post
Linguica Posted March 23, 2016 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? 0 Share this post Link to post
uhbooh Posted March 23, 2016 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. 0 Share this post Link to post
printz Posted March 23, 2016 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. 0 Share this post Link to post
Blastfrog Posted May 17, 2017 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? 0 Share this post Link to post
Reisal Posted May 17, 2017 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. 0 Share this post Link to post