Sprites Doom 2 Minor Sprite Fixing Project - v2.0 Release (updated 11/28/22)

7 minutes ago, nobleflame said:

Unintentional - new to this! Thanks for the advice :)

Hmm? Oh sorry, nono, that was to Max, who was helping you, not to you specifically. He already pointed that out! But I'm glad you got it sorted out in the end anyway :D

13 minutes ago, maxmanium said:

Ope, fixed.

Happens :P

Sorry for bumping the thread with a possibly useless question, but in the case of compatibility patches, do I have to apply both the standalone fix and the patch? If so, is the load order supposed to be: -file D2SPFX19.wad sunlust.wad d2spfx-sunlust.wad OR -file sunlust.wad D2SPFX19.wad d2spfx-sunlust.wad?

Also, do these wads require a patch because they use a custom palette?

10 hours ago, rzh said:

Sorry for bumping the thread with a possibly useless question, but in the case of compatibility patches, do I have to apply both the standalone fix and the patch? If so, is the load order supposed to be: -file D2SPFX19.wad sunlust.wad d2spfx-sunlust.wad OR -file sunlust.wad D2SPFX19.wad d2spfx-sunlust.wad?

Also, do these wads require a patch because they use a custom palette?

The latter example is correct -- the third wad IS the patch for the custom palette, it's all included.

Whoops.

10 hours ago, rzh said:

Sorry for bumping the thread with a possibly useless question, but in the case of compatibility patches, do I have to apply both the standalone fix and the patch? If so, is the load order supposed to be: -file D2SPFX19.wad sunlust.wad d2spfx-sunlust.wad OR -file sunlust.wad D2SPFX19.wad d2spfx-sunlust.wad?

The standalone D1SPFX19 and D2SPFX19 WADs do not need to be loaded when running a PWAD that requires a compatibility patch. You can leave them automatically loaded if you use an autoload feature or batch launch file, but they won't have any effect as the PWADs in question will completely override them.

10 hours ago, rzh said:

Also, do these wads require a patch because they use a custom palette?

That's partially the reason. The sprite fixes are compatible with custom palettes that don't change the positions any of the main color ranges. The difference with the PWADs that require compatbility patches is that their custom palettes are remapped in such a manner that all of the existing art needs to be converted, even if the art has no explicit changes, as the color ranges in the palette no longer match what the original artwork has been mapped to. Since all of the original art is converted, the normal sprite fix WAD is completely overridden, hence the creation of the compatibility patch which runs with a higher priority than the PWAD.

8 minutes ago, maxmanium said:

The latter example is correct

This is not true. The latter example loads the normal sprite fixes, D2SPFX19.WAD, after Sunlust, and that will cause the issues that have been reported twice in this thread so far. I cannot stress this enough: The sprite fix WAD must be loaded with the lowest priority, or before any additional PWADs. There are no reasons to ever load the base sprite fixes after any PWADs. That must only be done with compatibility patches.

6 minutes ago, Revenant100 said:

This is not true. The latter example loads the normal sprite fixes, D2SPFX19.WAD, after Sunlust, and that will cause the issues that have been reported twice in this thread so far. I cannot stress this enough: The sprite fix WAD must be loaded with the lowest priority, or before any additional PWADs. There are no reasons to ever load the base sprite fixes after any PWADs. That must only be done with compatibility patches.

Ope, sorry. Big brain fart there.

There are 3 brown pixels present in the top right of HEADH0, near the cacodemon's fizzling horns. These pixels are not present in HEADG0 or HEADI0 so it seems like they are included in error. Are you aware of these?

I hadn't noticed those before. You're absolutely right, and an errant brown pixel appears at the bottom of the HEADH0 sprite as well.

I'll add it to the v2.0 fixes.

so whats next on the list

-snip-

Disregard.

Not sure if this counts as a mistake but...
Look at the offsets

I'm not sure what you're intending to show here. These are the appropriate offsets for the two brain frames.

my apologies, I saw the different offsets and my mind immediately thought "oh no its wrong!"

I don't know if someone has already mentioned this in the past, but lumps WILV07, WILV11, WILV17, WILV24, and WILV27 have an erroneous strip of red pixels to the far left of the graphics. I'm attaching fixed versions -- maybe they could be included in D1SPFX20?

I've also found some errors relating to the incorrect palette indices for STTNUM2, STTNUM5, STTNUM8, and M_ROUGH. I corrected these in-house in SLADE so they should work with custom palettes like ColdPal and not look out-of-place.

lumps.zip

There are a handful of known visual issues with the WILV map name graphic lumps in both the Doom and Doom 2 IWADs. However, they won't be addressed in these sprite fixes because they will end up conflicting with the other IWADs. The only way to avoid this is to create yet more variations of the sprite fix WADs, and that's introducing an unnecessarily confusing hassle for truly little gain. Granted, this only applies at the moment to the Doom 2 IWAD map name lumps being shared with Plutonia's and Evilution's lumps, but it's not worth the potential possible future conflict by including the Doom IWAD map name tweaks either. The primary focus of these fixes has always been on the gameplay sprites, so if some UI adjustments prove to be too troublesome to accommodate, they will be deliberately omitted as they're ultimately a low priority element.

Sorry to keep bumping this thread but I've found something else possibly of interest -- STFTL00 and STFTL10 are very similar but the latter has a y offset of -2 instead of -1 which is weird to see if you're taking a lot of damage from the left since the face just lowers by a pixel for no discernible reason. There may be other issues with the TL\TR graphics but I haven't checked.

Sorry to bump this thread but I'm having a rather strange bug: the sprite fixing project seems to not work with the most recent dev builds of prboom umapinfo. Or at least, some features of the sprite fixing project aren't working.

For instance, the SSG lingering blast frame is still present even with the sprite fix in use. 

I've tried this for several WADs, including the WAD-specific sprite fix patches (i.e. sunlust sprite fix as well as the generic sprite fix) and I'm not having much luck.

Any ideas? 

On 7/13/2021 at 1:09 PM, maxmanium said:

Sorry to keep bumping this thread but I've found something else possibly of interest -- STFTL00 and STFTL10 are very similar but the latter has a y offset of -2 instead of -1 which is weird to see if you're taking a lot of damage from the left since the face just lowers by a pixel for no discernible reason.

Pardon the lateness, but I did look into this, and it looks like an appropriate offset adjustment for consistency purposes. I've added it to v2.0.

8 hours ago, nobleflame said:

Sorry to bump this thread but I'm having a rather strange bug: the sprite fixing project seems to not work with the most recent dev builds of prboom umapinfo. Or at least, some features of the sprite fixing project aren't working.

For instance, the SSG lingering blast frame is still present even with the sprite fix in use. 

I've tried this for several WADs, including the WAD-specific sprite fix patches (i.e. sunlust sprite fix as well as the generic sprite fix) and I'm not having much luck.

It sounds like you're describing the DeHackEd fixes not taking effect. This is because the DeHackEd fixes are not contained within the sprite fix WADs themselves. They are provided as separate loose DEH files and thus must be also be individually loaded if you want to enable their effects. If you're using launch parameters, you need to add the "-deh" parameter to the launch options, like so:

prboom-plus.exe -file D2SPFX19.WAD -deh D2DEHFIX.DEH

Alternatively, if you're not using launch parameters, you can add "D2DEHFIX.DEH" to the port's DeHackEd autoload list so it automatically applies regardless of how you launch the game. It's located in the General menu in the options:

4 hours ago, Revenant100 said:

It sounds like you're describing the DeHackEd fixes not taking effect. This is because the DeHackEd fixes are not contained within the sprite fix WADs themselves. They are provided as separate loose DEH files and thus must be also be individually loaded if you want to enable their effects. If you're using launch parameters, you need to add the "-deh" parameter to the launch options, like so:

 

prboom-plus.exe -file D2SPFX19.WAD -deh D2DEHFIX.DEH

 

Alternatively, if you're not using launch parameters, you can add "D2DEHFIX.DEH" to the port's DeHackEd autoload list so it automatically applies regardless of how you launch the game. It's located in the General menu in the options:

Thanks for your advice! Really helpful. 

I'm using the PRBoom+ Launcher v0.1.2 and have the DEH files loaded as the last priority in the load order. 

I'll have a look at manually including the DEH files in the in-game menu and see if that works. 

On 7/21/2021 at 4:49 AM, Revenant100 said:

Pardon the lateness, but I did look into this, and it looks like an appropriate offset adjustment for consistency purposes. I've added it to v2.0.

