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

I've just tested the newest GZDoom dev build with this change, and everything looks like the cat's pajamas. There are no longer any bouncing issues with any of the sprite clipping settings. Thank you, mysterious code committer!

If only this fix was also applied to 1.x.

[edit]

Derp, false alarm. It turned out that what I thought was a problem with GZDoom and sprite fixes was a result of another PWAD providing some replacements on its own, screwing things up. The version of the engine is older than the problem.

Hey, I've noticed a little oversight in the Spider Mastermind's sprites that I think this project could do something about.


While it's alive, its chaingun is large and black, with six barrels.

But then, after it dies, it becomes a thin, silver chaingun with only three barrels, matching its original model. Obviously, someone thought "the final boss deserves a beefier weapon" when converting photos to sprites, but missed a spot. I think it'd work if you maybe took the face of the chaingun from a frame where the spider's facing diagonally left or right and then pasted it over the death frames.

SiFi270 said:

Hey, I've noticed a little oversight in the Spider Mastermind's sprites that I think this project could do something about.

http://i.imgur.com/D8194FT.png
While it's alive, its chaingun is large and black, with six barrels.
http://i.imgur.com/sdCZhDz.png
But then, after it dies, it becomes a thin, silver chaingun with only three barrels, matching its original model. Obviously, someone thought "the final boss deserves a beefier weapon" when converting photos to sprites, but missed a spot. I think it'd work if you maybe took the face of the chaingun from a frame where the spider's facing diagonally left or right and then pasted it over the death frames.

I'd like to dismiss this because you see the death animation of the Spider Mastermind involves a lot of explosions and one of those blew up it's chaingun to pieces.

Yeah, I don't think it's really that noticeable anyway... good catch though.

Indeed, that's a good catch. While I would say your explanation for why this tinier barrel appears is accurate, I don't think it necessarily constitutes an error that warrants a fix, at least within the purview of this project. To remain faithful to id's intentions, original art edits have been kept to the bare minimum, and as of right now, the most involved of such is Da Werecat's modified MISFA0 frame. However, that was an extenuating circumstance as this is a large and conspicuous error, the only other way to address it being a DeHackEd patch which, apart from not being a sprite fix, would be prone to further mod incompatibilities and potential demo desyncs.

Prior to that frame's implementation, the most elaborate original art edit was and still is having removed the Cyberdemon's feet from the Barrel explosion frames, obviously quite a magnitude smaller. Replacing the Mastermind's corpse chaingun, while by no means a big change, is a considerable enough art edit that it wouldn't fit within the project's scope.

Any sprites you need help with ? I have a lot of free time and wanted to contribute to your project :)

Thank you for the offer, but there currently aren't any remaining sprite work tasks remaining for these Doom fixes. I will be seeking help with creating widescreen-friendly weapon sprites for the upcoming Hexen fixes, but that's a separate project that I'm still organizing.

There is one more thing that could be considered for another update in case you are planning one:

As it stands now, all HUD weapon sprites have extensions below the statusbar border - except for the Chainsaw, Super Shotgun and Plasma Rifle. Maybe those could be added as well, just for completion purposes (and also to eventually enable mods to take full advantage of the possibility to change weapon offsets)? 

I wouldn't be against extending the remaining weapon sprites as that would add consistency without affecting the existing visuals whatsoever, but unless there's another new asset dump from Romero which reveals that id did indeed originally draw those extended portions of the weapon graphics, I don't think this is a likely possibility. All of the current weapon extensions come from official art. It would take a lot of effort to create the remaining missing portions from scratch in a manner that is convincingly compatible with the rest, especially for something that is effectively unseen by design. I would rather any art efforts like that go to extending Hexen's weapon sprites to make them widescreen-friendly as those portions, or lack thereof, are actually plainly visible at all times.

I wasn't aware these extended graphics were part of graphics published by id. In that case, I guess it wouldn't be a good idea to ask anybody to create the "missing" parts. Unless the graphics are really good and look totally authentic, maybe. The thing is also that at least the SSG has quite a lot of frames (other than the Chainsaw and Plasmagun which just have very few), so realistically I guess it won't happen. Especially considering that under normal circumstances, one would never see these parts.

Happy Five of May! Today, I'm making two small updates to the sprite fixes. If you're just using the normal Doom 1/2 sprite fixes, there's nothing new to download right now. The following only pertain to the PWAD compatibility patches.

• All of the PWAD compatibility patches and the Full Modder's Resource WAD have been updated to address the unintended IWAD header, hence avoiding the IWAD lock problem in SLADE and loading issues in Doom Retro. The main Doom 1/2 sprite fixing WADs are not yet updated as that will require an upload and approval to the idgames submission (will be done soon).
   
• I have added a new section to the first post: Work-In-Progress PWAD Compatibility Patches. This will contain sprite fix patches for PWADs that have yet to reach a final release state but currently have public alpha or beta versions available. Due to the in-progress nature of these PWADs, you may have to return here from time to time to download updated versions of the corresponding sprite fixes. Note the dates in the sprite fix WAD filenames to determine if the version you have is up-to-date.
  
  So far, I've released WIP sprite fixes for Dimension of the Boomed and Mayhem 2016. Download links below:
   

  Dimension of the Boomed compatibility patch (load the sprite fixes after DOTB_A01.wad):

  • D2SPFX-DOTB-20170317.zip (2.49 MB)

  
  Mayhem 2016 compatibility patch (load the sprite fixes after mayhem16_semifinal1i.wad):

  • D2SPFX-mayhem2016-20161210.zip (1.52 MB)

   

As before, if there are any other PWADs out there that make a substantial use of a custom color palette such that they warrant their own sprite fix compatibility patches, please do inform me of them and I'll give them a look.

I had noticed the iwad flag issue in your Heretic and Hexen fixes as well. Maybe you can update those as well while you are at it, just for completion purposes. 

3 hours ago, Revenant100 said:

the IWAD lock problem in SLADE

It's just a CVAR away from being unlocked. Think of it as a child-proof safety to prevent newbies from destroying their IWADs when they start learning modding. :)

Well actually, there is little reason to edit these fixes by anyone. You can extract stuff if you like, still.

On 5/5/2017 at 11:24 AM, NightFright said:

I had noticed the iwad flag issue in your Heretic and Hexen fixes as well.

Thank you, I have made the header fix to my internal build of the Heretic sprite fixes. However, it's not ready to release yet as it's still in a work-in-progress state having received a portion of the upcoming Hexen fixes. The next release will probably be alongside that initial Hexen version.
 

8 hours ago, Averagewalrus23.9 said:

Do you have any intent to add the exploding head from the console ports?

While it would be a great addition, the exploding status bar face is unfortunately not natively supported in any PC version of the engine. The function would have to be coded in, so that's outside the realm of what these fixes can achieve. Advanced source ports like GZDoom can easily implement the feature, of course, but then that just becomes an individual mod release particular to those ports.

When working on my own project, I made a little discovery. MISFA0 is actually not so faithful to the original sprite; there's a big horizontal beam of light that the original sprite didn't have. IIRC, Werecat said that he made it for BTSX, and it just so happened to be useful for this project. However, upon submission, it seems he forgot that he took a big liberty with it, and none of us seem to have caught it until now.

Aside from removing the beam of light, I've also tweaked the edges between the launcher itself and the burst of fire behind it to closer resemble the original sprite.

I've grown dissatisfied with my widescreen extension of SHT2E0. It's certainly an improvement on the one before it (no offense to whoever made it), but I feel like my first version wasn't as consistent as I'd like it to be with the rest of the sprite. Here's my updated version:

It's worth noting that this is one pixel wider than the last revision, so take that into account when importing and aligning it.

Lastly, a few suggestions:

1. PSTRA0, while aligned better than it was in the IWAD, still doesn't seem quite right. It's an entirely symmetrical sprite, no reason not to center it. Same goes with MEDIA0, should be centered.

2. The rocket launcher should be moved one pixel to the left, IMO. I know that the idle frame is an odd number of pixels wide, thus cannot be perfectly centered, and that id generally preferred to bias it to the right in these cases, but considering that MISGB0 is an even number of pixels wide, perhaps we should opt to bias MISGA0 to the left instead so that MISGB0 is perfectly centered.

EDIT: Alternately, and I think this may be a better solution, leave MISGA0 where it already is, but still move everything else to the left by one. Yes, the relative alignment is now different, but it's not as big of a concern given its symmetrical nature.

The BFG edition IWADs are crap and should not be used, but perhaps it's worth considering applying some key sprite fixes there too?

3. Include STIMA0 (and if suggestion 1 is rejected, still include MEDIA0)

