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

[Revenant100]

Not all of the muzzle flash sprites are in my sprite fixes as they weren't changed. You'll find the Pistol's muzzle flash sprite in the base DOOM2.WAD as PISFA0, and if you want to edit its position, you should copy this unchanged sprite to the sprite fix WAD and then adjust its positions there.

[fraggle]

Another minor dehacked fix: the Berserk Pack mistakenly has the fullbright flag set.

[Gez]

19 minutes ago, fraggle said:

Another minor dehacked fix: the Berserk Pack mistakenly has the fullbright flag set.

The synchronicity between this post and this thread is funny.

 

I don't think it's a mistake, all the other items that count for the endlevel tally are fullbright, and even "physical" items like the keys and armors blink between normal and fullbright. The medikits are not fullbright, but they are white, while the berserk packs are black and therefore harder to see in dark areas.

[seed]

1 hour ago, Gez said:

The synchronicity between this post and this thread is funny.

 

I don't think it's a mistake, all the other items that count for the endlevel tally are fullbright, and even "physical" items like the keys and armors blink between normal and fullbright. The medikits are not fullbright, but they are white, while the berserk packs are black and therefore harder to see in dark areas.

 

Even funnier that someone brought that topic of mine up here rofl.

 

I agree though, that the fullbright effect is most definitely on purpose for the same reason (visibility in the dark).

[NeoWorm]

On 9/23/2019 at 6:39 PM, Revenant100 said:

... plus there's the off chance that some unorthodox modding or source port may allow viewing of the uncropped areas.

I use weapon sway mod that offsets the sprites in various ways as you move andfully uses these uncropped sprites.

[fraggle]

3 hours ago, Gez said:

The synchronicity between this post and this thread is funny.

It's not a coincidence! I wasn't aware until this morning that the berserk pack glows in the dark.

 

I suspect the berserk pack was just copied from other powerups without much thought being put into it. It doesn't make a lot of sense to me that it has fullbright set while medikits don't, but I'll let @Revenant100 make the call.

[seed]

12 minutes ago, fraggle said:

It's not a coincidence! I wasn't aware until this morning that the berserk pack glows in the dark.

 

I suspect the berserk pack was just copied from other powerups without much thought being put into it. It doesn't make a lot of sense to me that it has fullbright set while medikits don't, but I'll let @Revenant100 make the call.

 

Logically perhaps not, but I expect it was a conscious decision from id to make it that way because it's actually quite easy to miss in dark areas during regular play, especially at low resolutions. Medkits didn't need this since they're white and stand out a bit more as a result, Berserk packs, dark thing in darkness... not so much, and fullbright makes them easier to spot from a distance.

 

They're also power ups, another reason to back this choice as it creates distinction and suggests they're more than "just health refills".

Edited November 5, 2019 by seed

[fraggle]

1 hour ago, seed said:

I expect it was a conscious decision from id to make it that way

I think it's a pretty big assumption and I'm pretty skeptical. I can certainly agree with you that there are probably some good reasons to keep the fullbright flag regardless and that's why I'll be happy with whatever decision Revenant100 goes with. 

 

We can look at some of the source material to judge whether this was a deliberate choice or not. In this case the file to look at is the (rather obscure) multigen.txt file that was used to generate Doom's state tables. It looks like this:

;
; Strength (Berserk)
;
S_PSTR PSTR A* -1 NULL S_NULL

In the syntax of multigen.txt, the fullbright flag is added with the '*' character next to the 'A'. It's pretty subtle and would probably be easy to miss when editing the file. We can probably assume the line was copy/pasted from one of the surrounding sprites (like the Invincibility sprite immediately above, for example). All the surrounding entries also have the fullbright flag set, which is why I suspect this wasn't intentional.

[seed]

@fraggle Hm, perhaps it was an oversight originally, but I would not be so sure about that, because reportedly, in older versions of Doom power ups were not actually fullbright. Watching this video of Shareware 0.99 and paying attention to some of the Soulspheres in dark rooms reveals that they are actually not glowing in the dark (see 9:28 for an example, the visibility of the Soulsphere on the pedestral is affected by the flashing light).

 

If they were originally not fullbright, altering them all to be fullbright sounds like a pretty conscious decision to me.

[Revenant100]

It's easy to see how a fullbright sprite or lack thereof can go overlooked given that's essentially what we can identify happened with the monster firing frame errors that have already been addressed by the DeHackEd patch. However, those follow straightforward and logical rules (monster muzzle flash = fullbright, no muzzle flash = no fullbright), whereas the items and power-ups are more up for debate. Without a clear answer as to id's intentions, I can see a lot of arguments being made either way in the case of the Berserk's fullbright sprite, but given the secondary priority of the DeHackEd alterations, particularly with respect to avoiding potential conflicts with mods, it's generally best to stick with consistency and err towards the status quo.

 

