Revenant100

Thanks for the report! This is indeed a mistake, and I've noted it for the next release. If you're recording a speedrun for formal submission to DSDA, you shouldn't have any unnecessary external WADs loaded while playing, and the sprite fixes fall under that umbrella. However, for demo playback, the sprite fixes and the DeHackEd fixes are both demo compatible. The sprite fixes in the WAD are purely cosmetic graphic replacements, so there's no surprise there, but it is indeed unusual for a DeHackEd patch to be demo sync safe. The changes in the DeHackEd patch are also purely cosmetic, though, and they were carried out in such a way that they don't cause conflict with demo compatibility, hence they can safely be loaded while running demos.

If you're loading the WAD file for Scientist as taken directly from the Unity port right now, then all of the sprite fixes will be overridden because this WAD file is essentially its own IWAD, meaning it contains the entirety of Doom 2's sprites (and all other assets). For technical reasons, all of the Unity Doom add-ons are packaged as IWADs. If you want to play Scientist outside of the Unity port, I recommend waiting for the idgames archive version which is being uploaded right now which will omit all of the redundant IWAD resources and therefore allow more of the sprite fixes to take effect. Do note that Scientist does replace many Imp, Demon, and Doomguy sprites to give them glowing eyes, hence they'll override a lot of the sprite fix frames for those guys.

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.

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.

As I'm sure you've heard by now, ROTT fans around the globe have been up in arms regarding the truly calamitous omission of omissions: the acclaimed GUNFINITY selection warning.

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.

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 between software, hardware accelerated, and the hardware sprite clipping options:

But as it so happens, this release doesn't even include an alternate male variant for the Lightning Guard, even though we already know there was one played by the late William Scarboro. And not only was William's portrayal as the Lightning Guard featured in the game's credits, but new art of his sprites was also recently shown on Twitter in regards to cut characters that they still needed to "finish restoring": But release day has come, and the William Scarboro Lightning Guard is nowhere to be seen with nothing said of his conspicuous absence. In fact, the mystery deepens even further as the game includes a complete and seemingly pointless duplicate copy of the original Kevin Green Lightning Guard "LIG" sprites but under the name "WIG", and I can confirm these graphics are loaded in-game as "alternate" Lightning Guards even though they are 100% identical. Is this unsolved enigma of the missing alternate William Scarboro Lightning Guard one that will remain for the ages? Perhaps only time will tell. Also, since these duplicate Lightning Guard graphics actually are loaded, I have would posited that a mod could be made to create and load in some actual alternate Lightning Guard sprites since the code support is already there, but that's an impossibility as well as all forms of KPF mod loading are unfortunately disabled, a great and inexplicable peculiarity for a KEX title with Workshop support.

It's a rendering issue with GLBoom which has carried over to the current OpenGL renderer of DSDA-Doom. But that's ole de-"hardware-accelerated"-cino for you, always trying to fit an OpenGL peg into a software floor-above-floor rendering trick!

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: 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)

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.

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. Thanks, that's definitely an oversight. The download link for the compatibility patch of Dimension of the Boomed has been updated with the fix.

This is the vertical view of a vertebrae in the Revenant's spinal column (similarly visible on a dead Hell Knight or Baron, see example below) which represents how the Revenant's body is forcefully ripped in twain as his entire upper half is torn from his legs with the torso being propelled a distance backwards onto the ground, making it one of the most extreme and violent deaths the player will come across in Doom.

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.

The Doom Music album was produced first, and the reason why many tracks were shortened was to fit the ~70 minute capacity of a CD, as Bobby lamented on his site here. If you're interested in more of Bobby's lost Doom tracks, he had uploaded a rendition of The Imp's Song to his mp3.com profile as seen here (plus a couple of other non-Doom songs). This track was not included on any of his disc releases, so it's unknown what it may have sounded like. This playlist indicates the MP3 was 3:31, making it over a minute longer than the 2:35 game version we have in MIDI/MUS form. Unfortunately, only "Xenorage Live" (from the hit game Xenophage) seems to have been saved from Bobby's mp3.com days. The lost further extended cut of Donna to the Rescue is detailed in the below guy's post, and the disc label there shows several more Doom and Doom 2 tracks which never received a disc or digital release: