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

[ChaoticReverie]

Thank you! That is very helpful. I want to keep my own sprite edits consistent with the update. It looks like I wont have to do too much work.

[hawkwind]

Not sure if this would be classified as a major sprite fix, but have a look at the final death frame of the chaingunner - CPOSN0. You will still see the chaingun muzzle. This is clearly an oversight, since the final frame should not show any of the weapon. Weapon is dropped. Gibbed frame CPOST0 is OK .

[maxmanium]

1 hour ago, hawkwind said:

Not sure if this would be classified as a major sprite fix, but have a look at the final death frame of the chaingunner - CPOSN0. You will still see the chaingun muzzle. This is clearly an oversight, since the final frame should not show any of the weapon. Weapon is dropped. Gibbed frame CPOST0 is OK .

 

It's present in all death frames. It's probably far too intrusive to edit it out. Would look weird if it just disappeared suddenly too.

[Revenant100]

On 1/9/2023 at 7:47 PM, hawkwind said:

Not sure if this would be classified as a major sprite fix, but have a look at the final death frame of the chaingunner - CPOSN0. You will still see the chaingun muzzle. This is clearly an oversight, since the final frame should not show any of the weapon. Weapon is dropped. Gibbed frame CPOST0 is OK .

This doesn't fall under the realm of an outright error or oversight on the part of id's artists, rather being an instance where the art doesn't agree with the actual game mechanics. Other examples of such inconsistencies include the recently mentioned projectile origins not matching the monsters' respective firing art, Revenants possessing two shoulder-mounted launchers yet only firing one rocket, Barons/Knights and Cacodemons still bleeding red despite their art having their own unique blood color, and so forth. While it might look wrong for the Heavy Weapon Dude to continue holding his chaingun as he dies while another chaingun suddenly drops to the ground, id's artists certainly intended for the weapon to be present during the entirety of his death sequence and accordingly drew it in every frame. Thus, this is not a mistake to fix and can be considered yet another instance in the long list of quirks in Doom's art.

[Devalaous]

who knows, maybe they originally just dropped clips at some point.

[maxmanium]

By complete accident, I found this error in SARGC1:

 

 

Compare the rightmost toenail? to the leftmost in SARGA1:

 

[Revenant100]

Yes, I had noticed that issue with the inconsistent shading on the Demon's toe before. Although one might argue that the shading is deliberately different due to the orientation of the light source, there's no precedent for such a discrepancy in any other mirrored frames. Thus, it's reasonable to consider this inconsistency an error, but the question is, which toe shading is the correct one? Neither is obviously wrong, there are no adjoining frames that offer a helpful clue, and there's nothing in the lineage of Demon sprites we have to indicate it one way or the other. When the choice is seemingly down to 50/50 chance, is it even certifiably an error at that point? For this reason, this Demon toe shading was not altered in the v2.0 release.

 

However, it was only shortly after the v2.0 release that I finally noticed the damning detail which revealed all. As detailed here:

 

There is, in fact, a second error between the SARGA1 and SARGC1 frames. Somehow, the height of the sprite was increased by 1 pixel in SARGA1, and the top row of pixels encompassing the Demon's spine ridge was duplicated in this space. This issue does not exist in the SARGC1 frame, indicating it's the later fixed/intended appearance. The Demon's spine ridge only being one pixel tall from the body also agrees with the adjoining rotation frames, providing additional supporting evidence. How this error came about is likely another mystery lost to time, but fortunately, we do have enough information to come to a conclusion here.

 

So, in other words, the first two fixes (on the very same sprite, no less) for the subsequent v2.1 release of the Minor Sprite Fixing Project are officially confirmed! There's no immediate rush to get this update out, however, and I would expect this to still be several years off from now, probably closer to Doom's 35th anniversary, to collect any other minor fixes in that time (or to accommodate some major pertinent event which hopefully occurs by then).

Edited May 2, 2023 by Revenant100

[wertercatt]

@Revenant100

Do you have any tips or documentation on approaching a project like this? I want to try and make my own sprite fix wads for Chex Quest and Kick Attack! but I don't know where to begin.

[Revenant100]

12 hours ago, wertercatt said:

Do you have any tips or documentation on approaching a project like this? I want to try and make my own sprite fix wads for Chex Quest and Kick Attack! but I don't know where to begin.

If you're not sure where to start on such a project for Chex Quest or the like, I recommend checking the Doom 2 changelog and taking note of the kinds of fixes that have been made over time. Just reading about the changes doesn't give the full picture, of course, so I suggest using SLADE to open up the sprite fix WAD itself, also opening up the original Doom 2 IWAD, and then comparing the individual sprites to see what the fixes described in the changelog actually look like in practice, keeping in mind how these sort of alterations may also apply to the other WAD you're looking to make fixes for. You would presumably already be fairly familiar with the sprites in that other game.

 

