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

Dunno if it's off-topic or not, but did anybody notice that brightmaps wouldn't work on sprites that are patched with these fixes?

NightFright said:

Dunno if it's off-topic or not, but did anybody notice that brightmaps wouldn't work on sprites that are patched with these fixes?

The standard GZDoom brightmaps have the "iwad" keyword in their definition, meaning that they will be disabled if the sprite is changed from the IWAD. Try playing something like Hacx 1.1 (the non standalone version), Aliens TC, or Batman Doom to know why it's a good idea.

You can fix that by editing the sprite fix wad to add the needed brightmaps and their definitions, and replacing "iwad" with "thiswad" in their definitions.

I see. The thing is this, I am using these sprite fixes in autoload. It makes sense, but it breaks the brightmaps for those edited sprites.

I also dunno if I can just put the PNGs into a WAD without any kind of manual realignment as it was done for these fixes. Maybe a new option besides iwad and thiswad may be considered to allow sprite overrides, but only from a specific file.

Example:
iwad
thiswad d2spfx16.wad

would allow brightmaps to be applied if sprites are coming from the iwad or a specific pwad (in this case, the sprite fix file d2spfx16.wad), but otherwise they would be ignored.

I guess this is a feature request for GZDoom and doesn't really belong here, but since these fixes are kinda important, it would be great to have an option to use both brightmaps and sprite overrides (without having to merge files) at the same time in specific cases.

NightFright said:

I guess this is a feature request for GZDoom and doesn't really belong here, but since these fixes are kinda important, it would be great to have an option to use both brightmaps and sprite overrides (without having to merge files) at the same time in specific cases.

To elaborate on this brightmaps issue, it would actually require a little more work than simply changing the wad designation in the definition file as several of the graphic lumps included in the sprite fixes WAD have been renamed due to the addition or correction of the rotation frames, i.e. "BOSSA2A8" has been renamed to "BOSSA2C8".

Hence, the brightmaps could not natively support these sprite fixes unless they include a number of extra dummy definitions that otherwise go unused when playing with the vanilla IWAD. The nice thing here, though, is that no new brightmaps have to be created (apart from the missing rotations). The exact same art can be utilized. They just have to be defined for the differently-named graphic lumps.

Death Egg said:

So, I've spotted an off-colored pixel on the radiation suit that this project doesn't seem to have found yet:

http://i.imgur.com/KpwN9dH.png

Thanks for this report! I was wondering how this green pixel could have appeared, but I eventually realized the obvious: since the radiation suit is based on the player sprites, an errant pixel from the original green outfit survived. Placing PLAYA1 over SUITA0, I even managed to find a remarkably close alignment where the suit's green pixel is placed next to an identically colored player sprite pixel, among other matching details. I've made the fix, and it will be included with the 1.7 release.

This is pretty awesome.

Has anyone considered making an unofficial bugfix patch that compiles together all such fixes into one project that can be used as a basis for other patches like the aforementioned brightmaps?

That's what I am more or less trying to do.

@Revenant100:
You don't happen to have a list with all the sprites that were renamed in the process of creating the fix files? It would need to have both the old and the new names to be useful.

I did my own comparisons and came up with this list:

Keeping with your formatting, the following is a full list of the graphic lumps that were either renamed or added:

Thanks a lot! Luckily, not all of these sprites require brightmaps. ^^

I believe I am done with my adjustments, so I can present a result. Here are brightmaps that work with Revenant100's spritefixes (both Doom and Heretic, but Hexen and Strife are also covered):

Spritefix-compatible brightmaps pack for GZDoom v1.01 (PK3, 1.3 MB)