For the Berserk, it seems it follows the rule that all power-ups (as defined by the idbehold cheat) should glow. The only slight exception is that the Light Amplification Visor blinks rather than glows constantly. Ergo, the Berserk should remain fullbright to stay consistent with the rest of the power-ups. Of course, the definition of "power-up" starts to become muddled when you consider the source code and the manual, but the DeHackEd fixes aren't the focus of this project to warrant such semantics.

[NightFright]

GZDoom on GitHub just received a fix for that, it seems it was forgotten to make the Berserk Pack fullbright at all times.

[seed]

1 hour ago, NightFright said:

GZDoom on GitHub just received a fix for that, it seems it was forgotten to make the Berserk Pack fullbright at all times.

 

I doubt it was forgotten, I seem to recall seeing some discussions about this in the past and it was not changed back to fullbright at the time because, you guessed it, it was assumed that the Berserk being fullbright was a bug.

 

I'm glad they finally fixed it this time.

Edited November 6, 2019 by seed

[ChaoticReverie]

Hello!

 

I have a question regarding the changelog for the last version. Way back in ancient times, I made edits to the Spider Mastermind using version 1.2 of this mod. Years go by and new versions come and I'm here now seeing edits were made to certain sprites to remove a purple pixel. What the changelog doesn't say is what sprites those were? I'm wondering (Without going over all of them pixel by pixel!) if those changes might conflict with my old edits I did.

[Revenant100]

Spider Mastermind frames SPIDA4A6, SPIDG5, and SPIDH5 contain one purple pixel each. Here's a side-by-side highlighting them:

 

These purple pixels are notable because they're among the very few sprites in the game to use the PLAYPAL's limited purple range. More importantly, unlike the Partial Invisibility, Cacodemon Fireball, and other similar sprites, these are unintentional uses of the purple range which we can trace back to the digitization process and wasn't caught in the artwork cleanup.

 

The reason these particular purple pixels warranted action, aside from being a demonstrably unintentional use of the deliberately underused purple range, is that WAD authors who commandeer the palette's limited purple range for their own use with a custom PLAYPAL lump and accordingly modify the Partial Invisibility, Cacodemon Fireball, Lite-Amp Visor, and so forth to replace the purple pixels in those sprites often overlook also modifying these affected Spider Mastermind frames as well, resulting in unintentional colors appearing on the big momma spider. Hence, this is a fix that visually benefits both IWADs and PWADs alike, and it doesn't even require PWAD-specific patches to achieve that.

[ChaoticReverie]

That was very detailed! And interesting too, I had no idea about that at all. In my time playing Doom I never noticed this and I can only imagine someone with good eyes could see such a thing. That picture answered my question too, I can see that none of those rotations affect my edits.

[Annul]

How would I go in adding this sprite fix to the Plutonia and TNT WADs so I can try them out in DOSBox?

I have tried using DeuSF, but it seems to only work on the original Doom WADs.

Bit of weird question I know, but I'm just curious.

[Revenant100]

3 hours ago, Soothe said:

How would I go in adding this sprite fix to the Plutonia and TNT WADs so I can try them out in DOSBox?

I have tried using DeuSF, but it seems to only work on the original Doom WADs.

A more manual method utilizing a modern tool would be to use SLADE to open up the sprite fix WAD (d2spfx19.wad), copy the sprite graphics, and then paste them into both of your Final Doom IWADs, plutonia.wad and tnt.wad. Specifically, you'd append them to the bottom of the sprites list before the "S_END" lump.

 

Edit: Scratch that. The original DOS executable doesn't like dealing with so many duplicate lumps.

 

A working way is to download the full sprite fix resource WAD, open it in SLADE, copy all of the sprites (everything between the S_START and S_END lumps), open your Final Doom IWAD (either plutonia.wad or tnt.wad), delete all of the sprites (same as before, everything between the S_START and S_END lumps), paste the sprite fix's sprites back into this space, and then save the IWAD. This is effectively what DeuSF and Chocolate Doom does with their "-merge" parameters.

 

Another option is to load the aforementioned full sprite fix resource WAD as a PWAD with the "-file" parameter on top of Plutonia or TNT which the game will accept since it overrides all sprites by default. However, some of Doom 2's resources will override the unique Final Doom resources, like the title screen, intermission screen, map names, and other menu graphics. You can edit the full resource WAD in SLADE to delete the offending overriding lumps.

Edited March 17, 2020 by Revenant100

[maxmanium]

I thought modifying the IWADs was a no-no. Does this not cause any issues, then?

[D88M3R]

Awesome, this, smooth Doom and the neural think that makes everything look bette rmight be the way to go.

[Annul]

19 hours ago, maxmanium said:

I thought modifying the IWADs was a no-no. Does this not cause any issues, then?

If you're using a source port then yes, that is a no-no.

In my case, the original Doom.exe doesn't have the ability to "merge" original files, so I'm fully aware that I'm making a "different" IWAD. (Not that would change anything, this sprite fix alongside the .deh doesn't seem to desync any demos).

19 hours ago, Revenant100 said:

