Revenant100

Are you certain you're actually loading the sprite fix WAD? The only way part of the sprite fixes could be working while other parts are not is if there's an additional PWAD being loaded at the same time which overrides a portion of the sprite fixes. To be absolutely certain you're loading the sprite fixes, can you take a picture of the Rocket Launcher firing frame with the visible hole and also a picture of the Super Shotgun in its idle state (to see if the erroneous brown pixel is there)?

As mentioned, many of Doom's and Doom 2's graphics were merely aligned through some manner of auto-centering that was entirely unbecoming of how the sprites were originally intended to be animated, hence the initial offset adjustments. This fix (both the specific Heavy Weapon Dude adjustments and this type of offset tweaks in general) was verified by the release of Romero's sprite sheets a few years later. For convenience, here's an animated version of the Heavy Weapon Dude's attack sprite sheet demonstrating how Adrian illustrated and ultimately intended this sequence to look:

While perusing the net, I stumbled across this trailer for the 3DO port of Doom: (Original upload with presumably better quality) Sourced from a sales tape meant for retailers, what we have here is early footage of the 3DO port (presumably mid '95, while the port itself released in '96) featuring an unseen new level and a look at the fabled long lost new weapon! Why even the performance looks perfectly stable at a full screen size, but I think we can all agree, however, that the most impressive aspect on display here is the huge uptick in graphical quality, almost looking like pre-rendered footage there at the end! Shame the final release wouldn't end up managing these upgrades.

