Doom 2 & Heretic Minor Sprite Fixing Projects (upd 11/28/22)

For high-res texture/sprite projects, sprite-fix patches, music add-ons, music randomizers, and other graphic/sound-only projects.
Forum rules
The Projects forums are only for projects. If you are asking questions about a project, either find that project's thread, or start a thread in the General section instead.

Got a cool project idea but nothing else? Put it in the project ideas thread instead!

Projects for any Doom-based engine (especially 3DGE) are perfectly acceptable here too.

Please read the full rules for more details.
User avatar
StroggVorbis
Posts: 866
Joined: Wed Nov 08, 2017 4:23 pm
Graphics Processor: nVidia with Vulkan support
Location: Germany

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by StroggVorbis »

Beezle wrote:This works with GZDoom right? Just need to load the D2SPFX19.wad and not the .deh file unless using with Chocolate Doom?
Yes, it does work with GZDoom. The .deh file is optional and can be loaded in any source port, IIRC all it does is change the firing frames of some monsters to be bright. Notably the zombieman and cyberdemon, which in vanilla doom don't light up in dark areas, which doesn't make much sense when their guns emit muzzle flashes.
Beezle
Posts: 139
Joined: Thu Aug 16, 2018 6:48 pm

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Beezle »

DabbingSquidward wrote: Yes, it does work with GZDoom. The .deh file is optional and can be loaded in any source port, IIRC all it does is change the firing frames of some monsters to be bright. Notably the zombieman and cyberdemon, which in vanilla doom don't light up in dark areas, which doesn't make much sense when their guns emit muzzle flashes.
Thanks DabbingSquidward! One more question though, the wads that require compatibility patches, Sunlust for example, do you have to load BOTH the patch and the Spritefix after sunlust.wad?
Dark Jaguar
Posts: 28
Joined: Fri Jul 13, 2018 9:35 am

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Dark Jaguar »

What's the best way to load DEH files in my autoload? I keep reading that I need to rename them some specific filename,and it can only do one at a time, but those posts are several years old. Can I load the DEH files in the same way I load the wads?
Beezle
Posts: 139
Joined: Thu Aug 16, 2018 6:48 pm

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Beezle »

Dark Jaguar wrote:What's the best way to load DEH files in my autoload? I keep reading that I need to rename them some specific filename,and it can only do one at a time, but those posts are several years old. Can I load the DEH files in the same way I load the wads?
I load them just like other wads/pk3s with the wad 1st and the .deh file after, for example btsx_e1a, btsx_e1b, then btsx_e1.deh. With ZDL you have to look under patch files or all files.
Gez
 
 
Posts: 17831
Joined: Fri Jul 06, 2007 3:22 pm

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Gez »

Dark Jaguar wrote:What's the best way to load DEH files in my autoload? I keep reading that I need to rename them some specific filename,and it can only do one at a time, but those posts are several years old. Can I load the DEH files in the same way I load the wads?
What you can do is rename it to dehacked.txt, zip it, and then call the zip something appropriate, like modname.dehzip.
Dark Jaguar
Posts: 28
Joined: Fri Jul 13, 2018 9:35 am

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Dark Jaguar »

Gez wrote:
Dark Jaguar wrote:What's the best way to load DEH files in my autoload? I keep reading that I need to rename them some specific filename,and it can only do one at a time, but those posts are several years old. Can I load the DEH files in the same way I load the wads?
What you can do is rename it to dehacked.txt, zip it, and then call the zip something appropriate, like modname.dehzip.
What I've been doing is putting the wad directory and name in the config file under autoload. I'm confused about your steps. What exactly do I do? I need to stick the wad in a zip file with the deh file for it to work?
Gez
 
 
Posts: 17831
Joined: Fri Jul 06, 2007 3:22 pm

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Gez »

Dehacked files are interpreted as dehacked files if they are named dehacked, because internal dehacked lumps in an archive are named dehacked. When you load a single file, if you want it to be treated as a specific lump, it has to be named accordingly. For example, if you load a mapinfo that is named foobar.map, it will not be interpreted as a mapinfo; whereas if you name it mapinfo.foo, it will be.

Dehacked patches are normally loaded with the -deh command line to tell ZDoom that it is a dehacked patch even if it's not named dehacked. You want a dehacked file to be loaded as a dehacked file, you have to call it dehacked. But since it can be confusing to have 273 files named dehacked.something, the idea is that you put it in an archive, that can have whatever name you want, and then you load that archive, and since the dehacked lump in it is named dehacked it will be treated as a dehacked lump.

You can also put the content of the dehacked text file in a dehacked lump in the wad, if you want. Same result.
Beezle
Posts: 139
Joined: Thu Aug 16, 2018 6:48 pm

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Beezle »

Thanks for the advice Dark Jaguar and Gez, I've never thought to do that. :)
Dark Jaguar
Posts: 28
Joined: Fri Jul 13, 2018 9:35 am

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Dark Jaguar »