Doom and Doom 2 enjoyed a huge advantage in the area of sprite fixes as its long history has been heavily recorded and catalogued, numerous resources from its development cycle have been made available, and the games have undergone decades of community scrutiny. This provided a great amount of context to ascertain the intent of id's artists on how they approached the game's art. Unfortunately, for smaller and obscure titles like Chex Quest, this wealth of information simply isn't available. Just as I had to do with the comparatively much less popular Heretic, I had to make far more of my own judgment calls when it came to fixes compared to Doom, but that's really the only avenue possible given the knowledge and resources that are available to us.

 

Ultimately, there's really no strict guidelines to follow. What sprites issues that may warrant fixing is entirely dependent on the game, and how to approach those fixes is dependent on the nature of the sprites. Kick Attack! is deeply rooted in Doom's artwork, so techniques similar to these Doom 2 sprite fixes would be appropriate there, but something like Chex Quest uses a completely different art style which I think necessitates a different approach. Nonetheless, the technical nature of most sprite fixes for these WADs would probably fall into two of the categories I outlined in my original post: small image edits and adjusting sprite offsets (as there are no missing graphics to restore). That keeps the scope reasonably "minor" by not going too far (unless absolutely necessary) and ensures you're retaining the spirit of the original artwork, which I believe is very desirable.

[maxmanium]

Small nitpick: M_DETAIL should be given an offset of (1,0) since the fix is a new column of pixels to the left.

[SiFi270]

The fixes for Dimension of the Boomed seem to replace the minigun's sprites with the original chaingun. Either that or I have an outdated version, I guess.

[Revenant100]

On 6/11/2023 at 8:58 AM, maxmanium said:

Small nitpick: M_DETAIL should be given an offset of (1,0) since the fix is a new column of pixels to the left.

Shifting the M_DETAIL graphic over one pixel may make it retain its original position, but it will create a new inconsistency in that the left aligned menu options will no longer be flush with one another.

 

However, adding the missing column to M_DETAIL (and therefore shifting the rest of the graphic over to the right one pixel) does make the colon touch the "HIGH"/"LOW" settings graphics on the right side, but that's just going to be a quirk of the fix. You can tell by the spacing between the colon and the "ON" of the above M_MESSG graphic that the spacings in these menus were never consistent even before the one pixel shift.

 

On 6/17/2023 at 8:20 AM, SiFi270 said:

The fixes for Dimension of the Boomed seem to replace the minigun's sprites with the original chaingun.

Thanks, that's definitely an oversight. The download link for the compatibility patch of Dimension of the Boomed has been updated with the fix.

Edited June 25, 2023 by Revenant100

[maxmanium]

1 hour ago, Revenant100 said:

-snip-

 

Would it maybe be better to give M_GDHIGH & M_GDLOW an offset of (-1,0)?

[Revenant100]

A much less intrusive means that doesn't require altering two additional graphics is to reduce the spacing between the "Graphic Detail" words by one pixel, like so.

 

This leverages the fact that the spacing between words isn't consistent in any of the menu graphics to begin with, and given the low priority on matters outside of anything that isn't an in-game sprite, this is a plenty adequate solution, plus it comes with the bonus of retaining the sprite's original dimensions. Ergo, here's the third confirmed fix for the future v2.1 release of the sprite fixes, again still aiming for roughly four or five or so years from now.

Edited June 26, 2023 by Revenant100

[VoanHead]

Good evening, I have a small question about the spritefix patches. Is the reason why there's different ones for select pwads like specifically for BTSX is b/c of the playpal colors being different shades? Would the regular plain ol' spritefix patch not work correctly w/ any other PWAD who's playpal colors are different like BoatyMcBoat.wad?

[maxmanium]

15 hours ago, VoanHead said:

Good evening, I have a small question about the spritefix patches. Is the reason why there's different ones for select pwads like specifically for BTSX is b/c of the playpal colors being different shades? Would the regular plain ol' spritefix patch not work correctly w/ any other PWAD who's playpal colors are different like BoatyMcBoat.wad?

 

It's not about the shades specifically, it's because the palette reuses some redundant colors to add in extras. So the sprites have to be re-indexed to this new palette, otherwise the colors will be wrong. The wad you linked does not need a compatibility patch because the layout is identical to Doom's palette, just with hue/saturation shifts.

[VoanHead]

1 hour ago, maxmanium said:

 

It's not about the shades specifically, it's because the palette reuses some redundant colors to add in extras. So the sprites have to be re-indexed to this new palette, otherwise the colors will be wrong. The wad you linked does not need a compatibility patch because the layout is identical to Doom's palette, just with hue/saturation shifts.

Aight gotcha, this’ll be alright to play w/ the fix then.

[Revenant100]

Greetings, fellow minor sprite fix enthusiasts! I come to you today with a new release! However, it's not a new version of the sprite fixes as you might expect. In fact, it's a level! Yet, while this level is intrinsically linked to the Minor Sprite Fixing Project, its utility stretches well beyond that!

 

To set the stage here, when either viewing or making such sprite fixes over the years, it's always been necessary to do plenty of testing to ensure the end visual results. While external programs like SLADE and WhackEd are essential and invaluable tools in creating and previewing the sprites, there's really no substitute for checking out how they look within Doom itself. To walk around an 8-sided sprite in real time, to watch the frames of animation in motion, to see the sprite offsets and in-engine mirroring in action, and so forth are all critical. The problem is that it's not the most convenient option seeing as many of these sprites comprise demons that are trying to kill you most of the time. The solution here is to make a custom map featuring a full suite of dedicated sprite demonstrations, but while such a task can be done fairly easily in source ports with advanced scripting methods, there really should be some entirely vanilla-compatible solution available to permit maximum flexibility. And that's just what I set out to achieve!

 

Hence, I present Monster Sprite Expo (SPREXPO.WAD), a fully vanilla-compatible museum demonstration level that allows one to conveniently view all of the sprites of Doom's demons organized into their individual states. Handy for testing minor sprite fixes, one-to-one sprite replacements, voxel monster replacements, source port sprite clipping and other rendering options, and much more, all in the comfort of whatever source port (or lack thereof!) you desire!

 

Download: SprExpo.zip

 

Map features:

Spoiler

• All 17 of Doom's hellish beasts (plus Commander Keen, Romero's head, and Doomguy, of course!) presented in separated continuously looping animation sequences with accurate frame timing
• Individual viewing rooms with one-sided wall for complete distraction-free observation
• Non-solid actors to allow super close-ups
• Circular grid pads under and above all actors to help judge sprite centering, mirroring, and general offsets
• Teleporters for instant travel to the west, center, and east points of the map
• (Boom-only enhancement) Conveyor belts to automatically send you across the level
• Monster banner "bookmarks" to help identify the sprites you're looking for from anywhere in the museum hall
• Invisible flashlight - Hold fire for fullbright lighting!
• Light switch chambers to toggle room lighting, ideal for testing fullbright frames, brightmaps, and other lighting effects
• Easter egg! (Hint: It's not in the map. Double Hint: Doesn't work in GZDoom due to technical inferiority.)
• Pleasant and immersive museum-going atmosphere and experience

 

Map preview images:

 

Example source port and PWAD demonstrations:

• Chocolate Doom
  
• DSDA-Doom (Minor Sprite Fixing Project)
  
• DSDA-Doom (Ultimate Simpsons Doom)
  
• GZDoom (Voxel Doom)
  

Edited December 23, 2023 by Revenant100

[maxmanium]

I wish this had been around when I was doing a lot of messing around with custom color palettes and COLORMAPs. Also props for the BOOMEDIT.WAD homage(s).

[DoomGappy]

I don't know if it's been pointed out, but There seems toi be 5 loose blood pixels on the machinegunner's death sprite. They are below the floor level, and thus are only seen when he dies upon a h igher platform than the player. I don't know if this has been pointed out or if it's from vanilla Doom or the mod.

[DoomGappy]

40 minutes ago, jo2ukegappy said:

I don't know if it's been pointed out, but There seems toi be 5 loose blood pixels on the machinegunner's death sprite. They are below the floor level, and thus are only seen when he dies upon a h igher platform than the player. I don't know if this has been pointed out or if it's from vanilla Doom or the mod.

Just checked on SLADE and it's both in the doom2 wad and in the sprite fix project. Maybe it's not a mistake, but it looks like it, like they tried to make a speck of blood but it was left there or something. Still think it looks weird. 

EDit: Just checked the flow of the sprite and it seems to be they tried to make it be his eye poppring from its socket? Honestly, I don't think it looks good, but hardcore of their part. Maybe it's the sprite height problem showing in my pc too. I use GZDoom, after all.

Edited August 1, 2023 by jo2ukegappy

[Revenant100]

2 hours ago, jo2ukegappy said:

I don't know if it's been pointed out, but There seems toi be 5 loose blood pixels on the machinegunner's death sprite.

This is the Heavy Weapon Dude's left eyeball which pops out of its socket on death, and popped eyeballs are a common sight among the possessed humans' and even the Imp's gibbing sequences. Hence, it's very much intended.

 

2 hours ago, jo2ukegappy said:

They are below the floor level, and thus are only seen when he dies upon a h igher platform than the player.

The eyeball is visible in the original software renderer which follows the intended (or lack thereof) sprite clipping rules. In your screenshots, you're using the hardware accelerated renderer in GZDoom, and all hardware accelerated Doom source ports have had to create their own sprite clipping solutions due to the particular inability to render below floor level sprites as intended. This means either pushing sprites well above ground level to the point where they're visibly floating or allowing a portion of the sprites to clip at ground level, cutting off the bottom of the artwork. Neither is desirable, and in this case, the "Never" sprite clipping option you're using in GZDoom (at least it looks like Never) cuts off the eyeball in the Chaingunner's corpse. The "correct" choice here is to use the software renderer, but that's not always feasible depending on what and how you're playing.

 

Here's a demonstration of the different ways sprite clipping is handled between software, hardware accelerated, and the hardware sprite clipping options:

Edited August 1, 2023 by Revenant100

[DoomGappy]

4 minutes ago, Revenant100 said:

This is the Heavy Weapon Dude's left eyeball which pops out of its socket on death, and popped eyeballs are a common sight among the possessed humans' and even the Imp's gibbing sequences. Hence, it's very much intended.

 

The eyeball is visible in the original software renderer which follows the intended (or lack thereof) sprite clipping rules. In your screenshots, you're using the hardware accelerated renderer in GZDoom, and all hardware accelerated Doom source ports have had to create their own sprite clipping solutions due to the particular inability to render below floor level sprites as intended. This means either pushing sprites well above ground level to the point where they're visibly floating or allowing a portion of the sprites to clip at ground level, cutting off the bottom of the artwork. Neither is desirable, and in this case, the "Never" sprite clipping option you're using in GZDoom (at least it looks like Never) cuts off the eyeball in the Chaingunner's corpse. The "correct" choice here is to use the software renderer, but that's not always feasible depending on what and how you're playing.

 

Here's a demonstration of the different ways sprite clipping is handled:

Thanks for the answer, makes sense. I noticed it just a little bit later. Would you mind explaining very quickly why does that effect happen when using hardware acceleration? I know that software rendering has that warping effect when yolu activate moselook, but why do the textures on hardware acceleration? Fascinating stuff. 

[Revenant100]

11 minutes ago, jo2ukegappy said:

Would you mind explaining very quickly why does that effect happen when using hardware acceleration?

In short, the technical reason is the depth buffer, or rather that the original software renderer has no depth buffer but hardware accelerated renderers do. I'm not well equipped to explain the matter myself, but there's this Doom Wiki article which touches upon the subject and Kaiser's Sprite Clipping in Strife: Veteran Edition Explained article more relevantly explaining its relevance to floor clipping.

[DoomGappy]

18 hours ago, Revenant100 said:

In short, the technical reason is the depth buffer, or rather that the original software renderer has no depth buffer but hardware accelerated renderers do. I'm not well equipped to explain the matter myself, but there's this Doom Wiki article which touches upon the subject and Kaiser's Sprite Clipping in Strife: Veteran Edition Explained article more relevantly explaining its relevance to floor clipping.

Thanks, that's really cool and sorry for pointing out something silly. 

[The Almighty Egg]

Now what I wouldn't give for a Strife version of the Monster Sprite Expo.

[Revenant100]

I've added a work-in-progress PWAD compatibility patch for the recently released Back to Saturn X Episode 3 Preview to the OP, and the download link is copied here as well for convenience:

 

Back to Saturn X Episode 3 Preview compatibility patch (load the sprite fixes after BTSXE3PR.wad):

• D2SPFBX3.zip (2 MB)

Preview image:

 

As is the case with any WIP compatibility patch, it may be necessary to download updates as future versions of the PWAD are released. Be sure to check this thread when new developments occur.

Edited August 10, 2023 by Revenant100

[NihalRahman123]

Hey Revenant100

I am all about making palette's. Recently wanted to do a sanitization project, where I reindexed some niche/sparsly used colors in the palette ( index 248-255 ) to other existing similar colors in the palette, in order to free up palette space for custom stuff for people making custom texture sets or wads. I am using your spritefix mod as a base for certain sprites that were spritefixed but needed a reindex. Is it ok if i upload that mod/fix/resource? do i need to credit your or anything? Do let me know, if you are not cool with it, i will use the base game sprites for the reindexing instead

Edited August 14, 2023 by NihalRahman123

[Revenant100]

6 hours ago, NihalRahman123 said:

Is it ok if i upload that mod/fix/resource?

Certainly, you're more than welcome to utilize, build upon, and repackage the WAD in whatever way you wish. The sprite fixes are an open and accessible community resource that's available to everyone.

[MugMonster]

I was looking at Scientist in Crispy Doom since it got added to the Unity Add-Ons and noticed it doesn't seem to be compatible with this project.  some things are obviously not meant to be compatible, like the mod's unique Caco replacement, but even if I tried to load the wads in a different order so the sprite fix project doesn't overwrite the unique content, it still doesn't actually work, because it seems everything in Scientist is replaced, so if the sprite fix isn't priority, then things like the rotation sprites for zombies just don't get used.  any chance you could look at the differences and see if a compatibility patch is possible?