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.

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: