Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Revenant100

Doom 2 Minor Sprite Fixing Project - v1.9 Release (updated 1/27/18)

Recommended Posts

7 minutes ago, Gustavo6046 said:

@maxmanium you forgot to change the complevel value. Or did you intentionally keep the original one so as to demonstrate only the relevant changes? Just wondering.

 

Ope, fixed.

Share this post


Link to post
Posted (edited)
38 minutes ago, omalefico32x said:

not awnsering your question but eviternity uses complevel 11 (mbf compatible)

 

25 minutes ago, maxmanium said:

 

You can't load wads like that, they all have to go after -file. Also, yeah, Eviternity is -complevel 11. Use this:

 

prboom-plus.exe -file D2SPFX19.WAD Eviternity.wad -deh D2DEHFIX.DEH -complevel 11

Thanks both. All sorted now.

 

Share this post


Link to post
Posted (edited)
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

Share this post


Link to post

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?

Share this post


Link to post
Posted (edited)
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.

Edited by maxmanium

Share this post


Link to post
Posted (edited)
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.

Edited by Revenant100

Share this post


Link to post
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.

Share this post


Link to post

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?

cacopixels.png

Share this post


Link to post

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.

 

xcFyHyH.png

 

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

 

Share this post


Link to post
Posted (edited)

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

romero1.png

romero2.png

Share this post


Link to post

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

 

K3RdNLD.gif

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post

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? 

Share this post


Link to post
Posted (edited)
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:

16NjtkS.png

Share this post


Link to post
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:

16NjtkS.png

 

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. 

Share this post


Link to post
Posted (edited)
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.

Edited by maxmanium

Share this post


Link to post

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

Share this post


Link to post
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.

Share this post


Link to post

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)

Spoiler


Screenshot_13.png.810b2d247552aafdc9eb41ac82b10388.png

Screenshot_14.png.012381b1bc8e57a6d911bd643b342b24.png


 

 

Share this post


Link to post

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

TROOL0.png.08bfa3e8f86f92ea8ca884804117fc4b.png

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

Share this post


Link to post
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:

TROOL0.png.08bfa3e8f86f92ea8ca884804117fc4b.png

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.

Share this post


Link to post

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.

Share this post


Link to post
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).

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×