Revenant100

Also available: Heretic Minor Sprite Fixing and Widescreen-Friendly Project - v1.0 Release SIGIL Sprite Fixing Project Monster Sprite Expo map Greetings, Doomworld forums! I'd like to share with you all the release of a small project I've been working on. To keep a long story short, I recently came across Perkristian's high-res sound effects pack. I like the idea of enhancing Doom while remaining as pure (and compatible!) as possible, so I pondered what other areas this line of thought could be applied to. Perkristian's pack is pretty definitive when it comes to the sound effects, and the music has been dealt with in many ways over the years, but what about the game's art? Of course, I wouldn't dream of recreating the art and thinking it an improvement, but I have noticed tiny little errors in the sprites that seem trivial to fix. Why not go ahead and make those fixes? Hence, I bring you the Doom 2 Minor Sprite Fixing Project. The three main goals of this endeavor are as follows: As for how to use it, this WAD in its current state works with limit removing ports. However, vanilla doom2.exe compatibility simply requires some DeuSF work. With that in mind, you can pretty much use this WAD with any other level or mod as I can't imagine any conflicts. Simply run it with the lowest priority in the add-on hierarchy. Most newer source ports have an autoload feature, so I recommend using that. I personally have this WAD autoloaded while playing PrBoom+, GZDoom, and Zandronum, and I haven't come across any issues. This project now also includes the Doom 1 and 2 Minor DeHackEd Fixes patch files as optional augmentations for convenience. Here's the download of v2.0 which includes both Doom 2 and Doom 1-compatible WADs (released 11/28/22): https://www.doomworld.com/idgames/graphics/sprfix20 (2.6 MB) The complete changelog including the 2.0 edits can be viewed here: https://drive.google.com/file/d/1ehjZifW-3aWYCYHsZbuA-z9ZujUv3FK3/view?usp=sharing Compatibility patches for select PWADs: Work-In-Progress PWAD Compatibility Patches: Full Modder's Resource WAD: Now if you've made it this far, you probably just want to see some screenshots of the changes in action. Well, truthfully, it's rather difficult to showcase the end result outside of the game since many of the effects must be seen in motion. If the idea interests you, I suggest simply downloading the WAD right now and autoloading it during any future Doom sessions. I know this sounds cheap, but some changes are subtle and I think it would ruin the point to explicitly search for the differences. (If you still wish to do so, check out the Monster Sprite Expo map for dedicated sprite viewing demonstrations.) Nonetheless, here's a sample of some of the fixes: (clickable thumbnail) Phew, with all that done, I'll end by saying that this project is still very much and will always be a work-in-progress. I'm open to feedback on the current release as well as potential ideas for further changes.

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:

As per usual, I looked over the add-on release of Base Ganymede, and I've found a few changes compared to the original release. As mentioned, all the maps were given unique names. The three episodes are only called "Base Ganymede Episode #". In E3M4, some linedefs on the outer perimeter of the map were marked as secret. These have no effect on gameplay, so I assume this was just to make the automap linedef colors look nicer. In E3M8, the penultimate room with the teleporter leading to the final boss arena has been prettied up. Original on top, Bethesda'd on the bottom: Also in E3M8, one of the monster closets in the final boss arena now contains a teleporter going back to the main section of the map, allowing backtracking. This is presumably to address a possible softlock if the player neglects to kill the first Spider Mastermind in the main map area, thus making it impossible to beat the level as there previously was no way to return from the final arena. Original on top, Bethesda'd on the bottom:

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

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.

The following Hell Knight, Baron, and Revenant frames were visually altered in some appreciable fashion (including just offset adjustments) in v2.0: The additional following frames, which only encompasses Revenant sprites, were "invisibly" altered in v2.0. These were affected by the duplicate palette color fix, but the changes are only visible under the very specific custom color palettes that are able to reveal these discrepancies. Under the normal Doom palette, these modified v2.0 frames look completely identical to their v1.9 counterparts. Depending on your intent, you may not need to worry about anything in the second group here.

This is a problem I ran into with the Heretic Minor Sprite Fixing Project. As the simplest solution, @Eggman07, I recommend just including a duplicate set of Stalker sprites in the WAD but with the "STLK" sprite name so it works with ZDoom as well, ergo avoiding the need for two separate versions. Vanilla Strife will simply ignore the "STLK" sprites, and hopefully the ZDoom user won't be loading Strife sprite fixes while playing Doom to cause conflict with the "SPID" sprites. As a visual example, here's how I addressed the ZDoom conflicting sprite names for the Iron Lich in the Heretic fixes (left) and how the same fix would look for the Stalker in the Strife fixes (right). However, the Stalker is not the only Strife sprite that requires renaming due to conflicting names. Check the full Strife list here. To summarize, the following Strife sprite fixes don't work in ZDoom at the moment and would also need renamed duplicates:

Hello there, Doomworld! You may remember me as the creator of such WADs as 100,000 Revenants, Infinite Revenants, and The Revenant Problem. Today, I come to you with the fourth installment in the Revenant quadrilogy. Reviewing the responses to previous entries, it's clear the Doom public desires two things: More Revenants and more public transportation. Not one to question the demands of the masses, I bring forth a new paradigm in bus-centric Doom WADS, a hyper realistic simulation known as Revenant Bus. Revenant Bus is a Boom-compatible 7 level episode for Doom 2 that's aimed at casual players and hardcore speedrunners alike, for all are equal in the eyes of the WAD's featured foe: time itself. I elaborate further on the premise in the preview video below, but you can also read a text summary here. Download RC2 (updated October 30): https://drive.google.com/file/d/1snVmlyeYCoRPxILq2aM_syjKxfhEh387/view?usp=sharing Preview image: Preview video:

The Arachnotron's firing frames could be centered significantly more (more than I feel would be prudent in terms of the scope of the fixes), but that would still result in the plasma balls firing too high from its eyes. When it comes to demon projectiles visually matching the position they should emit from, Doom has a pretty spotty track record. The Cyberdemon's rocket comes from his crotch, the Mancubus' fireballs emit out of his belly, and the Revenant offers the most egregious sight as he clearly fires two different shoulder-mounted launchers simultaneously yet only produces a single missile every time! (Boy, I really hope somebody got fired for that blunder!) Ultimately, making a monster's projectile origin visually match the position on the sprite is not something that can truly be fixed from the art side, hence this goal isn't within the scope of the project. Realistically, fixing this the proper way (i.e. with code) is rife with issues, so it's just a quirk we have to live with. For anyone who isn't clear, this is suggesting that the Cyberdemon's firing frames should be always lit. Well, you're in luck, as this fix has already been made in the Doom 1 and 2 Minor DeHackEd Fixes which are included in the Minor Sprite Fixing Project as an optional DeHackEd-based augmentation! As mentioned above, the offsets on decorative objects have rarely been touched over time as their placements by map authors can be very precise and deliberate. Shifting things even a few pixels can make a big visual difference in Doom, especially with these objects that are assumed to be fixed and static, so moving the artwork around is not something mappers could account for. Additionally, one other aspect I didn't mention above is that, while centering sprites makes reasonable sense on a technical level, it's clearly not an aim id's artists were striving for when it comes to the decorations. Hence, it's not really wrong or an error. Again, this is more like another quirk that's just become so deeply ingrained in the games.