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

[Medis]

Revenant100 said:

By padding, I mean that I actually added empty space to the sprites to pad their dimensions, thus ensuring they are perfectly centered without changing their current offsets. Here's an example with the Spider Mastermind:

http://i.imgur.com/0zNxKSF.png

The original sprite is 215x109. The padded sprite is 251x109. When the engine mirrors the padded sprite, it flips it perfectly over the Y axis, thus avoiding the improperly recentered issue.

Briliant, magnificent idea!

[NightFright]

I have updated my GZDoom brightmaps pack that I had released in January 2016 so that it works again with v1.8 of the spritefixes.

[Link removed due to file update. Go here for latest version (works with spritefixes v1.8 final)]

Should anything change before the final v1.8 release, please let me know exactly which sprites got changed (compared to v1.8 RC1) since I would like to avoid checking each and every sprite manually once again as I did for this update. :P

*EDIT Nov 9, 2016*
Updated to version 1.11. Changes:
- Added brightmap for SSWVG5 (Wolfenstein SS firing/rear view)
- Made spritefix versions of SKULA1 and SKULB1 (Lost Soul/front view) brighter

[kb1]

Revenant100 said:

Thank you for the kind praise, kb1!

You're quite welcome. Credit where credit is due. Thank you for your extreme attention to detail (and thanks to everyone else who contributed). I'm thinking that, at that point in development, id Software was having so much fun playing Doom that they completely forgot to finish setting up the game data! (Sprite offsets, obj properties like height, width, mass, etc). I have a feeling that the wonderful Doom monster/weapon balance we have today is part good design, and a large part lucky initial pick!

Revenant100 said:

Despite the full *1-8 lump names, the rotations in the alphas are just mirrored graphics. Their later use of the *2*8 and so on lump names for automatic mirrored rotations is functionally identical to what they did in the alphas except more memory efficient.

Please look again. I use a combination of Doom 0.4, frames A through D (8 angles), and Doom 0.5, frames E through G (also all 8 angles). Angles 6, 7, and 8 are actually different, totally new frames, not mirrors. They're actually pretty cool.

Nah, they didn't just save memory. They lost 21 frames in doing so :(. These steps will bring them back:

You'll need a tool to convert them from Alpha format to standard Doom sprite format. Careful: When importing them, do not allow the WAD editor to convert colors - the alphas use a slightly brighter palette. Just bring them in without conversion and the alpha pixels will use the normal Doom palette, which will make them darken to the expected colors.

Or, duh, just get them from this wad I just made. Note: You'll have to do your padding and sprite offset thing - this wad contains the original images, converted from Alpha format, but with the original offsets. I included Doom 1.9's PALETTE and COLORMAP for easy viewing of the wad.

These are new frames, or I'm losing my head (please let me know which). I've been using these sprites for a few years now - they look nice. It's not an Earth-shattering thing - but I think you'll be able to see the difference. They animate nicely, so it adds a small bit of depth.

You've probably noticed that in the left-facing attack frames (in all versions), the imp's hands are clipped off. It's probably 'out-of-scope' of your project's guide lines, but I'd love to see those hands 're-mastered'. Maybe John Romero has the original, unclipped, full-frame images for the imp as well? Might be worth asking.

[Revenant100]

NightFright said:

I have updated my GZDoom brightmaps pack that I had released in January 2016 so that it works again with v1.8 of the spritefixes.

Thanks for keeping the pack up to date! Barring any major bug revelations, I don't foresee any widespread sprite alterations in the final 1.8 release that would necessitate a big update to your brightmaps. Fingers crossed, of course, but I'll compile a thorough list if something warranting changes does occur.

kb1 said:

Please look again. I use a combination of Doom 0.4, frames A through D (8 angles), and Doom 0.5, frames E through G (also all 8 angles). Angles 6, 7, and 8 are actually different, totally new frames, not mirrors. They're actually pretty cool.

The 0.4 alpha Imp walking sprites are definitely mirrored. The 8 angle doesn't even have the proper 4-frame animation. I have already included the non-mirrored 0.5 alpha attacking frames.

Maybe John Romero has the original, unclipped, full-frame images for the imp as well? Might be worth asking.

It's certainly possible. Romero likely has the raw sprite sheets for all of the current monster artwork, and judging from what he's shared with us so far, this might be his last big batch of Doom 2 material still left unreleased. I did personally reach out to him in 2013 inquiring about the missing Zombie/Player rotation sprites, and while he responded, those didn't end up seeing the light of day until a year later, so I can't say I've had great luck in that department. If he ever does (or someone manages to convince him to) share the rest of his Doom assets, I will certainly make the best use of them that I can. Even if they don't have additional missing artwork to implement, they would still be invaluable in adjusting the monster sprite offsets to the artists' precise original intentions.

Going back to the 1.8 Beta 1 release, I'm still all ears in terms of bug reports or issues. If anyone using this version has encountered problems, please do inform me. If none arise, however, the final 1.8 release should happen soon.

[DurableTomb]

Is one able to use this with Brutal Doom and Zandronum with the Steam version?
If so, how?
Also, can this be used for Doom 1, Master Levels, Plutonium, Final Doom, etc?

[VGA]

Brutal Doom changes so much stuff in the weapons. How would it be compatible with the changes in this mod?

Use one of the two.

[DurableTomb]

Could you suggest an adequate setup that allows for increased difficulty, while also maintaining the vanilla Doom feel, gear, and monsters? I only got Brutal Doom before because I hadn't played the game since the 90's and I wanted to make it more difficult.

[NightFright]

If you are using ZDoom/GZDoom, maybe you could try with an edited MAPINFO file containing modified code for skill settings (this is just an example):

Spoiler

clearskills
skill baby
{
	DamageFactor = 0.25
        Monsterhealth = 0.5
	DropAmmoFactor = 1.5
        AmmoFactor = 1.5
        SpawnFilter = Baby
}

skill easy
{
	DamageFactor = 0.5
        Monsterhealth = 0.75
	DropAmmoFactor = 1.25
        AmmoFactor = 1.25
        SpawnFilter = Easy
}

skill normal
{
	DamageFactor = 1.0
        Monsterhealth = 1.0
	DropAmmoFactor = 1.0
        AmmoFactor = 1.0
        SpawnFilter = Normal
}

skill hard
{
	DamageFactor = 1.25
        Monsterhealth = 1.25
	DropAmmoFactor = 0.75
	AmmoFactor = 0.75
        SpawnFilter = Hard
}

skill nightmare
{
	DamageFactor = 1.5
        Monsterhealth = 1.5
	DropAmmoFactor = 0.5
	AmmoFactor = 0.5
        SpawnFilter = Nightmare
}

DamageFactor: Damage you receive from monsters, lava or slime. Increase for higher difficulty.
Monsterhealth: Monster hitpoint multiplicator. Increase for higher difficulty.
DropAmmoFactor: Amount of ammo drops from monsters. Lower for increased difficulty.
AmmoFactor: How much ammo you get when picking up placed items. Lower for increased difficulty.
SpawnFilter: Only monsters with the specified max difficulty level will spawn.

There are also ArmorFactor and HealthFactor to try, work pretty much the same as AmmoFactor. These affect armor and health pickups.

There are also has some interesting setups at the bottom of the ZDoom Wiki page about MAPINFO, one for replacing actors (e.g. medikits are replaced with weaker ones, weaker monsters are replaced by stronger ones) and another for one-hit kills (player and monsters).

[damerell]

DurableTomb said:

Could you suggest an adequate setup that allows for increased difficulty, while also maintaining the vanilla Doom feel, gear, and monsters? I only got Brutal Doom before because I hadn't played the game since the 90's and I wanted to make it more difficult.

I usually play Doom 1 and maps of similar difficulty with -fast on. This is about half of Nightmare mode. It is worth a try not least because after playing with -fast, when you return to normal play, monster fireballs will appear to saunter towards you in a leisurely fashion as pinkbeasts stroll gently down the corridors pausing to admire the scenery.

[kb1]

Revenant100 said:

The 0.4 alpha Imp walking sprites are definitely mirrored. The 8 angle doesn't even have the proper 4-frame animation. I have already included the non-mirrored 0.5 alpha attacking frames.

Wow, you're absolutely right. I have no idea how I didn't see that before - both the mirroring, and the duplicated B8/D8 frame. Funny thing is - it's hardly ever noticeable in game (to me, anyway, but, then again, I didn't see it in the WAD editor either!). Good eye!

[Revenant100]

This month officially marks four full years since I first began this project, so what better time is there than now to release the finished v1.8?

The big addition in this release is the number of sprite padding fixes which addresses incorrect sprite mirroring in the vanilla executables and certain ports as well as alleviates visible animation jittering which still occurs in most all modern source ports. However, that's not all! I'm also releasing the Back to Saturn X-compatible sprite fixes WAD! I've integrated the missing rotations, art fixes, and so forth to work with the custom palette. This compatibility patch WAD works with both the Episode 1 and Episode 2 releases. v1.8 is quite pertinent to BTSX in that it addresses numerous vanilla-only problems, hence it's very much in line with BTSX's vanilla compatibility.

So without further ado, here's the current download of v1.8 (11/15/16):
(See original post for most current download link)

The complete changelog including the 1.8 edits can be viewed here:
https://drive.google.com/file/d/0B4X6_GM5D7D_MXJ2cGozSjRwZnc/view?usp=sharing

Preview images of 1.8's changes:

Spoiler

Back to Saturn X (both Ep1 and Ep2) compatibility patch (load the sprite fixes after btsx_e1.wad or btsx_e2a.wad/btsx_e2b.wad):

• http://www.mediafire.com/file/1d490jhobsjva6e/d2spfxbx.zip (2.1 MB)

BTSX compatibility patch preview images:


An updated Ancient Aliens compatibility sprite fix WAD will come soon along with a new compatibility patch for Sunlust. If there are any other major outstanding PWADs that require a specific sprite fix compatibility patch, please do inform me. I will also be releasing a modder's resource WAD for those who would like to integrate these sprite fixes into their own projects without the hassle of manually merging the sprites.

And, as always, this project would not have reached this far without the community. My gratitude to everyone for your continued feedback and support.

[HavoX]

Revenant100 said:

I will also be releasing a modder's resource WAD for those who would like to integrate these sprite fixes into their own projects without the hassle of manually merging the sprites.

Two words: Awesome sauce.

[NightFright]

Did you change anything in the final release compared to the release candidate? I would need to know about any sprite realignment, resize or anything similar that could break the brightmaps I had provided earlier.

[Revenant100]

I changed the padding dimensions of HEADF3F7 as it previously wasn't mirroring as intended. I also made some trivial offset adjustments to the Hell Knight and Baron of Hell attacking frames and one small offset adjustment to one Arch-Vile walking frame, but these wouldn't have any bearing on the brightmaps.

[NightFright]

Excellent! Thanks for the fast info. Here's the brightmaps pack for the final version of the v1.8 spritefixes, then.

Spritefix-compatible brightmaps for GZDoom v1.12 (PK3, 4.4 MB)

[Revenant100]

Hoo boy, precisely four years ago this day was this thread's initial creation, but that's already been covered, so let's get straight to brass tacks with today's two new releases: the Sunlust-compatible sprite fixes WAD and the Full Modder's Resource Wad.

This has little need for introduction, so here's the Sunlust compatibility patch (load the sprite fixes after sunlust.wad):

• http://www.mediafire.com/file/7z3hs4d7amnq1w1/D2SPFX-sunlust.zip (2.13 MB)

Sunlust compatibility patch preview image:



The newcomer here is the Full Modder's Resource Wad. If you are a mapper or sprite artist who wishes to utilize the sprite fixes in your own projects, this is what you'll be interested in. The big issue I've seen people have with trying to implement these fixes is manually merging them with their own WADs as this causes an organizational mess, numerous redundant sprites to be cleaned out, and several orphaned sprites left behind. Hence, the following D2SPFX18_FULL.WAD is a complete resource WAD to meet your needs, whether it be to batch process everything for your new palette conversion or to selectively extract and merge individual monster sprites for your own edits. Be sure to check the credits so you may properly acknowledge whomever's work you may be employing.

So without further ado, here's the Full Modder's Resource Wad (for modders, not end users):

• http://www.mediafire.com/file/zwbh4clhd2hgsmn/D2SPFX18_FULL.zip (2.35 MB)

Still upcoming is the updated Ancient Aliens sprite fixes and the proper idgames upload for v1.8. After that, we'll be aiming for beyond the stars. Or is that beyond Heretic?

[Revenant100]

Some minor updates on the Minor Sprite Fixing Project coming up.

v1.8 is now on idgames! There are no new changes since the original 11/15/16 release, but this will of course serve as the primary download mirror from here on out:

• https://www.doomworld.com/idgames/graphics/sprfix18 (2.63 MB)

Also, the Ancient Aliens compatibility patch has been updated to reflect the v1.8 changes. Again, no major introductions here, but the jitter fixes and other adjustments are a welcome change:

• D2SPFX-aaliens.zip (1.83 MB) (load the sprite fixes after aaliens.wad)

That closes the book on Doom-related fixes for a good while, I imagine. I'm still paying close attention to any new projects that necessitate a PWAD compatibility patch, Dimension of the Boomed being the latest candidate. I also have BTSX Episode 3 in mind, and I'd even like to offer the sprite fixes as a whole to the project considering the many vanilla-only issues that are addressed, but I have no idea what the current status of that map set is, nor where to check. I'm all ears for any helpful pointings in the right direction, however.

And with that, I now bid adieu, my compatriots. I must depart to that great ethereal plane to where it's said all lost Lost Soul sprites go. So long, and thanks for all the fish.



I'm not actually going anywhere, though, so I'll still be right here.

[Cire]

Nice! Looking forward to the Hexen Project too. :)

[NightFright]

Thanks for all the hard work you have put into this project, Revenant100. It's a must-have for any true Doom fan and a great community contribution in general!

I am glad that I was able to be part of it at least to a minor degree. May your legacy live on for all eternity! \o/

[3371-Alpha]

Does this fix the various sprite issues with the Wolfenstein SS soldiers, such as the purple pixels between their legs and lack of back and side attack frames?

[Revenant100]

Yes, among several other fixes, the SS's purple leg pixels were removed, and they now possess full shooting and pain rotation frames thanks to new sprites courtesy of DoomJedi, ItsNatureToDie, and PSTrooper.

[Viggles]

Fantastic work, as NightFright said this project is a great contribution!

I noticed the fixed "Twitching Impaled Human" animation in 1.8 bounces up and down in GZDoom 2.3.2 when using the default sprite clipping settings; this seems to be a recent GZDoom bug, and not a bug in the sprite fixing project itself. I've filed a GZDoom tracker issue about it here: https://mantis.zdoom.org/view.php?id=241.

[Xfing]

Excellent work! I really like what you did with this mod/fix.

[Revenant100]

Viggles said:

I noticed the fixed "Twitching Impaled Human" animation in 1.8 bounces up and down in GZDoom 2.3.2 when using the default sprite clipping settings; this seems to be a recent GZDoom bug, and not a bug in the sprite fixing project itself. I've filed a GZDoom tracker issue about it here: https://mantis.zdoom.org/view.php?id=241.

Thanks for making this bug report. I've also noticed this vertical bouncing issue occurring in GZDoom (the OpenGL renderer, I mean) with the Tall Green Torches, Tall Blue Torches (see MAP20: Gotcha! for a clear example), Burning Barrels, and Evil Eye actors, all of which received similar fixes. That the bouncing occurs even with the Sprite Clipping option set to Never seems indicative of a problem.

[Viggles]

I'm guessing that GZDoom may have hardcoded clipping offsets for certain sprite frames, which it doesn't apply if that frame is replaced in a PWAD. When only one frame of an animated sprite is replaced, it may be applying the clip value for the unmodified frame(s) but not the replaced frame(s), leading to the animation jitter.

If this is the case, then GZDoom isn't really doing anything wrong here; it would just be lacking sufficient context for what the PWAD is trying to do. The jitter does go away if every frame of the animation is replaced in the PWAD, so that could be one way to keep GZDoom happy.

[Gez]

Viggles said:

I'm guessing that GZDoom may have hardcoded clipping offsets for certain sprite frames, which it doesn't apply if that frame is replaced in a PWAD.

It's a relatively recent thing.

[Revenant100]

This is an interesting predicament, and I'm not sure I have a good answer to it.

Viggles said:

The jitter does go away if every frame of the animation is replaced in the PWAD, so that could be one way to keep GZDoom happy.

This would indeed be a way to address the issue (the hard coded offsets will be lost, but that seems unavoidable no matter what), but that poses a different problem. A difficulty I faced a year ago was attempting to upload this WAD to the idgames archive. It was initially rejected on the grounds of containing "unmodified id Software resources." I pointed out that every included lump was demonstrably edited in some way, but the concern was that the modifications weren't "substantial enough." While this decision was reevaluated a year later, to now begin deliberately including sprites that are expressly unmodified, even for the purpose of forward compatibility in certain source ports, is veering back towards those original concerns. Granted, it wouldn't require the addition of many unmodified sprites to fix this particular jittering, but that's still content that falls under the description of "unmodified id Software resources."

As a more practical matter, I'm wondering if I can realistically offer forward compatibility for all possible future scenarios. In its current state, these sprite fixes are essentially vanilla-compatible. Barring the IWAD itself, it can't go any layer lower. If a source port has troubles handling the sprite fixes, then I think the question should be where the breakdown is occurring in between. It's true that GZDoom's logic in this case is working correctly, but this is also an example of where these hard coded exceptions are failing in a real world test case.

I'll posit a possible solution I've come up with on GZDoom's end: The hard coded offset exceptions examine each sprite individually. However, we know by the sprite names that these are effectively groups, i.e. TGRN** rather than considering TGRNA0, TGRNB0, TGRNC0, and TGRND0 as independent lumps. Hence, they should be treated as groups. If the engine detects any sprites in a loaded PWAD overriding anything within this group (it doesn't have to be a specific frame or all frames), it should disable the hard coded offsets for the entire group. I believe this would fix the problem here with the sprite fixes and may future proof it against most (all?) further similar happenstances.

[Gez]

If I understand the crux of the issue:

There's an AB animation that jitters.
Sprite Fix solves the problem by changing the A offsets so that it aligns better with B.
GZDoom solves the problem by changing the B offsets so that it aligns better with A.
When combining both, the problem is back.

A simple solution would be to change GZDoom's offset list to make them coincide with the sprite fix project's.

[Viggles]

Gez: That's a good summary, though it's not precisely what's going on in this case. It's certainly one version of the problem that can come up.

In this case the original AB animation doesn't jitter vertically at all; Sprite Fix is overriding one of the frames to fix some pixels and make the two match better horizontally, but it doesn't alter the vertical offset of either frame. Those remain consistent with vanilla doom(2)'s.

GZDoom wants to override the Y offset of both the impaled human animation frames (POL6A0 and POL6B0) from 62 to 65, presumably to play nicer with OpenGL's sprite clipping. But because one of the frames is replaced in the PWAD, its Y offset is left alone, so it's now inconsistent with the other frame that receives the offset override.

GZDoom's offset overrides could be altered to be consistent with Sprite Fix's in each case; but that only fixes it in this particular instance, for this particular version of Sprite Fix, and it ignores the decisions that went into GZDoom's offset choices. (Indeed, in this case I imagine Sprite Fix would actually want to use GZDoom's raised offsets - if it didn't mean breaking idgames regs by shipping an unmodified original sprite solely to apply a better offset.)

Moreover I can see this edge case - PWAD replaces part of a sprite animation, keeping the offsets the same as vanilla - coming up for a lot more than just Sprite Fix. As a contrived example, imagine a PWAD that made the zombieman's muzzle flash blue but didn't touch the other frames.

I think Revenant100's proposal - that GZDoom ought to treat sprite animations as a group, and not override any offsets for that group if any sprite in that group has been replaced - would be the safest way to solve this kind of issue.

[Viggles]

Looks like there's a fix for the partially-replaced-sprite-offset issue in GZDoom dev builds now: https://github.com/coelckers/gzdoom/commit/a6156297ce3602dce73f1caa0805a23294b4799e

(I haven't tested it myself though.)