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

[Alaux]

48 minutes ago, ChaoticReverie said:

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?

Based on a list that specifies the lumps changed in 2.0 Beta 1 relative to 1.9, the Baron sprites are the same, but most of the Spider Mastermind sprites have been modified.

Here's the list:

On 1/22/2022 at 4:14 PM, Revenant100 said:

 

  Reveal hidden contents

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.

 

EDIT: Posted before seeing your edit... oh well.

Edited May 3, 2022 by Alaux

[The Almighty Egg]

How is progress going on the Hexen project?

[Revenant100]

9 hours ago, Eggman07 said:

How is progress going on the Hexen project?

There hasn't been any as of yet. There's a pass on Doom's text graphics to be done first.

[The Almighty Egg]

Also, did you ever check the doom title screen for any discrepancies or anything useful.

[Revenant100]

The TITLEPIC is another graphic that cannot be changed due to unavoidable IWAD conflicts. Again, this applies more to Doom 2 rather than Doom 1 (the TITLEPIC lump name being shared with Plutonia's and Evilution's TITLEPICs), but it's still not worth the potential future conflict to alter it. As for looking over it, the Cacodemon in the corner does have an erroneous transparent pixel at the corner of his mouth which is hard to spot because the red sky background blends in, but this was already identified and fixed for the normal sprite.

 

It is worth noting that the Doom 1 TITLEPIC was updated in the shareware version after the initial 1.0 release (changed from this to this), and this update did some small touch ups to the art. Of relevance to the sprite fixes is that a few pixels on the Cacodemon's nose were tweaked. While I considered carrying this over to the main sprite since it was a new and deliberate adjustment, this art update was ultimately done in complete isolation from the rest of the sprites just for the TITLEPIC, hence they weren't necessarily thinking about how it'd look in-game as well.

Edited May 9, 2022 by Revenant100

[maxmanium]

I found a disappearing pixel (highlighted in cyan here) in frames M and N of the player sprite. Maybe the other way around, but not sure. Frame L on top for reference.

 

Spoiler

 

[NightFright]

I dunno if it qualifies for this project, but CELL has two green pixels at the bottom which will light up in ports like Crispy or Woof when you activate brightmaps. Replacing these with one of the surrounding colors would improve the result.

 

I have marked the pixels in question with yellow in the screenshots below. Fix suggestion also attached.

 

 

 

Edited May 19, 2022 by NightFright

[Revenant100]

On 5/16/2022 at 1:08 AM, maxmanium said:

I found a disappearing pixel (highlighted in cyan here) in frames M and N of the player sprite. Maybe the other way around, but not sure. Frame L on top for reference.

  Reveal hidden contents

 

The nice thing about this particular inconsistency is that we have two reference points to examine when it comes to determining how to address it. We have the final sprites (top row), the press release beta sprites (middle), and an alternate decapitation death from Romero's sprite sheets (bottom).

 

It looks like Doomguy's right shoulder was redrawn between the press release beta and the final game to match the size of his left shoulder. As for whether the pixel in question is disappearing or shouldn't be there to begin with, the answer lies in the decapitation frames which reveal more of the shoulders behind the head: the shoulder should create a straight contour on the upper edge. Hence, the pixel in the final sprite is incorrectly disappearing in the last two frames. I'll mark this as a new fix.

 

On 5/19/2022 at 2:47 AM, NightFright said:

I dunno if it qualifies for this project, but CELL has two green pixels at the bottom which will light up in ports like Crispy or Woof when you activate brightmaps. Replacing these with one of the surrounding colors would improve the result.

Since this is a visual discrepancy created solely by the Crispy and Woof! ports, it doesn't warrant a fix in the sprite itself. Furthermore, the energy cell ammo appears to be made of metal, and this exact dark green in the color palette is used in other metal textures in the game (see the WALL47 family and WALL03_7 patches). Ergo, its presence in the energy cell sprite is intentional by the artists to depict this type of metal material. The two aforementioned source ports are making an incorrect assumption that this portion of the palette's green range can safely be made fullbright to create brightmaps.

Edited May 20, 2022 by Revenant100

[Cire]

Did you ever make any progress on a Hexen sprite fixing project?

[Revenant100]

As mentioned above, there won't be any major developments on Hexen until the remaining Doom tasks are taken care of as the latter has always been the priority.

[maxmanium]

I noticed in frames B, C, and D of the KEEN sprites, the entire rope seems to shift a pixel to the right while it's snapping. I'd suggest moving all rope pixels one pixel to the left so that the anchor point to the ceiling doesn't suddenly shift around.

 

Also, the rope itself doesn't connect to the ceiling until the Keen is killed, upon which it shifts too far upward into the ceiling. I'm not sure if anything can be done about this without DEHACKED work tho.

[Revenant100]

6 hours ago, maxmanium said:

I noticed in frames B, C, and D of the KEEN sprites, the entire rope seems to shift a pixel to the right while it's snapping. I'd suggest moving all rope pixels one pixel to the left so that the anchor point to the ceiling doesn't suddenly shift around.

Although it appears to disregard the anchor point, Keen's head remains perfectly aligned in all of his death frames, hence this looks to be a deliberate art decision to reflect the violent snapping of the rope. Nonetheless, the actual technical position of the anchor point is not reflected in the sprite due to the below issue.

 

6 hours ago, maxmanium said:

Also, the rope itself doesn't connect to the ceiling until the Keen is killed, upon which it shifts too far upward into the ceiling. I'm not sure if anything can be done about this without DEHACKED work tho.

That's correct. I've never touched Keen's rope not properly touching the ceiling because its implementation is flawed on two fronts. The first error is art-based in that the rope is simply just a few pixels too short to visually connect to the ceiling, and that's trivial enough to address as has been done for other hanging decorations.

 

However, in the object's sole official use in Doom 2's MAP32, a second error becomes evident. The Keen actor is defined to be 72 units tall, but the space in which the actors have been placed is only 64 units tall. This actor, and consequently the sprite, is pushed down down 8 units, technically clipping into the floor but nonetheless still leaving the ceiling gap above the rope. When a Keen dies, it becomes non-solid and "falls" to the floor which, in this case, actually pushes the actor up 8 units. Visually, this makes rope part of the sprite clip into the ceiling. Thus, there's no way I can adjust the sprite to connect the rope to the ceiling since it's inconsistent between its living and dead states.

 

All of that is a moot point though because, in most every other non-standard use of the Keen actor in custom maps which usually lets in hang in a sector at least 72 units tall, the entire Keen will fall to the ground on death. Hence, he fully disconnects from the ceiling regardless, leaving the rope floating no matter what's done with the art. There's no proper "fix" than can account for all of this.

 

All these technical concerns combined with the fact that Keen is only an Easter egg actor who appears even less than the Wolfenstein SS means no action will be taken here. There's no satisfactory way to go about it, but that's hardly a loss since Keen is never seen outside of deliberate joke WADs, so well enough is being left alone.

[Bytefyre]

Hello!  I saw something rather strange when I was watching back a Jenesis demo that was viddumped with the Minor Sprite Fix WAD included in the autoload in DSDA-Doom 0.24.3.  The SSG definitely doesn't have the brown pixel that would have been present without the Minor Sprite Fix WAD; however, it would appear that the firing frame glitch is somehow still present:

 

 

I'm including a link to the demo video here:  https://youtu.be/9oiYVC7-tx8?t=987.  Jenesis doesn't have any overrides for the SSG frames, so I'm wondering if this is a known issue?

 

[Alaux]

2 minutes ago, Bytefyre said:

It would appear that the firing frame glitch is somehow still present

That glitch is not related to the sprites themselves, it is caused by the SSG's states. I think a DeHackEd patch to fix it is included with the sprite fix WAD, but not in it. It's a separate file.

[Bytefyre]

1 minute ago, Alaux said:

That glitch is not related to the sprites themselves, it is caused by the SSG's states. I think a DeHackEd patch to fix it is included with the sprite fix WAD, but not in it. It's a separate file.

 

Interesting...the text file in the ZIP says the DEH files are supposed to apply to the DOS executables, but I guess that really means they're supposed to be at the engine level?

[Revenant100]

1 hour ago, Bytefyre said:

Hello!  I saw something rather strange when I was watching back a Jenesis demo that was viddumped with the Minor Sprite Fix WAD included in the autoload in DSDA-Doom 0.24.3.  The SSG definitely doesn't have the brown pixel that would have been present without the Minor Sprite Fix WAD; however, it would appear that the firing frame glitch is somehow still present

The SSG muzzle flash lingering too long isn't part of the sprite fixes but rather a DeHackEd fix, and the DeHackEd Fixes are separate from the sprite fix WADs both for compatibility reasons with the original DOS executable and to remain optional. The loose DEH files that comprise these fixes are included in the Minor Sprite Fixing Project package for convenience, but because they're separate, the pertinent DEH file must be manually loaded if you want the DeHackEd fixes to take effect along side the sprite fixes.

 

If you're using the autoload folder feature of PrBoom+ or dsda-doom, you can just put the DEH files in the appropriate folders, like so:

Edited June 16, 2022 by Revenant100

[Bytefyre]

Just now, Revenant100 said:

The SSG muzzle flash lingering too long isn't part of the sprite fixes but rather a DeHackEd fix, and the DeHackEd Fixes are separate from the sprite fixes both for compatibility reasons with the original DOS executable and to remain optional. The loose DEH files that comprise these fixes are included in the Minor Sprite Fixing Project package for convenience, but because they're separate, the pertinent DEH file must be manually loaded if you want the DeHackEd fixes to take effect along side the sprite fixes.

 

If you're using the autoload folder feature of PrBoom+ or dsda-doom, you can just put the DEH file in the appropriate folder, like so:

Ahhh...I understand now.  Thanks for the clarification and explanation!

[Quill]

Didn't want to bump the DEH fixes, but the non-colliding version of one-legged hanging body (DEH index 109) has the dimensions of the hanging leg (DEH index 106), thus making it look like it's clipping into the ceiling.

Is it possible for it to have the dimensions of its colliding counterpart? (DEH index 104) Or would it break demo compatibility?

Edited June 19, 2022 by dotQLL

[Revenant100]

5 hours ago, dotQLL said:

Is it possible for it to have the dimensions of its colliding counterpart? (DEH index 104) Or would it break demo compatibility?