A more manual method utilizing a modern tool would be to use SLADE to open up the sprite fix WAD (d2spfx19.wad), copy the sprite graphics, and then paste them into both of your Final Doom IWADs, plutonia.wad and tnt.wad. Specifically, you'd append them to the bottom of the sprites list before the "S_END" lump.

 

Edit: Scratch that. The original DOS executable doesn't like dealing with so many duplicate lumps.

 

A working way is to download the full sprite fix resource WAD, open it in SLADE, copy all of the sprites (everything between the S_START and S_END lumps), open your Final Doom IWAD (either plutonia.wad or tnt.wad), delete all of the sprites (same as before, everything between the S_START and S_END lumps), paste the sprite fix's sprites back into this space, and then save the IWAD. This is effectively what DeuSF and Chocolate Doom does with their "-merge" parameters.

 

Another option is to load the aforementioned full sprite fix resource WAD as a PWAD with the "-file" parameter on top of Plutonia or TNT which the game will accept since it overrides all sprites by default. However, some of Doom 2's resources will override the unique Final Doom resources, like the title screen, intermission screen, map names, and other menu graphics. You can edit the full resource WAD in SLADE to delete the offending overriding lumps.

Thanks for your instructions, I'm going to try it out.

EDIT: Managed to do it, works well enough, thanks.

Edited March 18, 2020 by Soothe

[Lila Feuer]

I'm noticing the small red/green/blue torches and evil eye decor objects are "dancing". Playing in Doom Retro via Doom 1.

[maxmanium]

12 minutes ago, Lila Feuer said:

I'm noticing the small red/green/blue torches and evil eye decor objects are "dancing". Playing in Doom Retro via Doom 1.

 

Set r_fixspriteoffsets to off. Presumably you shouldn't need that on anyway since that's one of the features of these fixes.

[Wadmodder Shalton]

There's also these findings mentioned in decino's videos on DOOM's graphics:

 

 

 

Basically the latter mentions the skull switch textures that are aligned very sloppy.

 

I wonder if you can fix those skull switch textures. 

[maxmanium]

2 hours ago, Wadmodder RiderPùdu said:

I wonder if you can fix those skull switch textures. 

 

It'd be nice, but it would mess with any map ever using those textures, so they have to be kept.

[Revenant100]

3 hours ago, Wadmodder RiderPùdu said:

Basically the latter mentions the skull switch textures that are aligned very sloppy.

 

I wonder if you can fix those skull switch textures. 

Unfortunately, there are two main reasons why the alignments on the switches will not be fixed:

1. The skulls in the switch textures are poorly centered due to the alignments of the individual patches as defined in the TEXTURE1 lump which is where all of a WAD's texture definitions lie, namely new ones that a level can use. Even if I were to fix the patch alignments and provide the modified TEXTURE1 lump, it would be completely overridden by a loaded PWAD's own TEXTURE1 lump, undoing the fix. A vast majority of custom maps provide their own TEXTURE1 lump, so there are relatively few levels where a fix would actually take affect. (I'd also have to create separate fixes for each IWAD, but this is moot in light of the aforementioned point.)
2. And, as the even bigger matter, the positioning of elements in any texture won't be touched in general as every map in existence is expressly dependent on the current alignments. The visuals in many levels will break if things in the textures get shifted around, especially on switches as they tend to be used with precise alignments. There's nothing that can be done from the fix's end to account for this.

There are many insurmountable technical difficulties when considering fixes for things like maps, textures/patches, music, and so forth, hence one of the reasons why this project limits its scope primarily to sprites.

[Lila Feuer]

Besides I didn't notice until it was pointed out, even then I still don't notice during the game, so it's an extremely minuscule "issue".

[DarkShotX45]

Is it just me, or are the weapons not fully centered?

[maxmanium]

53 minutes ago, DarkShotX45 said:

Is it just me, or are the weapons not fully centered?

 

They look fine to me.

[Revenant100]

1 hour ago, DarkShotX45 said:

Is it just me, or are the weapons not fully centered?

Which weapons do not appear to be centered to you?

For reference, this illustrates the current centered offsets of the weapons:

 

Centering was based on the weapon sight or the closest analog, i.e. the Chaingun's center barrel. For weapons that have perfectly mirrored sides aka even pixel widths (Pistol, Shotgun, Super Shotgun, Chaingun), the offsets place the weapon center straight down the middle. Can't get any better than that. For weapons that have uneven widths (Rocket Launcher, Plasma Rifle, BFG), their weapon center was chosen with a bias of one pixel to the left since that errs towards how id's artists originally centered the sprites, and they literally cannot be centered any better than that. The remaining Fist and Chainsaw are asymmetrical and had no adjustments made to their offsets in terms of centering.

And here's an example comparison to give an idea of how the offset adjustments actually affected the visual weapon center:

Edited April 11, 2020 by Revenant100

[DarkShotX45]

So some weapons are off by 1 pixel?

I really need to stop nitpicking because of an extremely minor thing...

Thanks for the answer