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

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

Recommended Posts

I have a question regarding compatibility patches:
For Wads with custom statusbars (Vanguard, Plutonia 2, Memento Mori 2) are they exactly like Ancient Aliens in that they need a compatability patch?
The only thing I noticed when quickly loading them up was that some numbers were not correctly displayed in the statusbar ("5" and "8" interestingly across all pwads). Is this normal glitched, non-compatible behaviour or am I doing something wrong and it should normally be compatible?
Thank you!

Share this post


Link to post

@Marvv7

Load D2SPFX.wad before the pwad:

DOOM2.wad > D2SPFX.wad > vanguard.wad

 

If you play a wad for which the project has a compatibility patch, load the patch after the wad:

DOOM2.wad > aaliens.wad > D2SPFX-aaliens.wad

Share this post


Link to post
1 hour ago, dmslr said:

@Marvv7

Load D2SPFX.wad before the pwad:

DOOM2.wad > D2SPFX.wad > vanguard.wad

 

If you play a wad for which the project has a compatibility patch, load the patch after the wad:

DOOM2.wad > aaliens.wad > D2SPFX-aaliens.wad

This fixes it, thank you!
I was under the assumption I would have to load it last, as @Revenant100 said to load it with lowest priority.
Interestingly, autoload (or "pre-loading") with PrBoom+ works, too, so that seems to also load it before the mappacks.

Share this post


Link to post

I'm guessing this is because the file loaded last in Doom will overwrite all that comes before it, assuming it and a previously loaded wad both replace the same asset, so this could be interpreted as the file you load first having the lowest priority. (Just putting this out there for clarification)

Share this post


Link to post

I really wish ports like Eternity and Woof! auto-loaded first rather than last. I can't keep this in autoload without overriding assets (e.g. Eternal Doom's imps) :(

Share this post


Link to post
1 hour ago, Doomkid said:

I'm guessing this is because the file loaded last in Doom will overwrite all that comes before it, assuming it and a previously loaded wad both replace the same asset, so this could be interpreted as the file you load first having the lowest priority. (Just putting this out there for clarification)

I see, I misunderstood "lowest priority" for "last to load"!

Share this post


Link to post

I've observed that all weapon flash states last 1 tic longer than the firing states in the states table. You'd think this would be wrong, but it seems like otherwise the flash ends before moving to the next state. This is most visible on the chaingun; if you edit the flash states to match the duration of the firing states (4 and 4) the flash sprites will flicker in and out. Perhaps the super shotgun's firing states should both be 4 tics in duration, rather than 4 and 3? I tested this in game and it seems to line up perfectly, whereas before, as I mentioned, there's a (very) brief period in which the flash states have finished despite the SSG not having changed states yet.

 

Edit: the same issue is actually visible in the flash states for the shotgun as well. This method doesn't have the overlapping flash states issue either.

Edited by maxmanium

Share this post


Link to post

The visual intention behind the timing of the SSG's muzzle flash appears to be that first frame should display relatively longer than the second frame, and the closest way to maintain this timing relation while also addressing the unintentional frame lingering is with the 4 and 3 tic durations for the two muzzle flash states. This happens to make the SSG's firing and muzzle flash timing match exactly that of the regular Shotgun's, so these fixed numbers do indeed have a clear and established precedent (since Doom 1, that is to say). While the fix does take a teeny bit of uniqueness away from the SSG, I feel it maintains the spirit of the original intentions better than simply reducing the first muzzle flash state's duration by 1 tic, thus making both states equal in duration.

 

And while it had no bearing on the reasoning that went behind this fix, the SSG in ZDoom also happened to independently reach the same 4,3 tic duration timing as its built-in solution to the SSG muzzle flash issue. Hence, there's already some consistency and long time familiarity for those who regularly use the ZDoom family of ports.

Share this post


Link to post
On 1/15/2021 at 8:47 AM, Eggman07 said:

Chex Quest sprite fixing project when?

You jest, but 2 or 3 years ago I threw together a notepad file on potential sprite fixes for other Doom engine games, Chex included. I don't have the file on hand, and don't remember where it is, but I think a conclusion was made, in that it would probably be impossible to decide what's an error and what isn't. I also came to the conclusion that no one actively plays Chex Quest, so it would be wasted effort.

Share this post


Link to post
1 hour ago, DELUXE said:

You jest, but 2 or 3 years ago I threw together a notepad file on potential sprite fixes for other Doom engine games, Chex included. I don't have the file on hand, and don't remember where it is, but I think a conclusion was made, in that it would probably be impossible to decide what's an error and what isn't. I also came to the conclusion that no one actively plays Chex Quest, so it would be wasted effort.

do you still have that notepad with the chex quest fixed sprites

Share this post


Link to post
On 1/16/2021 at 2:47 AM, Eggman07 said:

Chex Quest sprite fixing project when?

 

We need Hexen first. Had to look around for a widescreen fix since there isn't one, and GZDoom doesn't have native widescreen support for them yet.

Share this post


Link to post
1 hour ago, Eggman07 said:

Is it possible to run this mod with dos?

Yep, it is! You’ll just need to use DeHackEd to load the DEH and DEUSF to merge the sprites into the wad. If you have trouble just ask, I’ll be happy to help

Share this post


Link to post
5 hours ago, Doomkid said:

Yep, it is! You’ll just need to use DeHackEd to load the DEH and DEUSF to merge the sprites into the wad. If you have trouble just ask, I’ll be happy to help

 

Modifying the iwad can cause some issues, tho... the main one being the plasma rifle looking all fucked up if a wad replaces the firing graphics since they won't line up anymore.

Share this post


Link to post
On 6/2/2020 at 11:53 AM, Triple_sSs said:

Here's something I don't think was brought up before:
yTnsmnl.png
The STFST1 status bar faces are supposed to give Doomguy a bloody nose and ruffled hair, however I just noticed that the STFTL10, STFTR10, & STFKILL1 faces (bottom 3) don't have a bloody nose and I guess id forgot to add it to them. I think it'd be good if you added some red pixels to these faces so that the nosebleed is consistent in this set.

Was just thinking about this post from last year, and I thought I'd take a crack at adding the pixels for the nose bleed myself. Whatcha think?
BloodyNose.png.ad4eb7df25d3c339606d27e41de5d476.png

 

Feel free to use these in the mod if it works for you!

BloodyNose.zip

Share this post


Link to post
16 minutes ago, Triple_sSs said:

Was just thinking about this post from last year, and I thought I'd take a crack at adding the pixels for the nose bleed myself. Whatcha think?
BloodyNose.png.ad4eb7df25d3c339606d27e41de5d476.png

 

Feel free to use these in the mod if it works for you!

BloodyNose.zip

 

Thanks for this, I just included these changes for my own custom face sprite set.

Share this post


Link to post
On 1/24/2021 at 3:22 AM, maxmanium said:

 

Modifying the iwad can cause some issues, tho... the main one being the plasma rifle looking all fucked up if a wad replaces the firing graphics since they won't line up anymore.

You definitely shouldn’t modify the iwads ever, imo. DEUSF should be used to modify pwads by filling in the gaps. “deusf -app pwad.wad” is generally the correct usage, it won’t alter the iwad at all.

Share this post


Link to post
On 1/23/2021 at 4:56 PM, Devalaous said:

 

We need Hexen first. Had to look around for a widescreen fix since there isn't one, and GZDoom doesn't have native widescreen support for them yet.


I have been extending the Heretic and Hexen stuff, most of it is done. All that's left are the intermissons. Should be ready by March or April'ish :) If Graf plans to push an update around that time, then the images should be publicly available by then, too.

