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

[Alaux]

I've just discovered something that might be relevant for this project:

 

It seems that Doom renders first person (weapon) sprites off by one pixel to the right, independently of the sprite's offsets if any:

Spoiler

In this example, the red line and the blue dot are perfectly centered, at least horizontally, but the pistol's iron sight is off.

 

I thought that the issue was that this pistol frame has an uneven width, so I tried with the Super Shotgun from my own sprite fix (which uses the same centered weapon sprites as D2SPFX19), but the same issue was visible

 

I then thought that the problem could've been the port I was testing this on (Nugget Doom), so I went on to Chocolate Doom to find the exact same thing again (this time without any PWADs loaded, since the pistol's sight is centered anyways)

 

Lastly, another test on Nugget Doom with a 320x200 graphic, with vertical offset but no horizontal offset; the purple line drawn on top of the TITLEPIC is on the middle of the sprite itself, but you might notice that said line is not centered relative to the actually-centered green dot, and on top of that, there's a row of pixels to the far left that is not obstructed by the sprite as you would expect

 

Based on this evidence, I believe that for SPFX's weapon sprites to actually be centered in-game, they should be offset one pixel to the left relative to their current offsets.

Edited January 9, 2022 by Alaux

[Revenant100]

23 hours ago, Alaux said:

Based on this evidence, I believe that for SPFX's weapon sprites to actually be centered in-game, they should be offset one pixel to the left relative to their current offsets.

I've just tested numerous versions and ports, both in DOS and out, and I can confirm your findings. However, there's a catch: Some source ports have already fixed this centering issue, namely the ZDoom family. Hence, I cannot adjust the centering of the weapon sprites from the graphics side to account for this erroneous pixel offset without introducing the same erroneous offset into engines that also fixed this problem from the code level. It's an unavoidable conflict.

 

For this reason, I'm going to have to pass on this change. This issue should come down to a code fix on the engine side, and from my testing, a majority of source ports do exhibit this off-center behavior.

Edited January 10, 2022 by Revenant100

[Gez]

It's not very important with Doom's aggressive autoaim anyway.

Edited January 9, 2022 by Gez

[Quill]

I found some flaws in the Pinky Sprites.

In some frames, the teeth are gray instead of yellow.

SARGB4B6

SARGD4D6

SARGE6

And a stray gray pixel in SARGF6.

Edited January 16, 2022 by dotQLL

[Revenant100]

7 hours ago, dotQLL said:

I found some flaws in the Pinky Sprites.

In some frames, the teeth are gray instead of yellow.

Thanks for the report! It led to more than I was expecting. Comparing the final sprites to the Demon's alpha sprites when it still had white teeth, the error here is easy enough to pinpoint as being pixels they missed during the recoloring process. I fixed the four frames you've mentioned, and I was compelled to scrutinize the alpha Demon sprites further to work out the actual color palette translation used to recolor the teeth. This ended up revealing overlooked gray teeth pixels in 9 other frames (SARGA2C8, SARGC2A8, SARGE2, SARGE8, SARGF2, SARGF8, SARGG3, SARGG7, and SARGI0) which I've gone ahead and accurately recolored with my palette translation as well.

[Revenant100]

Greetings, everybody! Since it's been a good while since the last release, I'll be doing an early beta release of v2.0 right now.

 

The v2.0 Beta 1 release (1/18/22) of the Minor Sprite Fixing Project may be downloaded in the main post or here:

• (Outdated, see original post)

 

To be clear, there's nothing being held back here prior to the final v2.0 release. This Beta 1 version is fully up to date and includes all fixes discussed up to this point. However, since I plan to do the formal v2.0 release on this project's upcoming 10th anniversary at the end of this year, I figured I may as well refrain from holding it back any longer for everyone's perusal and enjoyment. And as always, this is still very much and will always be a work-in-progress, and I'm open to feedback and potential ideas for further changes. Note that the compatibility patches have not been updated yet.

 

Trimmed summary of the v2.0 Beta 1 changes:

 

v2.0 Beta 1 (1/18/22)

General
- [2.0] Restored inadvertently remapped duplicate palette colors in affected sprites. Fixes visual inconsistencies when using very particular custom color palettes.

 

Zombieman
- [2.0] Replaced few instances of color palette index 255 to more standard color for consistency.

 

Imp
- [2.0] Added missing knee spikes in 1 death frame.

 

Demon
- [2.0] Fixed gray pixels in teeth in 13 frames. Teeth now have correct consistency with the alpha-to-retail color palette translation.

 