I'll begin by pointing out that "it was clear id changed the frames on purpose" is certainly not true. We have absolutely no idea why the sprite changed between versions, only able to theorize based on the evidence available to us. I've gone over a majority of this before, but I'll reiterate the Lost Soul stuff now for the sake of discussion and since it's been a while. The first clue that something is wrong with the current Lost Soul sprites (introduced in version 1.666 of Doom 1 and Doom 2) is identifiable simply by looking at them: Without any knowledge about Doom's art, the specifics of Doom's development, the technicals of game art in general, or any sort of critical eye whatsoever, being abundantly perceivable to even the most average of laymen, it's obvious something is wrong here. Not just wrong, but glaringly wrong. Doom's artwork can be rough and unrefined at times, but this is egregiously broken beyond belief. I don't think it's necessary, but just to break down the technical issues point-by-point: Forehead and chin (most of his face, really) lighting flickers Jawline changes shape Horns change shape Teeth flicker between being teeth and fire Fire clearly shifts vertically between frames which is not part of the fire animation (as evident by part of the horns shifting as well) And this is simply the result of a cursory glance with no additional knowledge. Once you start taking the rest of Doom into account, even more problems become clear. Let's put the current front-facing Lost Soul sprites next to the adjacent "2/8" angle rotation frames and (getting a bit ahead of myself here) the original 1.1 front-facing frames: In addition to the aforementioned points, the 1.666 Lost Soul sprites prove themselves even more broken in their jarring lack of basic consistency: The 1.666 fire is animated in a completely different style (see the accompanying "3/6", "4/7", and "5" angle rotations for further corroboration) The 1.666 brow and nose are completely different from what's seen in the "2/8" angle rotation (instead matching the original 1.1 sprites) So the conclusion at this point is that the current 1.666 Lost Soul sprites are erroneous, and quite hideously so. If one can't accept this, then I'm afraid there's not much reason to continue reading this post because this is the matter that's going to be derived from onward. The question at this point is, how do we fix this problem? This is undoubtedly the largest art error in the entirety of the Doom IWADs, the only instance coming close being the incorrect Rocket Launcher firing frame (which is actually a code issue of the wrong state being displayed, but the resulting issue is visual nonetheless). Again, taking nothing else into account, there's two options: 1. Do nothing, or 2. Heavily redraw both frames to bring some semblance of functionality and consistency. Given the nature of this project, the first option would genuinely have been the leading candidate. As it turns out, however, despite the magnitude of the errors, the fix was astonishingly straightforward. I don't know how else to frame the proceeding since it's so simple, but id shipped registered Doom 1.1 with correct Lost Soul sprites. We just celebrated the game's 30th anniversary, so I think it bears worth remembering what the game actually looked like at this time, this 1.1 Lost Soul included. I used the correct 1.1 frames to fix the error that id introduced later on in 1.666, the 30th anniversary of which won't come until a later date this year marking Doom 2's release. And that concludes the identification of the error and how it was fixed. Note everything above is purely objective. There were flagrant technical and consistency errors with the art in question, and the developer's own work was used to rectify the matter. Simple as that. Even filling in a single missing pixel in the art requires immensely more manual work and personal judgment (i.e. "some" as opposed to "literally none") than what was needed to fix the Lost Soul. With the objective part out of the way, let's move on to address the subjective part of identifying how the 1.1 sprites are the intended ones. I say "subjective" because we don't have a verifiable and forthright declaration stating this, but the evidence is overwhelmingly in this regard. The first thing to note is that, after the 1.0 shareware release, the sprites in Doom rarely changed in any subsequent versions. Yes, the menu screens (F1 help, ordering screen, team credits, etc.) did see tweaks, but the in-game art remained virtually untouched since that initial release. The most we saw was some fairly significant sprite offset adjustments to the Imp and Spider Mastermind, incidentally serving as an important reference point for how further offset adjustments would be performed in the Sprite Fixing Project. Then came version 1.666. While a momentous version number, this is more easily recognizable simply as the release of Doom 2. For the first (and essentially last) time, existing sprites received some notable visual changes. Of course, there's the changed front-facing Lost Soul frames in question (note that this is just the front-facing frames and no other rotations), which as mentioned are inexplicable to this day. However, that's not the only alteration, as the Baron of Hell's sprites received two changes. The thing is, we can identify both of these changes as being clear and unambiguous mistakes. The Baron's second firing frame was reverted to a pre-1.0 version (see the suddenly glowing hooves and horns for one frame), and the Baron's pants darken for no reason on death (which we can easily tell was the Hell Knight's darker legs inadvertently being carried over somehow). So out of the three sprite changes in Doom 2, two are unarguably errors. Why, in the same update that introduced indisputable sprite errors, would id's artists decide to change two, just two, sprites at this time and only this time? Considering that even one error being introduced at this stage to something that had remained fine and untouched since the beginning is bizarre, it's not a huge leap to regard all three of these changes as falling under the same "unintended error" umbrella, especially considering how broken the 1.666 Lost Soul sprites look on their own. Also take note that these unambiguous Baron of Hell sprite errors were fixed in precisely the same fashion as the Lost Soul sprites: restoring the original sprites from the previous 1.0/1.1 versions. Again, more credence to the notion that they're all errors made in the same fashion. But that's not the only surrounding history we can glean context from! Doom didn't stop at Doom 2, so let's start by taking a gander at the following which constitutes the unique official instances in which the original 1.1 Lost Soul appeared: Doom 1.1 up to 1.666 Doom's box and marketing screenshots (closest time we ever saw the Lost Soul in 1.0 since the shareware lacked Episodes 2 and 3) Atari Jaguar port (made by id) 32X port (source provided by id) 3DO port (source provided by id) PS1/Saturn ports (source provided by id) Doom 2 strategy guide (showing pre-release version) Doom 2 pre-release footage Note that the ports were made during/after Doom 2, and note that the presence of the original 1.1 Lost Soul sprites in the Doom 2 guide and pre-release footage suggests that this was an extremely late 1994 change (i.e. likely an error made at the last minute). Obviously, the 1.1 Lost Soul was what was always in the source provided by id to port developers, but note that even Williams, making a Doom 2-derived port, used the pre-1.666 Lost Soul despite incorporating 1.666+ Doom 2 assets. This is not to say it was a conscious choice, rather that this was in the Doom 1/Doom 2 source that id provided them. As for where the 1.666 Lost Soul sprite was specifically introduced: Doom 1.666 and onward/Ultimate Doom Doom 2 And that's basically it. Note that virtually all later versions/ports of Doom and Doom 2 were not built directly from sources provided by id but rather the final compiled DOOM.WAD and DOOM2.WAD IWADs (See SNES Doom which famously was not built from any sources from id, hence ending up with the 1.666 Lost Soul). This was typically version 1.9 for both, hence these later releases merely inherited the erroneous 1.666 Lost Soul through id's earlier doing rather than introducing it by design. Of course, this was hardly the only error that would be passed on to this very day simply because id introduced them later on in those early days (See the stuck Sergeant in MAP02). And yes, I will immediately predict what someone will want to bring up: this 2014 tweet from Romero which is meant to counter all of the above evidence. To that, I invite you to truly think about the response Romero made here and whether or not it actually makes sense. Does the Lost Soul really "look better" now? Is this the kind of quality of work that Adrian would commit? Why would Adrian make this edit so late in Doom 2's development? Why were only the front-facing frames edited, thus creating an inconsistency with the adjoining rotations? Why would this be the sole post-release sprite edit in the entire history of registered Doom/Doom 2 in that era? There certainly wasn't a lack of other errors to notice at the time. Also consider the fact that, as kind as Romero is to humor our questions about matters long past, he has been mistaken before. He misidentified Adrian's Arch-vile art (later confirmed by Adrian himself), wrongly claimed Quake's Shambler has fur (later confirmed by Adrian himself), claimed the "DS" in Doom's sound names stands for "Demon-Spitter" (?), and so forth. This is not to knock on Romero. This is simply to highlight the reality that people's memories aren't infallible about minuscule, obscure, and inconsequential details, especially 30 years after the fact. id alumni are just as susceptible as anyone to making such simple slip-ups (See: "Hi Sandy, hope you’re doing well"). Also note here that we can see several of Romero's mistakes are in regards to Adrian's work. Again, as much as Romero can recall the past, perhaps it's reasonable to acknowledge that he can't speak for everything on Adrian's behalf whose own thoughts and intentions from 30 years ago he may simply not know. This is a whole lot of words and over elaboration, so I'll summarize all this with a TL,DR: id introduced erroneous Lost Soul sprites in a later version of Doom. The correct sprites from their original release were substituted in to fix their error. That's it. To keep the use of the sprite fixes as simple and foolproof as possible, the PWADs won't be split up any further. The sprite fixes are aimed for use by everyone at any level of Doom experience, including completely new players, and keeping the WADs relegated simply to "Doom 1 fixes for Doom 1" and "Doom 2 fixes for Doom 2 and everything else" is the most intuitive way of going about it, plus being as irreducible as can be. The reduction in redundancy for some file size savings is just be too negligible to warrant a shift in usage at this time. Also, after 11 years of being out there and in (still ongoing) development, changing the packaging format now would cause too much confusion for very little gain. Simply put, dealing with two WADs is easier than dealing with three WADs.

This is an inconsistency, but it's not necessarily an error on id's part. In fact, as you pointed out, the change to the SHTGB0 sprite (PSHOB0 in the earlier beta builds) was part of the ongoing cleanup and refining of the Shotgun artwork as development went on, this particular edit to the length of the barrel occurring some time between beta 0.5 and the press release beta. In other words, this change was a very conscious decision by one of id's artists, so it's not an objective error that falls within the scope of the project since id deliberately intended for the sprite to look like this. When it comes to inconsistencies, this isn't even the most egregious instance on the Shotgun sprites alone. The idle frame originally had a massive ring around the end of the barrel which is what the sight is attached to, also still visible on the original TootsieToy Dakota. Despite this ring being completely eliminated in the final idle frame, it magically reappears in all successive reloading frames. The game is replete with these sort of inconsistencies in the sprites, but this project limits its scope to the clear errors/mistakes/oversights on id's part, mostly of the technical kind, with the accompanying fixes being suitably minor. Addressing such aforementioned inconsistencies requires a large amount of original and redrawn art, and these aren't explicitly "fixes" in the sense that an error is being corrected (i.e. instead of shortening the Shotgun's barrel in one frame, why not extend it in the other two, hence more closely adhering to id's intentions in what we can identify as the newest frame?). That is ultimately an entirely different and, mostly importantly, subjective endeavor.

An alternate version that undoes fixes wouldn't be made as that's in direct contradiction to the purpose of the project, nor would it be possible to create enough versions to accommodate all possible individual personal preferences for the original errors, hence why the aim is purely for objective fixes, not a subjective and arbitrary middle ground. However, modifying any of the sprite fix WADs on your own to omit any included fixes is simple and has always been encouraged: Download SLADE, open up the appropriate sprite fix WAD in the program, find the two graphic lump entries named "SKULA1" and "SKULB1", delete both of them, and save the WAD. This particular change requires no further edits, so when you next run the modified sprite fix WAD, the game will default to the base IWAD resources for these two Lost Soul sprites.

That's entirely up to the Smooth Doom authors. That said, Gifty's original Smooth Doom already incorporates several of the Minor Sprite Fixing Project's assets, but not all of them.

These are Eviternity II's front-facing 1.666+ Lost Soul sprites from before the sprite fix incorporation: ev2_oldlostsoul.zip The Lost Soul is not visually affected by the new palette, however, so the converted color indexing doesn't actually change anything.

I've dug deep into the matter, and I've determined that this issue is related to an incorrect loading order but is not caused by the sprite fix WAD itself. Rather, the issue you're experiencing is being caused by the DeHackEd fixes (D2DEHFIX.DEH) being loaded in the wrong order. Just as is the case with the sprite fix WAD, the DeHacked fixes DEH patch must be loaded with the lowest priority, or before any additional PWADs, DEH patches, and so forth. In this case, the DeHackEd fixes are overriding the embedded DeHackEd patch included inside NERF.WAD, causing the wrong SS frame to display on the silver chaingunners. The problem here is that, when loading a DeHackEd patch through a launch parameter, there's no guarantee what order it will load in relative to the WAD files in the file parameter, and this behavior may even vary between different source ports. But as before, if you do intend to run the Minor Sprite Fixing Project (and the accompanying Minor DeHackEd Fixes) on a regular basis, I highly recommend simply using your source port's autoload function. This ensures everything is always loaded with the correct priority, and I just confirmed as such in DSDA-Doom. In this case, you would take both D2SPFX20.WAD and D2DEHFIX.DEH and place them in DSDA-Doom's "autoload\doom2.wad" folder. However, there's one caveat here that makes this particular situation moot: As Peter pointed out in the NERF thread, you do not need to load the Minor DeHackEd Fixes alongside NERF as NERF already incorporates these fixes in the PWAD's embedded DeHackEd patch. Thus, you can just ignore D2DEHFIX.DEH when you want to play NERF, but do note that the above autoload suggestion will still work and circumvent of all possible conflict scenarios.

This is indicative of running NERF with the incorrect WAD order. Another telltale sign of using the wrong loading order is the difficulty selection screen still saying "Hey, Not Too Rough" when all non-Nightmare options should be grayed-out with the "Out of Order" sign overlaid on top of them. The main sprite fixes must be loaded with the lowest priority, or before any additional PWADs. There are no reasons to ever load the base sprite fix WAD after any PWADs. That must only be done with compatibility patches. In this case, your launch parameters while running NERF should look something like this: dsda-doom.exe -file D2SPFX20.WAD NERF.WAD If you use the Minor Sprite Fixing Project on a regular basis, I recommend adding it to your source port of choice's autoloaded WADs to ensure it is always loaded with the correct priority in the loading hierarchy.

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.