Sprites Doom 2 Minor Sprite Fixing Project - v2.0 Release (updated 11/28/22)

[Revenant100]

On 12/19/2023 at 12:18 PM, Dragonfly said:

I've taken the time to look at the WAD and notice that loads of assets irrelevant to improving offsets are included from Eviternity II - before I feel comfortable merging this into the main release of Eviternity, could I please be a colossal pain in the ass and ask that you reduce the wad down to only the amended assets?

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.

Edited December 22, 2023 by Revenant100

[Dragonfly]

Awesome thank you! I've just implemented this into Eviternity RC3, which will be released soon. :D

[maxmanium]

I noticed that the compatibility patch for Dimension of the Boomed seems to have mis-matched CWILV lumps. Are these a leftover from an earlier release?

[Revenant100]

5 hours ago, maxmanium said:

I noticed that the compatibility patch for Dimension of the Boomed seems to have mis-matched CWILV lumps. Are these a leftover from an earlier release?

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.

[saturian1]

I just noticed that this spritefix has an issue in Not Even Remotely Fair: https://www.doomworld.com/forum/topic/127913-not-even-remotely-fair-32-maps-for-doom-ii-nightmare-difficulty-only-all-original-soundtrack/

 

The silver chaingunners (which are SS replacements) have SS's regular sprite in one frame (they flicker between a chaingunner and a nazi). If I don't load the .deh file, there's no issue.

Edited December 29, 2023 by saturian1

[Revenant100]

45 minutes ago, saturian1 said:

I just noticed that this spritefix has an issue in Not Even Remotely Fair: https://www.doomworld.com/forum/topic/127913-not-even-remotely-fair-32-maps-for-doom-ii-nightmare-difficulty-only-all-original-soundtrack/

 

The silver chaingunners (which are SS replacements) have SS's regular sprite in one frame (they flicker between a chaingunner and a nazi). If I don't load the .deh file, there's no issue.

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.

[saturian1]

1 hour ago, Revenant100 said:

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.

I use:

dsda-doom -iwad doom2.wad -deh D2SPFX20.DEH -file D2SPFX20.WAD nerf.wad

and the issue occurs.

All skills except NM are greyed out.

[Revenant100]

13 hours ago, saturian1 said:

I use:

dsda-doom -iwad doom2.wad -deh D2SPFX20.DEH -file D2SPFX20.WAD nerf.wad

and the issue occurs.

All skills except NM are greyed out.

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.

Edited December 30, 2023 by Revenant100

[saturian1]

1 hour ago, Revenant100 said:

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.

Thank you, now it's all good. I wasn't aware that there are cases where just manually placing files on the commandline can't replicate what autoload does.

[PhoenixCyanFire]

Any chance we get a smooth doom version of this? I would love to combine smooth doom with the sprite fixes

[Revenant100]

5 hours ago, PhoenixCyanFire said:

Any chance we get a smooth doom version of this? I would love to combine smooth doom with the sprite fixes

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.

[Flamsey]

Hey I was wondering if you could could make a version of this without the Lost Soul change, or at least let me know how I could change it back

[Revenant100]

46 minutes ago, Flamsey said:

Hey I was wondering if you could could make a version of this without the Lost Soul change, or at least let me know how I could change it back

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.

[pantheon]

On 3/2/2024 at 9:38 PM, Flamsey said:

Hey I was wondering if you could could make a version of this without the Lost Soul change, or at least let me know how I could change it back

 

Here's the complete Doom 2 sprite fix I use, I applied the fixed offsets but the lost soul graphic is the Doom 2 one. I like to use the sprite fix skulls for Doom 1 since that's what originally came with the game and you won't see them much otherwise.

 

D2SPFX20_OffsetOnly.zip

Edited April 14 by pantheon

[Flamsey]

Thanks so much! 

[Amaruψ]

I've always found the inconsistent and outright sloppy nature of DOOM sprites to be rather infuriating, so I simply cannot describe how much I appreciate the effort that you've put behind this. You've done a tremendous job and I can't thank you enough.

 

There is still something that you might've overlooked (or if someone has already mentioned it in the thread, since I haven't read the whole 30 pages, so apologies if you're aware of this issue already ^^;). The pump action shotgun's pumping frame has an inconsistency that bugs me. In the first frame, the barrel appears to be longer than the magazine tube. However, in both of the subsequent frames, they're both of the same length.

 

 

Looks like either Adrian or Kevin made changes to the barrel's length for that particular frame and forgot to update the other two. The beta sprites confirm that at one point the barrel in that particular frame was the same length as the magazine tube.

 

 

I'd love seeing this inconsistency to be fixed.

 

I've already made a sprite by creating a Frankenstein's shotgun, combining the current shotgun sprite with the beta to create a sprite that fixes the issue, though I'm not confident in releasing it as is, because it feels silly to make a .wad that simply fixes one single sprite like this :P

 