Cacodemon
- [2.0] Removed 3 erroneous brown pixels in 1 death frame.

 

Revenant
- [2.0] Restored missile launcher's missing column of pixels in 1 punching frame.

 

Mancubus
- [2.0] Further refined sprite offsets during walking frames.

 

Other Things
- [2.0] Fixed brown pixels and pink pixel in Nightmare! difficulty text. By JCST.
- [2.0] Status Bar Face: Adjusted sprite offsets during left and right looking pain frames.
- [2.0] Status Bar Face: Added missing bloody nose in 3 frames.

 

As you might expect, the updates here are minor. The biggest new fix is the painstaking complete restoration of the duplicate palette colors in about 200 sprites. This was not actually a Doom problem, mind you. This was a problem that was inadvertently introduced by previous versions of this sprite fix WAD. However, you've likely never noticed the issue before as roughly 99.99% of all released WADs in existence would never exhibit this problem. Nonetheless, an extremely small subset of WADs that implemented custom color palettes in a very particular manner did reveal this error, but the error is no more and visual compatibility is assured! Here are some examples of the fix in action:

 

And just for funsies, example of the Imp knee spike fix:

Edited July 17, 2022 by Revenant100

[NightFright]

Based on that changelog, I assume there are once again no new assets which would require adjustments of my spritefix brightmaps, correct?

[maxmanium]

Glad to see the palette indexing has been fixed. Was my work of any help? :)

[Revenant100]

13 hours ago, NightFright said:

Based on that changelog, I assume there are once again no new assets which would require adjustments of my spritefix brightmaps, correct?

That's correct. The latest compatible version of the brightmaps doesn't need any modifications to accommodate this update.

 

11 hours ago, maxmanium said:

Glad to see the palette indexing has been fixed. Was my work of any help? :)

Yes, indeedy. I independently performed my own complete pass on the duplicate palette colors, and I compared these results to your versions. Seeing as this is a thoroughly esoteric and intricate task that can't be automated, it was of great help and reassurance to essentially have a second pair of eyes look over everything.

Edited January 20, 2022 by Revenant100

[Alaux]

Regarding the issue with duplicate colors, I wanted to know if the list of sprites affected, found at the end of this post, is complete and does list all the affected (therefore now fixed) sprites. I kinda need to know exactly which sprites were changed between 1.9 and 2.0 Beta 1, and I believe I've got everything (thanks to the changelog) except the sprites with corrected colors.

Edited January 22, 2022 by Alaux

[Revenant100]

8 hours ago, Alaux said:

 I kinda need to know exactly which sprites were changed between 1.9 and 2.0 Beta 1

One way you could do this is to use SLADE's "Remove Entries Duplicated from IWAD" feature. It's under Archive/Maintenance. To use it for this purpose, load up D2SPFX20_FULL_beta1.wad, set the previous D2SPFX19_FULL.WAD as your current base resource, and then run the option. The remaining lumps will be all of the sprites modified between the two versions. Here's the list I generated using this feature:

Spoiler

sttnum2
sttnum5
sttnum8
sttprcnt
stftl00
stftl10
stftr10
stfkill1
stftr30
stftr40
stfgod0
m_rough
m_nmare
chgfa0
chgfb0
manfa8a2
manfa7a3
manfa6a4
manfb8b2
manfb7b3
manfb6b4
misfa0
misfb0
misfc0
misla6a4
sht2e0
sht2i0
bfgfa0
sarga2c8
sargb4d6
sargc2a8
sargd4b6
sarge2
sarge6
sarge8
sargf1
sargf2
sargf6
sargf8
sargg3
sargg7
sargi0
trooa1
trooa2c8
troob1
troob2d8
trooc1
trooc2a8
trood2b8
trooe1
trooe2
trooe8
troof1
troof8
troog2
troog8
trool0
playu0
playv0
playw0
possf7
possf8
possh0
possn0
posso0
skulb8b2
skulc8c2
skulc6c4
skuld8d2
skuld6d4
skule8e2
skule7e3
skule6e4
heada2a8
heada3a7
heada4a6
headb2b8
headc2c8
headd2d8
headb3b7
headc3c7
headd3d7
headb4b6
headc4c6
headd4d6
heade2e8
headf2f8
heade3e7
headf3f7
heade4e6
headf4f6
headh0
paina2a8
painb2b8
painc2c8
paind2d8
paine2e8
paine3e7
painf2f8
painf3f7
paing2g8
bspia1d1
bspia2d8
bspia3d7
bspia4d6
bspia5d5
bspib1e1
bspib2e8
bspib4e6
bspib5e5
bspic1f1
bspic2f8
bspic3f7
bspic4f6
bspic5f5
bspid2a8
bspid3a7
bspid4a6
bspie2b8
bspie3b7
bspie4b6
bspif3c7
bspif4c6
bspig2g8
bspig3g7
bspig4g6
bspih1
bspih2h8
bspih3h7
bspih4h6
bspii6
bspii7
bspil0
skela5d5
skela6d4
skela8d2
skelb3e7
skelb4e6
skelb8e2
skelc1f1
skelc2f8
skelc3f7
skelc4f6
skelc6f4
skelc7f3
skelc8f2
skeli6
skeli7
fatta1
fattc3f7
fattc4f6
fattd1
fatth2h8
fatth3h7
fatth4h6
fatti4i6
fattj4
fattj6
sswvn0
cybra3
cybra6
cybrb2
cybrg1
cybrg3
cybrh0
cybri0
cybrj0
cybrk0
cybrm0
cybrn0
cybro0
cybrp0
spida1d1
spida2d8
spida3d7
spida4d6
spida5d5
spidb1e1
spidb2e8
spidb3e7
spidb4e6
spidb5e5
spidc1f1
spidc2f8
spidc3f7
spidc4f6
spidc5f5
spidd2a8
spidd3a7
spidd4a6
spide2b8
spide3b7
spide4b6
spidf2c8
spidf3c7
spidf4c6
spidg2g8
spidg3g7
spidg4g6
spidg5
spidh2h8
spidh3h7
spidh4h6
spidh5
spidn0
spido0
spidp0
spidq0
pol5a0
bexpe0
bon1a0
bon1b0
pol6a0
gor1a0
gor1b0
gor1c0
gor2a0
gor3a0
gor4a0
gor5a0
smrtc0
hdb1a0
hdb2a0
hdb3a0
hdb4a0
hdb5a0
hdb6a0

Note this includes everything updated for the v2.0 Beta 1 release, not just the sprites that received the duplicate color palette fix.

Edited January 22, 2022 by Revenant100

[Alaux]

3 hours ago, Revenant100 said:

One way you could do this is to use SLADE's "Remove Entries Duplicated from IWAD" feature. Here's the list I generated using this feature.

That's actually a very helpful tip for the future. Many thanks!

[UndeadRyker]

I really appreciate the continuous fantastic work you've done for this. But I do hope you reconsider this:

On 12/11/2021 at 5:07 PM, Revenant100 said:

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.

In this project you actually add multiple rotations for the Nazis which is a bigger fix/change than adding the missing sights back, IMO.

Edited February 5, 2022 by UndeadRyker

[Revenant100]

On 2/5/2022 at 2:18 PM, UndeadRyker said:

In this project you actually add multiple rotations for the Nazis which is a bigger fix/change than adding the missing sights back, IMO.

The omission of firing and pain rotation frames for the SS monster was certainly not an error, oversight, or inconsistency on id's part, so the inclusion of the fanmade rotation sprites here is not meant to be within the stated scope of the sprite fixes. These community resources for Wolfenstein 3D actually have more use in Doom 2 than they do in the game they were originally created for, and there's really no other type of WAD that would ever incorporate them. Combined with the fact that the SS is a joke monster that appears in a total of two maps within all official IWADs (hence it is virtually never seen outside of deliberate joke WADs), the inclusion of the missing rotations was largely for fun. It's basically an Easter egg on an Easter egg, and it happened to be fully non-intrusive to boot. It's not representative of the project's aim as it's  the intentional sole exception of its kind.

 

The SSG, on the other hand, falls within the realm of normal gameplay sprites, and without going into the nitty gritty, addressing the missing sight would require original art well beyond the "minor" ambition. Just drawing in the few pixels above to fix the Imp's missing knee spikes already constitutes one of the more extreme examples of introducing original art in any fixes, and that had numerous adjoining frames to use as reference points for that addition.

Edited February 6, 2022 by Revenant100

[rzh]

10 hours ago, Revenant100 said:

the SS is a joke monster that appears in a total of two maps within all official IWADs (hence it is virtually never seen outside of deliberate joke WADs)

*laughs in A.L.T.*

Anyways, do you have any plans for updates for Heretic/ a Hexen Minor Sprite Fix?

I remember reading one of your comments about Hexen being a headache though, and I'm also wondering what makes editing Hexen so much harder.

[HavoX]

19 minutes ago, rzh said:

Anyways, do you have any plans for updates for Heretic/ a Hexen Minor Sprite Fix?

I remember reading one of your comments about Hexen being a headache though, and I'm also wondering what makes editing Hexen so much harder.

To chime in, I'm more than willing to help you out if you do. I did some work on some sprite fixes for the monsters in both Heretic AND Hexen.

 

My intention was to use these for my top-secret project*, but I have not forgotten about vanilla compatibility.

Unfortunately, there is a problem, and that involves the weredragon. The missile animations should be lit, and because HHE has no support for Shadow of the Serpent Riders, I can't do jack-shit about it. If only the HHE source code were released, damnit!

 

*(Yes, I'm still working on it, but you shouldn't rush perfection; ask Noctua.)

Edited February 6, 2022 by HavoX

[Revenant100]

3 hours ago, rzh said:

Anyways, do you have any plans for updates for Heretic/ a Hexen Minor Sprite Fix?

I remember reading one of your comments about Hexen being a headache though, and I'm also wondering what makes editing Hexen so much harder.

Yes, there will be an update to the Heretic sprite fixes which will coincide with the eventual Hexen sprite fix release. The biggest hurdles for Hexen has been that it's not nearly as popular as Doom, hence there's little in the way of familiar or common knowledge errors to address, and that it contains about as many sprites as Doom and Heretic combined. Consider that we're now a decade removed from the start of the Doom sprite fixes and still identifying potential errors to fix here! Although it won't be nearly as active a project in the long term, the initial scrutinizing of Hexen's sprites is nonetheless going to be a long and tedious endeavor, and I no longer have the abundance of free time as I did back then.

 

However, there has been one major recent development that indirectly supports sprite fixes for Hexen: the creation of Nash's WidePix. This alleviates the need for me to attempt my own widescreen sprites, and while widescreen-friendly sprites for Heretic and Hexen was always a secondary goal that only benefited the ZDoom family of ports at the time, there are now growing options where such sprites also make a difference.

 

3 hours ago, HavoX said:

To chime in, I'm more than willing to help you out if you do. I did some work on some sprite fixes for the monsters in both Heretic AND Hexen.

I appreciate the offer for help. At the moment, I don't need any direct assistance with the fixes. However, if you happen to have one handy, a list of errors you've already identified in Hexen would be a great resource to keep in mind as I go over its sprites. The more eyes and more collaboration on such a project, the more thorough and encompassing it can be.

Edited February 6, 2022 by Revenant100

[Alaux]

I noticed that the uppercase S from the big font graphics might be consistently missing two pixels of outline. I noticed this with most if not all appearances of said character, although my analysis might not have been thorough enough. A single example below:

Spoiler

I'm quite unsure about this, however; as I said, it is consistently present, so it could be deliberate, but on the other side, the outline is not complete unlike most other characters and graphics, and if the pixels above or below the highlights are meant to be the missing pixels, they're not the same color as the rest.

Edited February 7, 2022 by Alaux

[The Almighty Egg]

Is a Chex Quest sprite fixing project possible or is it too difficult to tell what's an error or not.

[HavoX]

2 hours ago, Eggman07 said:

Is a Chex Quest sprite fixing project possible or is it too difficult to tell what's an error or not.

Well, unfortunately, (and as much of a good idea as it sounds) it seems to me that a project like this is, as Revenant100 mentioned... tedious.

 

(And before anyone mentions Strife... yes, I believe that would be a tedious job as well.)

Edited February 7, 2022 by HavoX

[Revenant100]

15 hours ago, Alaux said:

I noticed that the uppercase S from the big font graphics might be consistently missing two pixels of outline.

The more I look over the font graphics, the more idiosyncrasies I come across. For reference, another independent review of the font artwork can be found in this thread. The takeaway is, I'm not sure the rules (at least the best we can surmise based on examination) for the font's appearance is as concrete or consistent as we'd like them to be. Ultimately, since I've already been including fixes for other identified font errors, I may as well commit to these as well, presuming the particular text graphics are safe to replace. I'll have to do some checking to ensure they're not likely to lead to conflicts.

 

7 hours ago, Eggman07 said:

Is a Chex Quest sprite fixing project possible or is it too difficult to tell what's an error or not.