I've considered making this fix before, and changing the height of an object that is non-solid and therefore cannot be interacted with by any means should, in theory, be demo sync safe. The concern is that there might be some edge case out there in which this change would cause some issue, and that's not necessarily just breaking demo compatibility (although that'd be a consequence as well). Maybe a source port changes the handling of the hanging corpse decorations which leads to a conflict, and some ports do already indeed fix this hanging corpse in their own way. A more likely case is that some mod, whether it be a simple DeHackEd patch or advanced GZDoom scripting, changes something (perhaps not directly related to the hanging corpses) which leads to unintended behavior because this one particular object's height was changed.

 

In practice, though, I've yet to come across any of these potential scenarios over the past several years since I initially made the DeHackEd fixes, so maybe this one-legged corpse height could safely be fixed. I'll consider including it for the 2.0 release, but I'll still be practicing due diligence in the mean time and keep a close eye out for any such potential conflicts.

Edited June 19, 2022 by Revenant100

[maxmanium]

It looks like GZDoom already fixes this, although it does change the radius to 20.

[Revenant100]

38 minutes ago, maxmanium said:

It looks like GZDoom already fixes this, although it does change the radius to 20.

The non-solid "MEAT3" also has a radius of 20 in the original code even though this technically does nothing because of its non-solid state:

https://github.com/id-Software/DOOM/blob/master/linuxdoom-1.10/info.c#L3916

 

In other words, GZDoom correctly fixes the non-solid MEAT3 by inheriting the solid MEAT3's attributes and only removing its SOLID flag and changing its radius to 20, making it accurate to the vanilla actor but with the height fix.

[Doomkid]

On 5/21/2022 at 8:06 AM, Revenant100 said:

The nice thing about this particular inconsistency is that we have two reference points to examine when it comes to determining how to address it. We have the final sprites (top row), the press release beta sprites (middle), and an alternate decapitation death from Romero's sprite sheets (bottom).

 

It looks like Doomguy's right shoulder was redrawn between the press release beta and the final game to match the size of his left shoulder. As for whether the pixel in question is disappearing or shouldn't be there to begin with, the answer lies in the decapitation frames which reveal more of the shoulders behind the head: the shoulder should create a straight contour on the upper edge. Hence, the pixel in the final sprite is incorrectly disappearing in the last two frames.

 

I always liked how the missing pixel served to make his shoulder pads look nice and round. I'll never forgive you for this change.

 

(I also wanted to mention that Zandronum, even in software mode, adjusts the visual position of the one-legged hanging body. It's not due to any "smart sprite clipping" OGL features, but it's probably done just the same way GZDoom does it.)

[maxmanium]

I noticed that the Baron and the Hell Knight have different offsets for some sprites — mostly, I noticed the front facing frames for the Baron’s walking animation (A1, B1, C1, and D1) aren’t mirrored and padded like they are for the HK, and the X-offsets are also different. Is there a reason for this or am I missing something? Shouldn’t they be the same since they’re just palette swaps of one another?

 

Sorry, I misremembered -- they do have the same offsets, though the mirroring on the Hell Knight causes frames C1, C5, D1, and D5 to have a different x-offset than those of the Baron. Or maybe the Baron needs to have its sprites mirrored similarly. I'm not sure which.

Edited June 24, 2022 by maxmanium

[Revenant100]

On 6/24/2022 at 12:04 AM, maxmanium said:

the mirroring on the Hell Knight causes frames C1, C5, D1, and D5 to have a different x-offset than those of the Baron. Or maybe the Baron needs to have its sprites mirrored similarly. I'm not sure which.

Yes, I'm aware of this, and this dives deep into the rabbit hole of sprite mirroring and the intentions behind it from the perspectives of the artists and the code (of which there's actually none from the latter in the original executables, hence the sprite padding fix). I've scrutinized the matter again for all relevant sprites, and, without delving into the convoluted series of steps involved, the end result is that 8 frames were shifted exactly 1 pixel on the x-axis and another 4 frames shifted 2 pixels. This is summed up with these two new bullet points in the changelog:

 

Demon

• [2.0] Further refined sprite offsets during front and rear-facing walking frames. Now perfectly centered and consistent with general sprite mirroring logic.

Baron of Hell

• [2.0] Further refined sprite offsets during front and rear-facing walking frames. Now consistent with Hell Knight's offsets and general sprite mirroring logic.

 

Edited July 10, 2022 by Revenant100

[Revenant100]

Hola, everyone! Believe it or not, it's been six months since the release of Beta 1 of v2.0 of the sprite fixes. The 10th anniversary of the project that will mark the proper v2.0 release is approaching fast, but until then, I figured it's time for the next beta. This Beta 2 release incorporates a handful of new fixes that have cropped up since last time, but the big addition now is bringing all previously released compatibility patches for select PWADs up to date! As before, nothing is being held back in this beta. This reflects what will constitute the forthcoming proper v2.0 release assuming no further updates are made.

 

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

• (Outdated, see original post)

 

Trimmed summary of the v2.0 Beta 1 and Beta 2 (highlighted) changes:

Spoiler

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

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

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

Demon
- [2.0 Beta 1] Fixed gray pixels in teeth in 13 frames. Teeth now have correct consistency with the alpha-to-retail color palette translation.
- [2.0 Beta 2] Further refined sprite offsets during front and rear-facing walking frames. Now perfectly centered and consistent with general sprite mirroring logic.
 

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

 

Baron of Hell
- [2.0 Beta 2] Further refined sprite offsets during front and rear-facing walking frames. Now consistent with Hell Knight's offsets and general sprite mirroring logic.
 

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

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

Player
- [2.0 Beta 2] Fixed miscolored pixel between legs in 1 walking frame.
- [2.0 Beta 2] Fixed disappearing pixel in 2 death frames.

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

 

DeHackEd (part of the separate Minor DeHackEd Fixes)

- [2.0 Beta 2] Fixed non-solid one-legged hanging corpse object clipping into ceiling.

 

There aren't any major visual changes to preview for Beta 2, so I'll copy the previous images from the Beta 1 release in the following spoiler:

Spoiler

The biggest new fix of Beta 1 was 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 for funsies, example of the Imp knee spike fix:

 

Edited November 28, 2022 by Revenant100

[maxmanium]

EDIT: Disregard.

Edited July 17, 2022 by maxmanium

[Revenant100]

36 minutes ago, maxmanium said:

I'd suggest that you rename + mirror the Baron of Hell's walking sprites in the same manner as the Hell Knight's in order to reduce file size and number of lumps (bonus for consistency). Could be done for the Demon as well.

I'm afraid this won't be done as one aim of this project has been to remain as compatible and minimally intrusive as possible for convenience and ease of use in any scenario it can be run in. Being a vanilla-compatible WAD (as close to the bare metal as possible, so to speak) that has a broad range of appeal from players running the original DOS executable all the way to players running modern source ports with all the bells and whistles enabled, this means simply keeping some things as they are. In the case of the non-mirrored sprites you've mentioned, mirroring them now would offer no visual change whatsoever (as expected), and the tangible size/lump count difference would be negligible.

 

On the other hand, where this change would cause conflict is anything strictly dependent on the original lump names. The current manifestation of this problem is GZDoom mods involving brightmaps, but that's not to say some new cases couldn't arise in the future. While such mods could always be updated themselves, and the nature of this project means some particular types of mods will need unique versions to accommodate the sprite fixes regardless, I ultimately strive to avoid needless conflicts where feasible, especially when there's next to no tangible benefit and genuinely no visual difference. In this case, the non-mirorred sprites are the status quo and have been so since the original IWADs, so well enough is once again being be left alone.

Edit: However, scrutinizing the Baron's and Hell Knight's sprites again, I am seeing a discrepancy in the padding in six sprites. I'll investigate this further, but it looks like this'll be a new fix for v2.0.

Edited July 17, 2022 by Revenant100

[maxmanium]

Sorry for the frequent bumping, but I also noticed that the Ancient Aliens fixes don't incorporate sprite padding for the new monster sprites, so they aren't mirrored properly.

[Revenant100]

14 hours ago, maxmanium said:

Sorry for the frequent bumping, but I also noticed that the Ancient Aliens fixes don't incorporate sprite padding for the new monster sprites, so they aren't mirrored properly.

Since Ancient Aliens is a Boom-compatible WAD, this threshold automatically excludes a majority of the engines that don't already support proper sprite mirroring logic at the code level. I think the only actively developed modern source port today that can run Ancient Aliens but lacks proper sprite mirroring is Odamex, and I don't see a reason why the port shouldn't add this at some point in the future.

 

While adding sprite padding to the new monsters in the AA compatibility patch now would be trivial, padding was always meant to be solely a vanilla executable fix. Any modern source port beyond that could (and really should) fix the issue engine-side as the padding itself is intrusive to things like the aforementioned GZDoom brightmaps, and AA does even specifically target such ZDoom-family ports with some exclusive features. Although the PWAD compatibility patches don't operate as strictly as the main sprite fix WADs, I believe the minimal gain from this fix doesn't outweigh the needless and ultimately avoidable drawbacks it would entail.

[L0l1nd3r]

The Auger Zenith Shotgun and SSG sprite offsets are off by 3 to 4 pixels from the Doom 2 Minor Sprite Fixing Project, so the blast overlay appears slightly to the left of the muzzle. I made this to realign the Shotgun and SSG to the sprite fix sprites.

File: DBP37_AUGZEN_SG_SSG_Fix.zip