4. Include any remaining unmodified SS trooper sprites (this one is iffy, as it's a whole sprite set, but id did break it in an official IWAD, did they not?)

6 minutes ago, Blastfrog said:

However, upon submission, it seems he forgot that he took a big liberty with it, and none of us seem to have caught it until now.

I specifically said that the edit might be too much for the project.

And I will also point out that the hole isn't even exposed on the GA frame, for which the original FA frame was made. You only see a glimmer of light shining through it, but not the hole itself.

Which is why I didn't really care.

36 minutes ago, Da Werecat said:

I specifically said that the edit might be too much for the project.

I thought you meant that in a more general sense, as in "this is such a major change in general that it might be too much". I hadn't (though probably should have) considered that you were specifically referring to the bright light.

36 minutes ago, Da Werecat said:

And I will also point out that the hole isn't even exposed on the GA frame, for which the original FA frame was made. You only see a glimmer of light shining through it, but not the hole itself.

In turn, I'll point out that GunFlash is called right on the first tic of the firing state. The flash state always draws on top of the normal sprite, so just because MISGB0 has a hole doesn't mean that it was necessarily meant to be visible. It's less subjective to leave the hole covered.

5 minutes ago, Blastfrog said:

I thought you meant that in a more general sense, as in "this is such a major change in general that it might be too much". I hadn't (though probably should have) considered that you were specifically referring to the bright light.

I meant everything at once.

7 minutes ago, Blastfrog said:

The flash state always draws on top of the normal sprite, so just because MISGB0 has a hole doesn't mean that it was necessarily meant to be visible.

Not always. It is visible at the end of the sequence.

18 minutes ago, Da Werecat said:

Not always. It is visible at the end of the sequence.

I probably should have been clearer. I meant "not necessarily meant to be visible at all times that MISGB0 is used as the underlying frame". Yes, it was absolutely meant to be visible when MISFB0 through MISFD0 was there, and yes, MISFA0 was a screwup. Regardless, the end result in id's version is still that the hole is covered when MISFA0 was there.

It kinda makes sense too, the holes are obviously some kind of exhaust port, perhaps they haven't fully opened when the fire first pops out.

4 minutes ago, Blastfrog said:

Regardless, the end result in id's version is still that the hole is covered when MISFA0 was there.

Sure, because it was supposed to be used on top of GA, where the hole is still covered.

5 hours ago, Da Werecat said:

Sure, because it was supposed to be used on top of GA, where the hole is still covered.

Okay, but we do not and cannot know for certain whether id still would've had the hole covered if they made the FA sprite for GB instead. Regardless of their intent, I feel that this is one of those cases where the error sorta became the defacto "canon" appearance. Given that, the safer option is to just fix what we know for certain is an error, which is the size of the launcher's trim.

Not to mention, I simply prefer it this way, it means that the animation has more "steps" to it rather than having the exhaust ports open immediately and thus seems a bit more "lively". I dunno, heh.

Lastly, I said that bit about the error becoming "defacto". I don't think this would apply to the lost soul, as it was never their intent to have it flash or otherwise change so radically between frames (see my theory about the 3 versions of the lost soul in my major sprite fix thread). Even though MISFA0 does not correspond to MISGB0, it was unambiguously id's intention was that the exhaust was not open in MISFA0.

The funny thing is: the majority of players never even knew the animation was so screwed up, and they won't know something was fixed without reading the changelog. Whether there's a small "lens flare" around the hole or not is something no one will ever notice at the animation's speed.

32 minutes ago, Blastfrog said:

Even though MISFA0 does not correspond to MISGB0, it was unambiguously id's intention was that the exhaust was not open in MISFA0.

Except you can see the light coming from it. It's not just the light from the lower hole. But the perspective makes it so that the hole itself is hidden behind the... round thing.

32 minutes ago, Blastfrog said:

I don't think this would apply to the lost soul, as it was never their intent to have it flash or otherwise change so radically between frames (see my theory about the 3 versions of the lost soul in my major sprite fix thread).

My position: screw the intent, what matters is whether it works or not.

Not for this project, obviously, but for anything that would go beyond it.

We could sit here all day and argue about what is or isn't correct, but for the purposes of this project, we should not take such liberties so lightly. I still think my revised version is more appropriate for this WAD.

I'm not gonna argue with that.

Greetings again, all! After considering the current set of changes, I've decided that the next release will warrant a version increment to v1.9. There typically hasn't been any need for a rush with new versions as being patient meant more opportunities for new developments to occur that could lead to additional fixes, but the main reason I've been waiting nowadays is in case Romero decides to bedazzle us with any new Doom source asset releases. However, I've learned that Romero is no longer as eager to share such content with the public now due to Zenimax, so we're unfortunately not likely to see anything like his asset dumps of previous years any time again in the near future. Thus, there's no point in dilly dallying. I just need to finish up some closing tasks, as detailed below. But first, the suggestions.

On 5/16/2017 at 2:29 AM, Blastfrog said:

When working on my own project, I made a little discovery. MISFA0 is actually not so faithful to the original sprite; there's a big horizontal beam of light that the original sprite didn't have. IIRC, Werecat said that he made it for BTSX, and it just so happened to be useful for this project. However, upon submission, it seems he forgot that he took a big liberty with it, and none of us seem to have caught it until now.

 

Aside from removing the beam of light, I've also tweaked the edges between the launcher itself and the burst of fire behind it to closer resemble the original sprite.

 

Because of the absolute necessity of this fix requiring a (relatively) significant art modification, it's fair to afford it a degree of artistic liberty. As a choice is being presented, though, I figure I will go with your rendition over Da Werecat's, but that's not to say either one is expressly right or wrong.

Quote

I've grown dissatisfied with my widescreen extension of SHT2E0. It's certainly an improvement on the one before it (no offense to whoever made it), but I feel like my first version wasn't as consistent as I'd like it to be with the rest of the sprite. Here's my updated version:

 

 

Thanks again. I've implemented this.

Quote

PSTRA0, while aligned better than it was in the IWAD, still doesn't seem quite right. It's an entirely symmetrical sprite, no reason not to center it. Same goes with MEDIA0, should be centered.

Way back when, I had considered re-centering all of the decoration sprites, but in the end, this posed too many issues. While some sprites are perfectly symmetrical and wouldn't be affected significantly by minor offset adjustments, there are other non-symmetrical decorations that still have a "center", such as the burning barrel. Readjusting these have a great and noticeable visual impact, especially in cases where the thing placement is very precise (burning barrels placed in floors to represent open fires).
 

Additionally, while examining Romero's asset dumps, it's clear that id's artists had several opportunities to center the decoration sprites themselves, namely when drawing the sprites, again after initially importing them, and finally when manually adjusting them afterwards as in the case of the Medkit. However, they chose not to. Hence, there's no indication this was an oversight on their part that necessitates action.
 

Because of this, the only decoration sprites I ended up centering were ones that posed clear inconsistencies relative to related sprites, such as the Red and Yellow Keys compared to the perfectly centered Blue Key.

Quote

The rocket launcher should be moved one pixel to the left, IMO. I know that the idle frame is an odd number of pixels wide, thus cannot be perfectly centered, and that id generally preferred to bias it to the right in these cases, but considering that MISGB0 is an even number of pixels wide, perhaps we should opt to bias MISGA0 to the left instead so that MISGB0 is perfectly centered.

EDIT: Alternately, and I think this may be a better solution, leave MISGA0 where it already is, but still move everything else to the left by one. Yes, the relative alignment is now different, but it's not as big of a concern given its symmetrical nature.

I have opted to center the first person weapon sprites based on the idle frames, relatively moving all other frames accordingly, as that's primarily the phase when players would be aiming the weapon (and how it's been identified as an error). Readjusting the offsets of the individual weapon states independent of the others is farther than I'd like to go, and in the case of MISFB0, it's currently only one pixel off from having pixel perfect centering. This offset is simply a quirk that was there originally (albeit slightly worse before I centered it) that's managed to survive the associated fix.
 

