Revenant100

Yes, you're right. I've just made a small update to the Dimension of the Boomed compatibility patch to correct these old graphics lumps.

Also available: Heretic Minor Sprite Fixing and Widescreen-Friendly Project - v1.0 Release SIGIL Sprite Fixing Project SIGIL II 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.

SLADE's built-in "Remove duplicate entries" option can perform this task in a jiffy, which I've gone ahead and done for you as requested here: (Obsolete, do not download!) Note that this trimmed WAD includes "VILE\*" lumps which have not appeared in either of the Eviternity II RC versions. This was an additional fix I forgot to mention in my above changelog. The absence of these particular Arch-Vile sprites is presumably due to your build process misinterpreting the back slash in these lump names being part of some directory structure, thus omitting them in the WAD builds. This omission did not actually have any visual effect in Eviternity II since these particular Arch-Vile frames (the second in his resurrecting state) don't use any of the new palette's modified colors and thus worked just fine even without the palette re-indexing. However, omitting these frames from the sprite fixes would have a slight visual consequence since, although the graphics themselves are identical, the adjusted sprite offsets would be missing.

I've completed the extent of the sprite fixes I was aiming for in Eviternity II and am releasing this new version right now. This is a minor update, but it does fulfill my goal of bringing the rest of the new monsters in line with the original monsters in terms of sprite offsets which offers a nice visual improvement in motion. I've also gone through an adequate amount of testing by now, and no abnormalities have cropped up. Thus, this compatibility patch is essentially in its final state barring any reports/suggestions and any forthcoming release candidates from Eviternity II itself which may warrant future sprite fix updates. All download links for this compatibility patch in this thread have been updated which I'm also copying here for convenience. As of this writing, this release of the sprite fixes is compatible with the "RC5" build of Eviternity II. Eviternity II compatibility patch (load the sprite fixes after "Eviternity II RC5.wad"): D2SPFX-Eviternity2-RC5.zip (2.5 MB) NOTE: Eviternity II now officially incorporates these fixes already. Here's the changelog for everything I ultimately did in this compatibility patch: And just for fun, here's one animated demonstration of the effects of the sprite offset adjustments using the Duke of Hell's attack frames as an example:

These Eviternity II sprite fixes are absolutely all yours to integrate and use when you need. In their current state, the implementation is as simple as directly cutting the lumps from the sprite fix WAD and pasting them into the Eviternity II PWAD (and deleting the original lumps) since all graphics and sprites are included in the sprite fix WAD (which is a lot of unnecessary redundancy, but it helps make updating and maintaining future fixes much easier, and it happens to have this convenient benefit of making a complete and official integration into the base PWAD incredibly trivial). I still have further testing and forthcoming updates to make to the sprite fixes which will also naturally accommodate any relevant graphics changes the upcoming release candidates of Eviternity II will bring, so it would indeed be prudent to wait a little while before performing a full integration. And speaking of which, I can confirm that the current version of the Eviternity II sprite fixes is still compatible with the just-now-released "RC2" build of the PWAD, so no redownloading is necessary as its still perfectly applicable. For the main Minor Sprite Fixing Project, you only need to run D2SPFX20.WAD which has full compatiblity as-is with WadSmoosh's Doom: Complete package. When it comes to the Sigil sprite fixes, however, these are not compatible in their current form with the WadSmoosh editions of Sigil 1 and 2. Of course, Sigil 2 isn't supported yet by WadSmoosh, but the program renames the graphic lumps used by the two so they don't conflict with the default Doom 1 graphics. This means my Sigil sprite fix WADs will override the wrong graphics when loaded with Doom: Complete. I'm happy to create a WadSmoosh-compatible version of my Sigil sprite fixes, but I'll need to wait for Sigil 2 support to be added first so I know what to name my lumps.

Greetings again, this fine 30th anniversary! I come this time with yet another sprite fix project release, this time one that fixes actual sprites! You got it, I'm bringing you the initial work-in-progress release of the Eviternity II compatibility patch! Of course made for Eviternity II, the entirety of the relevant sprite fixes have been converted and will take effect on the unmodified monsters, weapons, items, and so forth. However, I've also gone a small step beyond and performed an offset adjustment pass on several of Eviternity II's new monsters, bringing them more in line with the rest of the project. This isn't going to be a full sprite fix pass on all of these new graphics, but I will be continuing on the cursory work I've started here for the sake of more consistency and to fix small errors I've found throughout Eviternity II's sprites. So without further ado, the download link has been added to the OP and is copied here as well for convenience. As of this writing, this release of the sprite fixes is compatible with the "RC5" build of Eviternity II. Eviternity II compatibility patch (load the sprite fixes after "Eviternity II RC5.wad"): D2SPFX-Eviternity2-RC5.zip (2.5 MB) NOTE: Eviternity II now officially incorporates these fixes already. Preview image: This sprite fixing project is in its effectively complete state. However, given the work-in-progress nature of Eviternity II, I recommend checking on this thread in the near future for further updates as new versions of the PWAD are released. Also, should you come across any sprite fix-specific issues, please report them in this thread.