Share this post


Link to post

So this is another thing I picked up recently on the status bar face and tried making a fix.

It seems to me that the STFST0 & STFST1 Doomguy faces are rather inconsistent in regards to his "puffy eyes" where there's a little pink underneath. In those first two health statuses they'll blink in and out like so:

STFST01.gif.c31fb8f2bdb2985c9106f6506075ec6d.gifSTFST11.gif.3b1904ec0e69a4b8904c5f2657469868.gif

However I tried adjusting the pink pixels so they're only on the STFST1 faces, since they would seem to show exhaustion in his face if he was losing health, and IMHO it looks more appropriate & fitting.

STFST01(2).gif.199d67fc6fc27ea6f015144308019616.gifSTFST11(2).gif.489e171501519b7669502f1326b603d5.gif

Perhaps the puffy eyes were intended to be just for the second status, but was eventually forgotten about during production of the graphics? I'll admit this is something that could be a bit more subjective, but I wanted to at least bring it up for consideration.
Anyway, here's all the graphics I made for these statuses with the fixed puffy eyes, which also includes my previous bloody nose fix and a couple other minor fixes:

PuffyEyesFix.zip

Share this post


Link to post

You've made a compelling argument, but I can't rightly say that this is an inconsistency or oversight. The pink "puffiness" can also be seen in the undamaged STFTL00 and STFTR00 frames, and these eyes are unchanged in the next damaged state's equivalent STFTL10 and STFTR10 frames. And as I mentioned before, the status bar face is also one of the few sprite sets that we know received last minute touch ups as we can identify a handful of differences between the press release beta frames and the shareware release frames, so we know someone at id did take a second look at this artwork shortly before release.

 

And even if I were to attempt a fix, I don't see a clean way to objectively approach it. A number of pixels surrounding the eye are changed between the STFST01 and STFST11 frames, and I think those have a marked effect on the overall appearance. In particular, the altered pixels around the eyes in STFST11 seems intentional to give them a more squinty and intensely focused stare, appropriate for having taken some damage, but that's an element that was lost in your edit. Since this is much less concrete than something like the bloody nose, I'm inclined to leave the art as it is.

Share this post


Link to post

Thanks for the feedback. Yeah not surprised if you're not interested in adding that, but I guess I could just use the edit for myself.

Share this post


Link to post

Hello!  I recently became aware of this after reading some comments in decino's latest analysis video on YouTube.  However, when I click the Download File button on the first post of the thread to try and get the main v1.9 package, nothing happens.  I'm not sure if this is something for the site's tech support to look into, but is there any chance a ZIP could be made available on Google Drive as was done for some of the PWAD specific patches?

Share this post


Link to post
1 hour ago, Bytefyre said:

However, when I click the Download File button on the first post of the thread to try and get the main v1.9 package, nothing happens.  I'm not sure if this is something for the site's tech support to look into, but is there any chance a ZIP could be made available on Google Drive as was done for some of the PWAD specific patches?

For the sake of not having to manually maintain multiple download sources, please first try downloading the WAD from this page instead:

https://www.doomworld.com/idgames/graphics/sprfix19

 

There are multiple download mirrors to choose from on the right side of the page.

Share this post


Link to post

Romero hasn't posted any new Doom content since 2015, and there have been a handful of updates since then, so yes, this project will actively continue as long as additional fixes continue to be identified. The past several pages have discussed a few things that will end up in the eventual 2.0 release.

Share this post


Link to post
20 hours ago, Eggman07 said:

what is currently on the "to do" list?

The current pending task is to address the duplicate palette colors art issue first reported here. A pass on this problem was contributed by @maxmanium which will be an invaluable benchmark to check against, but I've intended to do a pass myself as a matter of redundancy.

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

×