Quote

The BFG edition IWADs are crap and should not be used, but perhaps it's worth considering applying some key sprite fixes there too?

If I were to include lumps that undo the BFG Edition changes, I would prefer to either do it fully or not at all, but the former is not possible without causing conflicts. Restoring the original Stimpak/Medkit/Berserk sprites, Wolfenstein SS sprites, and even the rest of the Wolf 3D wall patches would be possible, but I could not restore the MAP31 or MAP32 intermission screen map names without creating a conflict with the Final Doom IWADs. There are also some other graphical inconsistencies and non-sprite stuff that can't be accommodated for either. This release already does pretty much what you suggest, so there's still something out there that players stuck with the BFG Edition can use.

Anywho, as far as additional fixes that will appear in v1.9, something I've been very closely scrutinizing lately is the effect a sprite's dimensions has on its scaling during animations. I've already identified some peculiar animation jittering which was addressed by introducing some padding to the sprites. In truth, this "jittering" can be narrowed down to very specific circumstances, but the amount of padding required to mitigate all possible instances would be unreasonable.
 

For now, I'm limiting the scope of further jittering fixes to the most visually obvious and unavoidable instances, and there's no place less obvious and more unavoidable than what you have smack dab in your face. Pictures illustrate this issue more succinctly than I can describe, so here's a demonstration of what the new fixes look like so far (spoiler tagged as the images are fairly big):