About this change -- I think the appropriate change is actually to lower STFTL00 rather than raising STFTL10. I was messing with my custom status bar face sprite set and I noticed that STFTL00 is actually the odd one out, because it appears one pixel higher than the near-identical STFTR00. (unless this is already what you did, but I wouldn't know.)

You may also want to consider adjusting the x-offsets of STFTR00 and STFTR10 to -5, rather than -3. These two sprites have the same dimensions as their TL counterparts but have different offsets. From what I can tell it seems to fit in the little mugshot box much better this way (in terms of centering). Nevermind, it doesn't look too good coming from the ST sprites.

Sorry for the bump, but the download link on the OP does not appear to be working on my end.

11 hours ago, Rudolph said:

Sorry for the bump, but the download link on the OP does not appear to be working on my end.

Seems to be a problem with the link provided by the database, at least if you're not logged in. As an alternative, the legacy idgames page with download links is here: https://www.doomworld.com/idgames/graphics/sprfix19

Just pick any of the mirrors in the right column.

Hey, sorry for the bump. Just want to report something.

Lately I noticed there's this single orange pixel at the top of PLAT1 texture (the lift wall texture), it seems to me, this is a minor mistake take a look for yourself.

Screenshots: (sorry for the shitty resolution)

Not sure if this was mentioned, but I want to report that the imps TROOL0 sprite has missing horns here on its knees:

I'm happy to provide a new sprite if you like.

12 hours ago, lokbustam257 said:

Lately I noticed there's this single orange pixel at the top of PLAT1 texture (the lift wall texture), it seems to me, this is a minor mistake take a look for yourself.

I appreciate the report, and that is indeed a clear color discrepancy, but for now, patches and flats will remain outside of the scope of these fixes. The focus has always been on the sprites, as map textures would essentially have to be their own endeavor.

12 hours ago, Wavy said:

Not sure if this was mentioned, but I want to report that the imps TROOL0 sprite has missing horns here on its knees:

I'm happy to provide a new sprite if you like.

I recall this coming up before, and I don't remember why I hadn't done anything about it at the time, but since it's only a single frame, there are surrounding frames to serve as visual references, and it'd only take genuinely a few pixels to address, I'll go ahead and fix these missing spikes now. Thanks for the offer, but I'll be able to draw them in myself easily enough.

Would you be willing to do a palette re-indexing with respect to the unused rotation sprites? At least one of them -- POSSF8, and maybe more than that -- use index 255 whereas none of the iwad sprites use it since it was the initial transparency color id used when importing graphics lumps (or however that goes). I ask because with just the iwads index 255 is completely safe to replace, at least to my knowledge, so it kind of sucks that this index shows up for those users loading the sprite fixes. SLADE says the closest match is index 27.

8 hours ago, maxmanium said:

Would you be willing to do a palette re-indexing with respect to the unused rotation sprites? At least one of them -- POSSF8, and maybe more than that -- use index 255 whereas none of the iwad sprites use it since it was the initial transparency color id used when importing graphics lumps (or however that goes).

I did catch this back then when I was importing the art from Romero's sprite sheets, and I was 50/50 on replacing the couple uses of palette index 255. On one hand, it's a legitimate color in the palette that, at least purely from an art standpoint, id's artists could and did occasionally (perhaps inadvertently) use. From a technical standpoint, though, this color obviously didn't survive in a visible fashion in the final IWAD since it was just handled as transparent. As you mentioned, I did leave the 255 indexed color pixels intact in some of the imported Romero sprites, but in retrospect, having heavily scrutinized palette usage since then, it would be more consistent to change these cases to a regularly used color instead. Thanks for pointing it out; I'll be carrying out this change for v2.0 as well.

For reference, the affected sprites using color palette index 255 are POSSF7, POSSF8, and POSSH0 (I added that one in manually ages ago to fill in an erroneous transparent pixel).

Has it been mentioned that the SSG's iron sight only seems to be present in the first frame (SHT2A0) and the flash sprites, and is missing in the rest of them?

On 12/9/2021 at 2:36 AM, Alaux said:

Has it been mentioned that the SSG's iron sight only seems to be present in the first frame (SHT2A0) and the flash sprites, and is missing in the rest of them?

The sight is arguably present in the SSG's SHT2C0 frame as the pixels that made up the regular Shotgun's sight were not completely drawn out after the barrel was duplicated and then edited to make the SSG.

Nonetheless, any hint of the iron sights is nowhere to be found in the SSG's other unique frames. However, while it's not the biggest inconsistency you can find in the sprites, redrawing these missing sights is too big and too subjective of a change to fall under the umbrella of minor fixes.

I think I have asked this before, but is it possible to run this mod with dos?

17 hours ago, Eggman07 said:

I think I have asked this before, but is it possible to run this mod with dos?

Yes, the sprite fixes are fully compatible and functional in the original DOS executable. However, due to the limitations of how the DOS version handles sprites, you can't load the sprite fix WAD like any other PWAD. You need to merge the sprite fix graphics into the main IWAD. This was how graphics (and other types of) mods were commonly installed back then, and we even have a dedicated DOS tool for this purpose: DeuSF.

If you want to use the sprite fixes in DOS, you're going to be in a DOS environment anyway, so here's instructions on how to carry out the process there using Doom 2 as the example:

1. Put D2SPFX19.WAD in your main Doom 2 game directory
2. Download DeuTex/DeuSF 3.6
3. Extract these files to your Doom 2 directory
4. In DOS in your Doom 2 folder, run the program DeuSF with this parameter:
   deusf -merge D2SPFX20.WAD
5. Run Doom 2 as normal

The sprite fixes will now be in effect. The process for Doom 1 is essentially identical except with D1SPFX19.WAD instead. DeuSF also gives instructions on how to restore your IWAD if desired.