[NovaRain]

ChopBlock223 already made a set of tweaked classic shotgun with corrected tube magazine and front sight:

https://www.doomworld.com/forum/post/2748211

 

Compare to SFP sprites:

Edited March 21 by NovaRain

[Amaruψ]

11 hours ago, NovaRain said:

ChopBlock223 already made a set of tweaked classic shotgun with corrected tube magazine and front sight:

https://www.doomworld.com/forum/post/2748211

 

Quite neat actually. Far cleaner than my hackjob :P

[Revenant100]

18 hours ago, Amaruψ said:

There is still something that you might've overlooked (or if someone has already mentioned it in the thread, since I haven't read the whole 30 pages, so apologies if you're aware of this issue already ^^;). The pump action shotgun's pumping frame has an inconsistency that bugs me. In the first frame, the barrel appears to be longer than the magazine tube. However, in both of the subsequent frames, they're both of the same length.

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.

Edited March 21 by Revenant100

[Scuba Steve]

I completely agree with this assessment; minor sprite fix shouldn't wholesale change things that were intentional, even if they seem odd. Which does make me question again why the lost soul 'a' frame was reverted to an early build of the game when it was clear id changed the frames on purpose in a subsequent release. It's still my biggest complaint about this project and the one change that isn't a fix but a wholesale change.

[liPillON]

hello there! one question, since this thread has been bumped..

 

Have you ever considered (re)packaging this project as follows:

- one pwad for all common assets

- one pwad for DOOM.WAD specific assets

- one pwad for DOOM2.WAD/PLUTONIA.WAD/TNT.WAD specific assets

- two separate dehacked lumps, as usual

 

Most sourceports do not provide/recognize/support autoload folders dedicated to each "iwad family" so currently one should copy "D2SPFX20.WAD" in three different locations - this is redundant and a waste of space (albeit small, I'll admit)

 

Repackaging as suggested should also help you avoid having to keep track which lump has been updated and where (see the issue I brought up a while ago, about the BOSSB2D8 lump in D1SPFX20 being more up-to-date than the one in D2SPFX20)

Edited March 21 by liPillON

[Revenant100]

On 3/21/2024 at 5:22 AM, Scuba Steve said:

Which does make me question again why the lost soul 'a' frame was reverted to an early build of the game when it was clear id changed the frames on purpose in a subsequent release. It's still my biggest complaint about this project and the one change that isn't a fix but a wholesale change.

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.

 

On 3/21/2024 at 8:25 AM, liPillON said:

Have you ever considered (re)packaging this project as follows:

- one pwad for all common assets

- one pwad for DOOM.WAD specific assets

- one pwad for DOOM2.WAD/PLUTONIA.WAD/TNT.WAD specific assets

- two separate dehacked lumps, as usual

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.

Edited April 11 by Revenant100

[Bedingungsl.Grundeinkommen]

On 11/28/2012 at 8:51 AM, Revenant100 said:

 

 

The chaingunner moving like that (as in "before") seems intentional to me. Has this ever been discussed?

[The Almighty Egg]

4 minutes ago, Bedingungsl.Grundeinkommen said:

 

The chaingunner moving like that (as in "before") seems intentional to me. Has this ever been discussed?

https://www.doomworld.com/forum/post/1179241

It was one of the first points discussed here.

[Bedingungsl.Grundeinkommen]

18 minutes ago, The Almighty Egg said:

https://www.doomworld.com/forum/post/1179241

It was one of the first points discussed here.

 

Thanks. By the way I don't understand the explanation why he assumes there is an indicator for the animation not being deliberately like that, just saying. But I think it might be deliberate either way. Should we ask John? :D He mostly replies to stuff like this. 

[The Almighty Egg]

17 minutes ago, Bedingungsl.Grundeinkommen said:

 

Thanks. By the way I don't understand the explanation why he assumes there is an indicator for the animation not being deliberately like that, just saying. But I think it might be deliberate either way. Should we ask John? :D He mostly replies to stuff like this. 

For one, even if the vanilla doom sprite offsets are terribly auto centered, all of the monsters clearly stay in their footing when attacking. This kind of jittering you see on the Heavy Weapon Dude only appears in 3 of the 8 angles he was drawn at. 

[Revenant100]

9 hours ago, Bedingungsl.Grundeinkommen said:

The chaingunner moving like that (as in "before") seems intentional to me. Has this ever been discussed?

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:

Edited April 14 by Revenant100

[Notsee]

I see, interesting Mr Black

Edited April 17 by Notsee

[Bedingungsl.Grundeinkommen]

On 4/14/2024 at 4:23 PM, Revenant100 said:

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:

Awesome!

[Notsee]

I seem to have found a bug causing the sprites of the dead marines to clip through the floor