I think the question for any sprite fix project attempt is what its end value will be versus the time investment involved. The problem with games like Strife and Chex is that, quite unlike Doom, Heretic, and Hexen, the former don't have much ongoing replayability. The replayability in question here is essentially the endless modding the games receive. People get great use and functionality out of these current sprite fixes because they'll continue to take effect in the many WADs, mods, and so forth that are produced by the active modding community. Of course, there's already a massive gap in modding activity between Doom and the Raven games. Consider then just how virtually non-existent modding is for Strife and Chex. Any sprite fixes would just have far less value for these two. While ideally it would be great to create the sprite fixes simply for the sake of having them available, it's hard to justify the time and effort required, especially in the case of something massive like Strife.

[maxmanium]

This is more of an edge case, but some ports like Crispy Doom and Doom Retro have an option to randomly mirror corpses -- it might be worth it to consider adding padding to death animation sprites so that they mirror properly. I'm not sure if that necessarily fits within the project's philosophy, but it certainly wouldn't hurt anything.

[Revenant100]

1 hour ago, maxmanium said:

This is more of an edge case, but some ports like Crispy Doom and Doom Retro have an option to randomly mirror corpses -- it might be worth it to consider adding padding to death animation sprites so that they mirror properly.

If a source port is adding a feature as non-vanilla as arbitrary mirroring of non-mirrored sprites, it may as well also add proper mirroring logic for the sprites at the code level since that's actually a very vanilla-friendly feature that supports the original intentions.

 

That said, what ports (aside from Chocolate Doom and the like) still haven't implemented correct mirroring? Last I checked, Crispy Doom was indeed one, but fabian chimed in in this very thread years ago and said he committed the fix. GLBoom+ is obsolete, I recall hearing that ZDaemon was supposed to add the fix (and it may have?), I don't think Odamex ever did, and I can't imagine Doom Retro not already having this.

Edited February 9, 2022 by Revenant100

[maxmanium]

I had no idea this was already addressed at the code level. I think it may have been something during the cast call game state rather than the normal playsim so I guess that makes sense -- I just assumed it was broken there too.

[maxmanium]

On the topic of menu lumps, M_SFXVOL and M_MUSVOL both have the rightmost "E" cut off by one column of pixels in comparison to other graphics.

 

EDIT: The leftmost column of pixels on the first "G" of M_DETAIL is also cut off.

Edited February 11, 2022 by maxmanium

[maxmanium]

Apologies for posting so many times in a row. I happened to notice an off pixel on frame PLAYB1, and then I found (what I presume to be) an error on frame PLAYB5 as well.

 

Spoiler

 

[Revenant100]

The tan pixel between Doomguy's legs in PLAYB1 does look to be an oversight. This particular tan color is used for his helmet, boots, and other gear, but there's no reason why it would be sitting right at the corner of his pants like that. Oddly, this very same pixel exists in the Zombieman's equivalent POSSB1 frame where it actually fits fine there since this tan color is a part of his uniform. The pixel is appropriately recolored to black for the Shotgun Guy's black outfit, so I'll be recoloring it to an appropriate green on Doomguy for consistency between the three.

 

As for PLAYB5, I'm not certain what you're pointing out here. If you mean to show that there appear to be some seemingly erroneous green pixels connecting between the legs which should be removed, I wouldn't agree to that. We can see the pants are somewhat baggy and do hang over the boots in several frames. This sufficiently accounts for the pixels you've highlighted here.

[Alaux]

Speaking of legs, I noticed that POSSA6 has some rather suspicious green pixels on one of them:

Spoiler

  

Could very well be a part of the shading though, given the limited palette.

[Revenant100]

A few green pixels also appear at the back of the left foot in POSSB7.

 

Of note is that both of these frames are exclusively from the long lost rotations for the Zombieman, so this would never have been identified before. Most importantly, though, despite using the same shades of green from Doomguy's uniform, these green pixels in the Zombieman's sprites do not originate from the original Doomguy frames. The obvious immediate thought is that these green pixels could have been inadvertent leftovers when modifying the Doomguy artwork to become the Zombieman, but Doomguy's knee pads and boots do not use these greens at all. They're completely original to the Zombieman frames. In the absence of any other evidence, it appears the use of these shades of green to create darker shading was indeed a very deliberate decision by id's artists. An odd quirk, but hardly the only one of its kind among the game's art and evidently not an error, so it doesn't warrant any changes.

Edited March 9, 2022 by Revenant100

[ChaoticReverie]

I understand some palette issues were corrected on a large number of sprites. May I ask if any of those edits involved the Baron of hell and Spider Mastermind? I have made my own edits to these sprites based on the ones done in this project and I'd like to avoid having to redo them if possible.

 

Edit: I missed the list you posted before, thank you!

Edited May 3, 2022 by ChaoticReverie