Page 5 of 6

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

PostPosted: Sat Apr 27, 2019 10:15 am
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.

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

PostPosted: Mon Apr 29, 2019 8:24 am
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?

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

PostPosted: Fri May 10, 2019 12:55 pm
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?

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

PostPosted: Fri May 10, 2019 1:48 pm
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.

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

PostPosted: Fri May 10, 2019 3:00 pm
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.

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

PostPosted: Sat May 11, 2019 3:58 am
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?

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

PostPosted: Sat May 11, 2019 6:54 am
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.

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

PostPosted: Sat May 11, 2019 9:34 am
by Beezle
Thanks for the advice Dark Jaguar and Gez, I've never thought to do that. :)

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

PostPosted: Sat May 11, 2019 12:01 pm
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?

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

PostPosted: Sat May 11, 2019 2:29 pm
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.

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

PostPosted: Sat May 11, 2019 3:31 pm
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.

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

PostPosted: Sat May 18, 2019 5:09 am
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.

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

PostPosted: Sat May 18, 2019 7:19 am
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.

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

PostPosted: Sun May 19, 2019 1:19 pm
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?

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

PostPosted: Tue Feb 18, 2020 7:54 pm
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.