Gez wrote:Dehacked files are interpreted as dehacked files if they are named dehacked, because internal dehacked lumps in an archive are named dehacked. When you load a single file, if you want it to be treated as a specific lump, it has to be named accordingly. For example, if you load a mapinfo that is named foobar.map, it will not be interpreted as a mapinfo; whereas if you name it mapinfo.foo, it will be.

Dehacked patches are normally loaded with the -deh command line to tell ZDoom that it is a dehacked patch even if it's not named dehacked. You want a dehacked file to be loaded as a dehacked file, you have to call it dehacked. But since it can be confusing to have 273 files named dehacked.something, the idea is that you put it in an archive, that can have whatever name you want, and then you load that archive, and since the dehacked lump in it is named dehacked it will be treated as a dehacked lump.

You can also put the content of the dehacked text file in a dehacked lump in the wad, if you want. Same result.
That's so strange that it's going off the first part of the file name to determine behavior instead of the extension, as is right and proper in the eyes of god and man. So, what should this archive look like? Using a shortcut for a mod like this doesn't really work, since I intend to have this autoload on the majority of my doom sessions. Do I just slap the word dehacked on the two files that come with this particular mod, put them in a zip file with the wads, and then insert the zip into the autoload section?
User avatar
Enjay
 
 
Posts: 26508
Joined: Tue Jul 15, 2003 4:58 pm
Location: Scotland
Contact:

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Enjay »

It's not strange at all. The extension can be used outside a container, such as a WAD (as Gez explained)* but inside a WAD it's different. Doom has always done that with lump names (right back to vanilla Doom). The first up-to-8 characters are a lump name and that name may tell Doom what to do with it.

