Doom 2 & Heretic Minor Sprite Fixing Projects (upd 1/27/18)

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 YOUR 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.

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

Postby StroggVorbis » Sat Apr 27, 2019 10:15 am

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.
User avatar
StroggVorbis
Donut eat me pls!
 
Joined: 08 Nov 2017
Location: Germany
Discord: StroggVorbis#2466
Operating System: Windows 10/8.1/8/201x 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support

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

Postby Beezle » Mon Apr 29, 2019 8:24 am

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?
Beezle
 
Joined: 17 Aug 2018
Discord: #8423

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

Postby Dark Jaguar » Fri May 10, 2019 12:55 pm

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?
Dark Jaguar
 
Joined: 13 Jul 2018

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

Postby Beezle » Fri May 10, 2019 1:48 pm

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.
Beezle
 
Joined: 17 Aug 2018
Discord: #8423

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

Postby Gez » Fri May 10, 2019 3:00 pm

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.
Gez
 
 
 
Joined: 06 Jul 2007

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

Postby Dark Jaguar » Sat May 11, 2019 3:58 am

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?
Dark Jaguar
 
Joined: 13 Jul 2018

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

Postby Gez » Sat May 11, 2019 6:54 am

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.
Gez
 
 
 
Joined: 06 Jul 2007

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

Postby Beezle » Sat May 11, 2019 9:34 am

Thanks for the advice Dark Jaguar and Gez, I've never thought to do that. :)
Beezle
 
Joined: 17 Aug 2018
Discord: #8423

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

Postby Dark Jaguar » Sat May 11, 2019 12:01 pm

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?
Dark Jaguar
 
Joined: 13 Jul 2018

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

Postby Enjay » Sat May 11, 2019 2:29 pm

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.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

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

Postby Dark Jaguar » Sat May 11, 2019 3:31 pm

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.
Dark Jaguar
 
Joined: 13 Jul 2018

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

Postby Marphy Black » Sat May 18, 2019 5:09 am

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.
User avatar
Marphy Black
 
Joined: 12 Nov 2012

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

Postby Gez » Sat May 18, 2019 7:19 am

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.
Gez
 
 
 
Joined: 06 Jul 2007

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

Postby Dark Jaguar » Sun May 19, 2019 1:19 pm

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?
Dark Jaguar
 
Joined: 13 Jul 2018

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

Postby SamVision » Tue Feb 18, 2020 7:54 pm

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.
You do not have the required permissions to view the files attached to this post.
User avatar
SamVision
 
Joined: 13 Apr 2010
Location: Behind You

PreviousNext

Return to Graphic/Audio Patches

Who is online

Users browsing this forum: No registered users and 2 guests