This type of jittering occurs uniquely in different ports and even differing resolutions, so I still have more testing to perform.

I've hit a stopping point with my own testing, so now I'd like to reach out to anyone willing to do a quick test of the new sprite fix WAD to offer feedback. First, here's a summary of the updates being made:

• v1.9 is being released right now as a Beta 1 test version. See the main post or just download it right here: (Outdated, see original post)
  
  The current v1.9 changelog may be viewed here: (Outdated, see original post)
  
  While this is a beta, this is essentially what the final release will encompass barring any changes warranted by feedback (see below).
• A new WIP PWAD compatibility patch for Mayhem 2017 has been released. See the main post for the download link.
   
• The rest of the PWAD compatibility patches and the Full Modder's Resource WAD have all been updated to v1.9. Again, see the main post for those download links.

The big new feature of this version is the introduction of jitter fixes for the first person weapon sprites. While such jittering doesn't take place in several cases (the vanilla exe and Chocolate Doom, to name the obvious), it's a frequent occurrence in source ports that require the sprites to be scaled in some fashion. If you've played a source port in a high resolution above 320x200 and fired the Super Shotgun or Rocket Launcher, then chances are you've seen this jittering happen right in front of your nose. If you hadn't seen it, chances are you probably just weren't noticing it. (But now you probably will!)

This is where the desire for more testing comes in. Unfortunately, I've found there isn't one magic bullet fix for the issue. Different ports, different resolutions, and even the different renderers all come with their own sprite scaling quirks that these fixes can't all mitigate. If you use these sprite fixes and would like to help out here, simply download and run the v1.9 Beta 1 test in your preferred setup, fire the Super Shotgun and Rocket Launcher, and see if there's any visual jittering on the weapon sprites. You may want to run these test cases without the sprite fix WAD to see if there's even a net benefit taking place at all for you.

If you aren't familiar with what the jittering looks like, here are the demonstration gifs I made in PrBoom-Plus running at 1920x1080:

(This is by far from the worst case scenario. This jittering can manifest much more clearly in other ports and resolutions.)

Whether or not you find the jittering is fixed for you, stating what your choice of source port, resolution, and renderer will still give me useful information to work from. At the very least, I can aim to address the matter in the most commonly used ports/resolutions/renderer, but I'd have to know what those are! While the fix as of the v1.9 Beta 1 test works in most of my test cases, there's still more fiddling I can attempt in case there are still some other unaccounted for scenarios (adjusting the sprite offsets, changing the sprite dimensions, even vs. odd dimensions, etc).

Aside from that specific matter, I suppose this is also just a general test for v1.9 in general. However, I don't think any of the new changes are extraordinary enough to create any conundrums at this stage. That's the hope for now, at least.

Hey! New poster here. :P

I really appreciate all the work you've done here, this has become one of my "must-have" WADs and I always have it on autoload. The massive amount of time you've put into correcting all sorts of issues is astonishing, and I congratulate you for doing so.

Seeing such a great project really inspires me to contribute something, even if it is minor. So... here goes.

One thing I've always noticed on the skill select menu is that the comma on HNTR's graphic has the bottom row of pixels cut off. This is a very simple fix, especially since the apostrophe character visible in ITYTD's graphic is identical.

As such, I quickly threw this together. I basically just copy-pasted the apostrophe into place over the comma and saved it. Like I said, it's nothing special, but why not post it anyway while I have it?

Thanks again as always, looking forward to a proper 1.9 release.

On 7/20/2017 at 5:12 PM, LemonWolf3322 said:

One thing I've always noticed on the skill select menu is that the comma on HNTR's graphic has the bottom row of pixels cut off. This is a very simple fix, especially since the apostrophe character visible in ITYTD's graphic is identical.

 

Thanks for the suggestion! This looks like an appropriate fix, and after some cursory testing and forethought, I can't think of any potential conflicts that including this graphic could cause. I'll include it with the final v1.9 release, also updating all of the other releases here accordingly when it's time.

Speaking of, I've not encountered any remaining issues while testing, so barring any ultra last minute feedback, the final v1.9 will be released soon.