[*however, the extension isn't really that important. the -deh command line parameter is.]

Why? In a WAD file, 8 is the maximum number of characters for a lump name and extensions to the name are not possible. That is what modern ports have inherited. It is those up-to-8-character names that Doom uses. Loading an external file that is not inside a WAD can use the same logic. So you could, for example, load titlepic.png into GZDoom from the command line to replace the TITLEPIC in the game because it is overriding the TITLEPIC name inside the IWAD. If you loaded mypic.png, it would be loaded, but GZDoom wouldn't know what to do with it unless you referenced it in a script or something.

Doom is file extension blind and will load anything, try to recognise its type and, if it does, use it appropriately. That even goes for WAD files. You could rename a WAD called DAVE.WAD to DAVE.ANYTHINGYOULIKE, load it with the -file command line option and Doom would still load it the same as if it had the WAD extension. And to repeat the titlepic example, you could also rename titlepic.png to just titlepic or titlepic.groovy, load it from the command line and it would still work.

Also, remember that long filenames were not a thing in 1993 when Doom came out. At that time, under DOS, there was no double-clicking of files to open programs, no associated files in the way we know them now and file extensions really didn't serve much more purpose than allowing file open/save dialogues to filter the display of files that the program knew about, or to allow a user looking at the file list to recognise what type of file was likely to be what.


Also consider that while a dehacked lump might have a relatively characteristic internal layout, it's still just a text file. How is Doom supposed to distinguish all the lumps of the same type that it can load? Maybe it's OK to consider DEH as an extension (in a container that would allow it - i.e. not a WAD), but MAPINFO, GLDEFS, DECORATE, ZSCRIPT, TEXTURES... are all text lumps. What do we do when we get to the few thousand patches and sprites that are all basically the same file type but which need to be used in the correct position in the game? The unique first part of the name is what's important.
Dark Jaguar
Posts: 28
Joined: Fri Jul 13, 2018 9:35 am

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Dark Jaguar »

Enjay wrote:It's not strange at all. The extension can be used outside a container, such as a WAD (as Gez explained)* but inside a WAD it's different. Doom has always done that with lump names (right back to vanilla Doom). The first up-to-8 characters are a lump name and that name may tell Doom what to do with it.

[*however, the extension isn't really that important. the -deh command line parameter is.]

Why? In a WAD file, 8 is the maximum number of characters for a lump name and extensions to the name are not possible. That is what modern ports have inherited. It is those up-to-8-character names that Doom uses. Loading an external file that is not inside a WAD can use the same logic. So you could, for example, load titlepic.png into GZDoom from the command line to replace the TITLEPIC in the game because it is overriding the TITLEPIC name inside the IWAD. If you loaded mypic.png, it would be loaded, but GZDoom wouldn't know what to do with it unless you referenced it in a script or something.

Doom is file extension blind and will load anything, try to recognise its type and, if it does, use it appropriately. That even goes for WAD files. You could rename a WAD called DAVE.WAD to DAVE.ANYTHINGYOULIKE, load it with the -file command line option and Doom would still load it the same as if it had the WAD extension. And to repeat the titlepic example, you could also rename titlepic.png to just titlepic or titlepic.groovy, load it from the command line and it would still work.

Also, remember that long filenames were not a thing in 1993 when Doom came out. At that time, under DOS, there was no double-clicking of files to open programs, no associated files in the way we know them now and file extensions really didn't serve much more purpose than allowing file open/save dialogues to filter the display of files that the program knew about, or to allow a user looking at the file list to recognise what type of file was likely to be what.


Also consider that while a dehacked lump might have a relatively characteristic internal layout, it's still just a text file. How is Doom supposed to distinguish all the lumps of the same type that it can load? Maybe it's OK to consider DEH as an extension (in a container that would allow it - i.e. not a WAD), but MAPINFO, GLDEFS, DECORATE, ZSCRIPT, TEXTURES... are all text lumps. What do we do when we get to the few thousand patches and sprites that are all basically the same file type but which need to be used in the correct position in the game? The unique first part of the name is what's important.
Very informative, thank you that does teach me a lot, but that brings me back to my core question. How do I load these very specific files with this mod in gzdoom inside the autoload config file? Am I supposed to embed these deh files inside the provided wads, embed the wad and the deh file inside a zip, or rename the deh files and then put that file name inside the config file? I'm very confused, and I think a step by step guide using this exact mod would resolve things for me.
User avatar
Marphy Black
Posts: 20
Joined: Mon Nov 12, 2012 3:18 am

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Marphy Black »

Dark Jaguar wrote:What's the best way to load DEH files in my autoload? I keep reading that I need to rename them some specific filename,and it can only do one at a time, but those posts are several years old. Can I load the DEH files in the same way I load the wads?
For the record, I did request a feature to allow loose DeHackED patches (i.e. in DEH or BEX format) to be autoloaded in the same manner as any other package that can be loaded at launch, similar to the DEH/BEX preload option first made available in Boom and followed in all derivatives since, but the request was No'd. Packing the DeHackEd patch into a WAD file or any other package format is not an option as that would break vanilla compatibility, and this is a vanilla-compatible project.
Dark Jaguar wrote:How do I load these very specific files with this mod in gzdoom inside the autoload config file? Am I supposed to embed these deh files inside the provided wads, embed the wad and the deh file inside a zip, or rename the deh files and then put that file name inside the config file?
Download these WAD files and add them to the appropriate Doom 1 and Doom 2 autoload sections in your config:
https://drive.google.com/file/d/1RYj7M9 ... sp=sharing

These are simply the DeHackEd patches packed into WAD files, which again is the thing I expressly intended to avoid, but there's just no easy way to do this in GZDoom. I did everything I could to make this very basic and core vanilla-compatible project as simple and user-friendly as possible, and there's nothing I can do to avoid this particular hassle brought on by GZDoom.
Gez
 
 
Posts: 17831
Joined: Fri Jul 06, 2007 3:22 pm

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Gez »

Marphy Black wrote:Packing the DeHackEd patch into a WAD file or any other package format is not an option as that would break vanilla compatibility, and this is a vanilla-compatible project.
Technically, you can duplicate the dehacked patch as both a DEHACKED lump that'll be read by (most) ports, and an external .deh file to be used with vanilla and Choco.
Dark Jaguar
Posts: 28
Joined: Fri Jul 13, 2018 9:35 am

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by Dark Jaguar »

Marphy Black wrote:
Dark Jaguar wrote:What's the best way to load DEH files in my autoload? I keep reading that I need to rename them some specific filename,and it can only do one at a time, but those posts are several years old. Can I load the DEH files in the same way I load the wads?
For the record, I did request a feature to allow loose DeHackED patches (i.e. in DEH or BEX format) to be autoloaded in the same manner as any other package that can be loaded at launch, similar to the DEH/BEX preload option first made available in Boom and followed in all derivatives since, but the request was No'd. Packing the DeHackEd patch into a WAD file or any other package format is not an option as that would break vanilla compatibility, and this is a vanilla-compatible project.
Dark Jaguar wrote:How do I load these very specific files with this mod in gzdoom inside the autoload config file? Am I supposed to embed these deh files inside the provided wads, embed the wad and the deh file inside a zip, or rename the deh files and then put that file name inside the config file?
Download these WAD files and add them to the appropriate Doom 1 and Doom 2 autoload sections in your config:
https://drive.google.com/file/d/1RYj7M9 ... sp=sharing

These are simply the DeHackEd patches packed into WAD files, which again is the thing I expressly intended to avoid, but there's just no easy way to do this in GZDoom. I did everything I could to make this very basic and core vanilla-compatible project as simple and user-friendly as possible, and there's nothing I can do to avoid this particular hassle brought on by GZDoom.
Thank you very much! This is exactly the answer I was looking for. I would have been fine with compiling the DEH into wads myself but you went the extra mile! I'll go with the download you've provided. And for the record, I'm in total agreement, that would be a welcome feature for GZDoom. I wonder just how many people have tried to slip DEH files into their autoload and assumed they were working when they weren't?
User avatar
SamVision
Posts: 2425
Joined: Tue Apr 13, 2010 4:47 pm
Location: Behind You

Re: Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/

Post by SamVision »

Some additional minor fixes. The revenant was missing a few pixels on his launcher in one frame, and the marine's boots are colored to not look like the zombieman's boots in this frame.
Attachments
SKELI6.png
SKELI6.png (2.4 KiB) Viewed 3141 times
PLAYO0.png
PLAYO0.png (2.1 KiB) Viewed 3141 times
Post Reply

Return to “Graphic/Audio Patches”