From the included readme:
- This file completely replaces brightmaps.pk3 that comes with GZDoom. You don't need to load both files at the same time.
- It is assumed you use the spritefixes for Doom and Heretic made by Revenant100 (d1spfx16.wad, d2spfx16.wad, hrspfx10.wad).
- By editing the definitions inside of the PK3 file, you can switch to vanilla sprite support and deactivate brightmaps for textures (which are used by default).
- For additional/fixed texture brightmaps in Final Doom, edit doomdefs.bm according to the comments in the file.
- As long as you use the spritefix definitions, avoid loading these brightmaps with Doom/Heretic addons that come with customized sprites. Textures won't matter.

Note that I didn't do most of these brightmaps, only those that were missing for the Doom spritefixes (everything in brightmaps/doom/spritefix). Proper credits has been given to the authors (Acidhoes, DrVenom8, TheUnbeholden and Virtue) in the included readme.txt file.

Is this compatible with Smooth DooM?

No, it's not. Far more brightmaps would be needed for that, sorry. And this thread is about the sprite fixing project, Smooth Doom isn't the topic here.

I know. I just wish the sprite improvements could be added to Smooth DooM. :(

Smooth DooM adds sprites from the IWAD.
Doom 2 MSFP changes them.

See why it wouldn't be compatible? The new sprites from Smooth Doom would not be fixed, only the original IWAD ones, and... well that's it. (I think?) Still it WOULD work, just not be 100% compatible.

Please correct me if I am wrong.

Yeah, this is what I meant to ask. My bad. :(

You can use those brightmaps also with Smooth Doom, but you would be missing many brightmaps for those frames that have been added. It would probably look quite stupid if for example glowing eyes of the zombieman flicker like crazy because of missing definitions.

In the meantime, I have updated the brightmaps a bit. Cacodemon and Mancubus still had glowing eyes in their final death frames which looked kinda stupid. In the new version that I uploaded above, the eyes "fade out" in the last three frames until they are completely dark.

This is probably the best "minor fix" mod out there, I never play doom without it. However, there's still something I think should be fixed. The status bar has some extra space to the right of doomguys head, this is a leftover from the 1up counter in the beta. If filled in this makes the face appear perfectly centered.

There's also something I'd like to ask about the edits you made to the hanging bodies, wouldn't it make more sense to adjust the sprite offsets?

uhbooh said:

The status bar has some extra space to the right of doomguys head, this is a leftover from the 1up counter in the beta. If filled in this makes the face appear perfectly centered.

Although it's true that the status bar mug is visually off center, there's no perfect way to non-intrusively address it. As far as its sprite offsets goes, the face's size and the dimensions of the HUD space happen to leave an odd number of pixels surrounding it, so the sprite is already technically as centered as can be in this arrangement. While I could alter the status bar graphic to reduce the HUD face space by a pixel, as you suggest, this has a high likelihood of conflicting with any mods that replace the Doom Guy's mug with something else.

There's also something I'd like to ask about the edits you made to the hanging bodies, wouldn't it make more sense to adjust the sprite offsets?

There are situations where the mapper's placement of decorations such as hanging bodies are very precise and deliberate, and unaccounted for offset adjustments may break the intended visuals. As a reverse floor-bound decoration example, torches are often embedded into the ground to create the illusion of a detached fire. Adjusting the sprite offsets up or down in this case would break the illusion.

While I can't imagine there are too many instances where the placement of hanging body decorations would be this sensitive to vertical offset adjustments, I nonetheless opted to remain as minimally intrusive as possible here and extended the ropes/chains rather than shift the entire sprites upwards. This way, the detached ceiling links are fixed while hanging bodies remain in the exact same positions as before, thus perfectly preserving all existing level visuals as the authors originally created.

I tried playing this with Back to Saturn X (in Crispy Doom, but I dont think this issue is source port dependent) and it didn't seem to work, BTSX just kept using the default sprites. I'm not sure if there's some special case for this mod, I haven't tried using it with too many other mods so far but generally it's worked with others. I'm using this command sequence

crispy-doom -iwad doom2.wad -merge d2spfx16.wad -file btsx_e1.wad -deh btsx_e1.deh d2dehfix.deh

BTSX replaces all of the Doom sprites with new sprites, so loading it before the mod won't work. In addition, it won't match the palette even if you do load it in the right order, so things will look off. BTSX should just incorporate the changes this mod made into it tbh.

ah, I didnt realize the sprites themselves were altered, I assumed the different palette was just a playpal lump or something. I've been using this mod with Brutalist Doom, which also alters the palette but doesn't affect the sprites, so I didn't even think that would be necessary in BTSX

I definitely think there should be a "minor texture fix project" to go alongside this one.

Death Egg said:

BTSX should just incorporate the changes this mod made into it tbh.

This a couple of times.

Including stock sprites in their original state seems like a wasted opportunity to me.

Can't you convert all the sprites to the BTSX pallette with SLADE? Then load it after BTSX and it should work. I think.


Or just play BTSX with Doom Retro, which fixes most weapon sprites (SSG brown pixel, offsets ...) by default.

The lost soul's single pixels of fire in the sprite's fix provided by this WAD (the one in the Lost Soul walking animation) are not present in the other walking frame of it, which makes it look weird, as if the 2nd frame had like a short and small "eruption".

VGA said:

Can't you convert all the sprites to the BTSX pallette with SLADE? Then load it after BTSX and it should work. I think.

A straight palette conversion in SLADE would result in a great deal of color reduction in certain instances, particularly the blues in sprites such as the Cadodemon's, as they have different color hues that don't translate directly between one another. I don't know the exact steps the BTSX team took, but I would presume they first converted the sprites to an intermediate palette that mapped all of the colors to the correct indices and then applied (or rather switched to) their new palette which has the modified color ranges.

Gustavo6046 said:

The lost soul's single pixels of fire in the sprite's fix provided by this WAD (the one in the Lost Soul walking animation) are not present in the other walking frame of it, which makes it look weird, as if the 2nd frame had like a short and small "eruption".

This is the same style used for the fire animation in all other rotation angles of the Lost Soul:

Hello again! It's been about a year since the last version of the Doom 2 Minor Sprite Fixing Project, so I'm now going ahead and releasing the 1.7 update which is comprised of the fixes discussed here in the past many months. As before, this isn't a huge change over the previous version, but I again meant for this update to coincide with an idgames archive release. Unfortunately, that plan fell through once more as there's not much I can do if I receive nothing but willful radio silence from the other end.

Many thanks to the numerous individuals who have provided feedback and continue to report issues, with special gratitude to Linguica for documenting and providing a fix for the tall sprites wrapping error.

So without further ado, here's the current download of v1.7:
https://www.doomworld.com/idgames/graphics/sprfix17 (2.52 MB)

The complete changelog including the 1.7 edits:
https://drive.google.com/file/d/0B4X6_GM5D7D_YUtvek8wSmMwN00/view?usp=sharing

Trimmed summary of the new 1.7 changes:

Nice, thanks for the new release!

I expressed interest in a 'Doom/Doom 2 minor texture fixing Project' before, and since it seems no one has the time or motivation to start such a Project, I would be more than happy to start it myself.
Revenant100, you told us Before that you were also working on a Hexen sprite fixing Project. I would also be willing to assist in maintaining such a Project and even extending it to texture fixing, if you ever feel the interest/need for it. :)
By the way, are anyone familiar with Strife's Graphics in regards to what 'bugs' there are? I could help compiling such a thing too.

Cire said:

I expressed interest in a 'Doom/Doom 2 minor texture fixing Project' before, and since it seems no one has the time or motivation to start such a Project, I would be more than happy to start it myself.

I definitely encourage you to go ahead with the idea as I'd love to see something of that ilk myself. My main thought here is that we don't have nearly as many points of references in terms of knowing how the patches and flats were created over the development period, but this was more of a concern years ago before Romero released his graphic resources, and there are nonetheless still a handful of easily identifiable objective errors in the textures.

The other snag you're going to face is IWAD cross compatibility. With the sprite fixes, I luckily didn't run into any issues that necessitated more than separate Doom 1 and Doom 2 PWADs. However, if you're going to fix the errors in the TEXTURE1 lumps (SW1DIRT/SW2DIRT comes to mind), you're likely going to have to at minimum create TNT and Plutonia-compatible PWADs as well. And, unfortunately, pretty much any level that includes its own textures is immediately going to override any TEXTURE1 lump fixes.

Revenant100, you told us Before that you were also working on a Hexen sprite fixing Project. I would also be willing to assist in maintaining such a Project and even extending it to texture fixing, if you ever feel the interest/need for it. :)

Hexen's patches and flats would be venturing further into unknown territories for me, so I would appreciate help there in that respect.

As for the Hexen Sprite Fixing Project as a whole, please don't count it out yet! I have every intention of returning to it at some point, even sooner if I can get this idgames archive matter sorted out, but Bloodshedder and TheGreenHerring appear to be ignoring my last reply. I do hope they will come through eventually.

Perhaps next you could do a Chex Quest sprite fixing project, there's a lot of errors in those sprites and how they're aligned. Would be an undertaking, I've attempted it once or twice for fun.

OK, I've started working on putting together a Doom and Doom 2 Minor Texture Fixing Project with a first small test release uploaded here: http://www.filedropper.com/texfix01
I haven't started work on TNT or Plutonia versions yet. I've also included the fixed RSKY2 even though it's already included in the Sprite Fixing Project.
Feel free to comment! :)
Thanks to:
Noiser for FLAT5_5 and RW18_3
Quaker540 for SKY1 and SKY2
Revenant100 for RSKY2
VGAce for BIGDOOR1

After some promising tests, I'm happy to announce a mildly exciting new development in regard to these sprite fixes: compatibility patches for select PWADs!

In recent years, you may have noticed that several high profile WAD releases included their own customized color palettes such as Back to Saturn X, Sunlust, and most recently the critically acclaimed Ancient Aliens. Due to the nature of the palette system, these PWADs must include virtually the entirety of the original IWAD's graphics and sprites in nearly unmodified form. However, while said modifications are almost entirely, if not fully, invisible to the naked eye, these palette conversions are a technical necessity and cannot be avoided. What's relevant here is that these repacked IWAD graphics end up completely overriding any autoloaded sprite fixes. Trying to circumvent this problem by loading the sprite fixing WADs afterwards will result in visual errors due to the mismatching palettes.

And this is where the recent development comes into play: I've managed a fairly painless process to make sprite fixes compatible with these custom color palettes, hence I can release separate sprite fixing WADs expressly for the megawads and whatnot that warrant them. What I need help with now is identifying the appropriate PWADs to create compatibility patches for. Specifically, I'm looking for releases that incorporate a custom PLAYPAL lump that requires the entire set of original IWAD sprites to be repacked along with them. I've already noted BTSX, Sunlust, and Ancient Aliens so far. While I'm sure more will come in the future, are there any I'm missing at the moment?

And so this post isn't just boring text, the Ancient Aliens-compatible sprite fixes WAD is being released right now! Not only have I integrated the previous missing rotations, art fixes, and so forth, but I've also gone ahead and made AA-specific fixes, namely adjusting the new monster sprites and correcting some of the palette conversion errors present in the current version.

Ancient Aliens compatibility patch (load the sprite fixes after aaliens.wad):
(Outdated, see original post)

Preview images:


BTSX and Sunlust compatibility patches will come soon.

Cire said:

OK, I've started working on putting together a Doom and Doom 2 Minor Texture Fixing Project with a first small test release uploaded here: http://www.filedropper.com/texfix01

Looking like a good start! However, I think you're inevitably going to run into problems with that BIGDOOR1 fix. Changing the dimensions of the texture is almost certainly going to cause noticeable conflicts. Unfortunately, this is where striving for compatibility will constrain the nature of the viable fixes.