Happy 30 years of Doom! And you know what that means! That's right, it's time for another sprite fix release for another SIGIL installment! Hence, I present to you this fine anniversary today the SIGIL II Sprite Fixing Project! While you've been playing the recently released hot new WAD SIGIL II, you've undoubtedly noticed something was wrong the moment you launched the game. Your instincts serve you well, for that's because you've noticed and been distracted by the very same error that plagued SIGIL I nearly half a decade ago: The new Christopher Lovell artwork included in SIGIL II is unnaturally stretched vertically by 20%. This is due to the fact that the aspect ratio was not considered when importing the graphics in the WAD. As such, I have yet again taken the liberty of tracking down the original artwork and redoing the new graphics while taking the aspect ratio correction into account. I also ensured that my adjustments and processing of the artwork was faithful and authentic to the appearance of the original SIGIL II graphic lumps. As of this writing, these sprite fixes are up to date with v1.0 of the WAD and are compatible with both the SIGIL_II_V1_0.WAD and SIGIL_II_MP3_V1_0.WAD versions of SIGIL II. Simply load SIGIL_II_V1_0_SPFX.WAD after either one. Download: https://drive.google.com/file/d/1hXHQb2zkgSteHXyoJPKYz4S-id1rbbaZ/view?usp=sharing Preview comparison: And also, I am aware of the release of Eviternity II and its dire need of sprite fixes. Do not fret, for a compatibility patch is now in production and on its way soon!

I appreciate the suggestions. In order to keep the number of compatibility patches I need to continue maintaining over time reasonable, I do limit the scope of what necessitates a compatibility patch in the first place. For the most part, this means the project in question is large enough to warrant the endeavor. As of now, all of the compatibility patches available are (or are planned to be) megawads in size (or close to it) with one exception. Dimension of the Boomed only consists of six real maps, but I created a compatibility patch at the time with the notion that these Quake-styled assets could serve as the base resources for future similar Quake-styled projects, hence the patch may have use beyond just this one PWAD. Were I posed with the same choice today, though, I would have to give the prospect some serious consideration. And therein lies the issue with the Nirvana projects you've mentioned. Breathless and Entropy are both single-level PWADs, and while they're undoubtedly grand in scale, they realistically don't meet the threshold for compatibility patches. Fractured Worlds, having eight real levels, is just on the cusp of what I would consider justifying the ongoing support of a compatibility patch, but there's one other factor at play here. Many of the overriding sprites included in Fractured Worlds are outright graphical edits of the original monster sprites, albeit mostly recolors. This means that I would have to manually redo the relevant sprite fixes on these edited sprites, and in some cases, it would necessitate accurately recreating the original color palette translations first, thus putting even more of the burden on me. Unfortunately, I can't commit to the creation and the ongoing support and maintenance of sprite fix compatibility patches for these particular PWADs. I don't want to end this on a down note, so I'll say this in regards to any and all future projects: I encourage map authors to integrate these sprite fixes of their own volition. For everyone else, perhaps feel free to inform said map authors of the open availability of such sprite fixes and that you would like to see them integrated into their projects. It by no means has to just be me to ensure sprite fix compatibility. As I've said from day one, this project is an open resource for use by the entire community. I've long provided the resources tailored for modders to make this a simple task, which several out there have already taken advantage of, and it requires no more work than what would already be needed to modify the original IWAD artwork. In the end, these sprite fixes have been around for quite some time and won't be going anywhere, the greater awareness of and their adoption rate will only continue to increase, and the development of the project isn't going to end any time soon. (And by the by, happy 11th anniversary to the Minor Sprite Fixing Project!)

You are correct in that the offsets for the burning barrel decoration are not intuitively centered which would be to put the barrel itself smack dab in the middle. However, it is technically centered when taking the blowing flames into account which spill over the edge. The offsets could be adjusted to center them in a more natural fashion, but the problem here lies in the fact that these sprites are not seen in dynamic, roaming positions like monsters. The burning barrel is a static decoration placed into its fixed positions by mappers. Sometimes these placements can be very precise, and when you alter the sprite's offsets, you end up breaking the mapper's intended visuals. Here are two examples of such burning barrels use that come to mind from All Hell is Breaking Loose MAP01 and TNT MAP02: These are not the best or most extreme examples as the centered offsets in these instances appear satisfactory enough, but they do illustrate just how much tweaking the offsets of decorations can alter the visuals that would never have been originally envisioned or could be accounted for by the mappers. The All Hell is Breaking Loose fireplace (an example of a sprite viewed from a fixed perspective as you can't circle around it) now has a strange open gap to the left side while the flame clips into the right brick wall. In TNT MAP02, the human barbecue visible as soon as you enter is the very namesake of the map, and with centered offsets, the fire doesn't seem to quite fill the eponymous barbecue pit, and the flame seems to be missing the hanging human corpse above. However, the hanging corpse decoration itself is intuitively (again, not technically) off-center. Hence, you can also see here the potential domino effect where adjusting the offsets of some decorations and not others can create problems, and while in this case both decorations could be centered so they at least maintain their relative positions, unavoidable visual conflicts would occur with other object combinations. The last thing to consider here is whether or not this is actually an outright error. While we can discern a lot of the intent about the intended sprite offsets for the monsters, there's no such evident aim from id's artists when it comes to the decorations. As I've alluded to in the past, this is another one of the game's quirks that's become deeply ingrained into what's been built with it in mind. Although there's certainly merit in the notion, centering the decorations in a more natural fashion is not truly a "fix", and it'll cause problems in both past and future WADs which makes it unsuitable for this project.

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.