Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Revenant100

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

Recommended Posts

I am not very experienced with Doom modding, but I was wondering, could it be possible to just include these fixes inside the doom.wad and doom2.wad files themselves? Something like the where the cross got changed to a pill in the BFG edition?

Share this post


Link to post
14 hours ago, CeDean said:

I am not very experienced with Doom modding, but I was wondering, could it be possible to just include these fixes inside the doom.wad and doom2.wad files themselves? Something like the where the cross got changed to a pill in the BFG edition?

 

You could alter the official WADs but you'll get a warning screen in SLADE for example telling you it's a bad idea. I think some programs rely on the original IWAD "fingerprints" to recognize what they are which would break. It also kind of goes against the whole idea of the WAD system which was to make it easy to drop in and change replacement assets etc. Instead, if you get comfortable making profiles in something like Doom Launcher you can pretty much set it and forget it. Some source ports (like Woof) have autoload folders to accomplish the same thing.

Share this post


Link to post

Hello, so I ran into a small issue that affects both your sprite fix WAD and Alaux's version where monster corpse sprites are ever so slightly sunken into the ground. At first I thought there was an issue with GZDoom 4.8.2, but then I tested it with Skulltag (remember the good ol' days?) and the same thing happened, which really obfuscated me.

 

Maybe I should take it up with the GZDoom crew to see what's going on and determine if it's actually an issue on my end, but I thought you should know.

 

You'll find a couple of screenies showing the bug.

Thanks, have a good one.

with spritefix.jpg

without spritefix.jpg

Share this post


Link to post
1 minute ago, Lt.Gonflette said:

-snip-

 

That's not a bug, that's the hardware rendering cutting off the part of the sprite which sinks into the floor (which has always been the case for the original sprites). Look at your sprite clipping settings or use the software renderer.

Share this post


Link to post
2 minutes ago, maxmanium said:

 

That's not a bug, that's the hardware rendering cutting off the part of the sprite which sinks into the floor (which has always been the case for the original sprites). Look at your sprite clipping settings or use the software renderer.

Thank you, I just saw the setting that raises monster corpses, though the "always" setting raises them a bit too much. I had a hunch it was a setting issue on my end (though I played a whole megawad with a sprite fix wad a few months back and I don't remember noticing it...).

As I said, very minor thing, but one I don't remember noticing before.

Cheers

Share this post


Link to post
2 hours ago, Lt.Gonflette said:

Hello, so I ran into a small issue that affects both your sprite fix WAD and Alaux's version where monster corpse sprites are ever so slightly sunken into the ground. At first I thought there was an issue with GZDoom 4.8.2, but then I tested it with Skulltag (remember the good ol' days?) and the same thing happened, which really obfuscated me.

You are correct, and this is technically intended behavior on GZDoom's part. GZDoom includes its own built-in sprite offsets overrides (located in game_support.pk3/filter/doom.id/sprofs.txt) that augment the "Adjust sprite clipping" setting in a manner I'm not precisely familiar with. However, the point is that loading the sprite fixes will disable most of these built-in offsets as there would otherwise be conflicts between these overrides and some of the WAD's own modified offsets. Hence, you will see clipping differences in some sprites with the sprite fixes loaded, even if the sprite fix WAD doesn't actually replace said specific sprite. Strictly speaking, the more sunken sprite offsets you see with the sprite fixes loaded are actually more accurate to the game's original appearance. (You can switch between hardware and software rendering to compare!)

 

This is deliberate behavior on GZDoom's part, and I in fact actually reported the initial conflict on their forums years ago, leading to the current behavior. This behavior does unfortunately lead to the minor visual discrepancy you've noted, but nothing is wrong here on a technical level. Making the sprite offsets match as you're familiar with them in GZDoom, however, would be rather inelegant as that would mean providing an override for an engine-specific override. It can certainly be done, but I'm afraid it's not something I'll be offering myself.

Share this post


Link to post
7 hours ago, Revenant100 said:

You are correct, and this is technically intended behavior on GZDoom's part. GZDoom includes its own built-in sprite offsets overrides (located in game_support.pk3/filter/doom.id/sprofs.txt) that augment the "Adjust sprite clipping" setting in a manner I'm not precisely familiar with. However, the point is that loading the sprite fixes will disable most of these built-in offsets as there would otherwise be conflicts between these overrides and some of the WAD's own modified offsets. Hence, you will see clipping differences in some sprites with the sprite fixes loaded, even if the sprite fix WAD doesn't actually replace said specific sprite. Strictly speaking, the more sunken sprite offsets you see with the sprite fixes loaded are actually more accurate to the game's original appearance. (You can switch between hardware and software rendering to compare!)

 

This is deliberate behavior on GZDoom's part, and I in fact actually reported the initial conflict on their forums years ago, leading to the current behavior. This behavior does unfortunately lead to the minor visual discrepancy you've noted, but nothing is wrong here on a technical level. Making the sprite offsets match as you're familiar with them in GZDoom, however, would be rather inelegant as that would mean providing an override for an engine-specific override. It can certainly be done, but I'm afraid it's not something I'll be offering myself.

Thank you for your detailed answer! So it is absolutely normal for GZDoom. Is this a question you've often been asked by Sprite Fix users who play on GZDoom? Because if it is, if you want, I could create a new thread quoting your answer for everyone to see.

 

1 hour ago, Delfino Furioso said:

speaking of SPRFIX and GZDoom.. 

 

you'll probably want to use this gzdoom-specific variant made by Nash

https://forum.zdoom.org/viewtopic.php?t=74649

 

all the original dehacked code has been converted to zscript, so this should likely reduce the chance of conflict with other dehacked-heavy pwads

 

Great find! Using it right now ;)

Share this post


Link to post
3 hours ago, Delfino Furioso said:

all the original dehacked code has been converted to zscript, so this should likely reduce the chance of conflict with other dehacked-heavy pwads

The nature of the DeHackEd fixes is such that they are as unintrusive as possible, and in the years I've been using and testing them, I've yet to come across one incompatibility, even with the most elaborate DeHackEd modifications. They even maintain perfect demo sync compatibility, which is quite a high bar to pass. I understand why Nash created ZScript conversions for the DEH patches, but given how the code works by replacing actors and states, I can't guarantee they can work as conflict-free in practice. Any ZScript conflict in this case would nonetheless be very minor, though, with the cosmetic effects of the fixes simply being overridden by other higher priority mods. However, I think sticking with the DeHackEd patch here could result in better guaranteed compatibility, perhaps something to test out and verify in the future.

 

2 hours ago, Lt.Gonflette said:

Thank you for your detailed answer! So it is absolutely normal for GZDoom. Is this a question you've often been asked by Sprite Fix users who play on GZDoom? Because if it is, if you want, I could create a new thread quoting your answer for everyone to see.

You're the first to bring up the visual discrepancy. I should note that the reason the clipping looks so extreme and sunken in your original screenshot is that you had the "Adjust sprite clipping" option set to either "Never" or "Smart", neither of which I would recommend. While this is still ultimately up to the user's preference, the sprite clipping setting that minimizes the discrepancy (and also my preferred choice) is "Smarter". This is not the default setting in GZDoom, so I wholeheartedly recommend all GZDoom hardware renderer users running the sprite fixes (and even those who don't) to switch to it as that's the simplest way to handle clipping as best as can be done short of changing to the software renderer.

Share this post


Link to post
7 minutes ago, Revenant100 said:

The nature of the DeHackEd fixes is such that they are as unintrusive as possible, and in the years I've been using and testing them, I've yet to come across one incompatibility, even with the most elaborate DeHackEd modifications. They even maintain perfect demo sync compatibility, which is quite a high bar to pass. I understand why Nash created ZScript conversions for the DEH patches, but given how the code works by replacing actors and states, I can't guarantee they can work as conflict-free in practice. Any ZScript conflict in this case would nonetheless be very minor, though, with the cosmetic effects of the fixes simply being overridden by other higher priority mods. However, I think sticking with the DeHackEd patch here could result in better guaranteed compatibility, perhaps something to test out and verify in the future.

 

You're the first to bring up the visual discrepancy. I should note that the reason the clipping looks so extreme and sunken in your original screenshot is that you had the "Adjust sprite clipping" option set to either "Never" or "Smart", neither of which I would recommend. While this is still ultimately up to the user's preference, the sprite clipping setting that minimizes the discrepancy (and also my preferred choice) is "Smarter". This is not the default setting in GZDoom, so I wholeheartedly recommend all GZDoom hardware renderer users running the sprite fixes (and even those who don't) to switch to it as that's the simplest way to handle clipping as best as can be done short of changing to the software renderer.

Alright, just saw the "Smarter" setting and applied it. Never occurred to me to see if there was a setting above "Always" :/

Now the sprite offset is correct. Thank you, cheers!

Share this post


Link to post

I have noticed that in the latest version of this mod, the first imp gibbing frame is offset a few pixels to the left compared to its front facing pain frame which it is based on.

SLADE_BlbtiaOlKM.png

SLADE_c0xuGkvCi3.png

Share this post


Link to post
On 11/6/2022 at 2:41 AM, Eggman07 said:

I have noticed that in the latest version of this mod, the first imp gibbing frame is offset a few pixels to the left compared to its front facing pain frame which it is based on.

That's a fine catch. I had already realigned the Imp's front-facing pain frame to match the feet position of his first death frame, but I had only realigned his gibbing frames to add internal consistency throughout that one sequence. I've just now shifted all of the Imp's gibbing frames so that they match the feet position in both his pain and initial death frames.

 

On an unrelated note, while looking over the Revenant sprites as part of an investigation into a different matter, I finally noticed a glaring art inconsistency that's been staring us in the face for decades: The Revenant's iconic three red arm markings actually disappear in two frames right in the middle of his walking sequence! Using the surrounding frames as close reference points, I have manually drawn these markings back in.

 

0RstVBQ.png

 

This will likely be the last major art edit before the upcoming 2.0 release which is still scheduled for the project's 10th anniversary, only a short couple of weeks away now!

Edited by Revenant100

Share this post


Link to post
On 11/15/2022 at 2:03 AM, Revenant100 said:

This will likely be the last major art edit before the upcoming 2.0 release

Looks like I spoke too soon, as the ole IWADs still have a few secrets to reveal even after all this time!

 

SFmkRJF.png

 

In total, five Hell Knight frames have just now received art edits to address the minor visual inconsistencies between it and the Baron's frames. Additionally, as previously mentioned, six Hell Knight walking frames have had further offset and padding refinements to absolutely guarantee perfectly matching offsets with the Baron's walking frames. In other words, we can finally say that, after 28 years, the Baron of Hell and Hell Knight have finally reached visual parity. Tell that to the next person who says the Hell Knight is just a palette swap!

 

All this coming soon in the ever approaching 2.0 release.

Edited by Revenant100

Share this post


Link to post

Would you mind looking at some pickup and decorative sprites for adjusting offsets? Specific ones I think could use adjustment are COLU, BPAK, PMAP, and PVIS.

Share this post


Link to post

Hi I have a question regarding the Baron walking frames. I read the change log and it mentioned you added extra walking frames from the alpha 0.2 version, however when I looked at the Full Modder's Resource WAD AND the current latest version of this pwad. All I see are just renamed frames (A2A8 to A2C8 for example) instead of the unique ones present in the alpha 0.2. Am I missing something or did you revert this change some time ago? I would appreciate an answer.

Share this post


Link to post
9 hours ago, NaliSeed said:

I'm guessing there are no sprites to fix in Hexen? 😊

The Doom sprite fixes have had priority over Heretic and Hexen, so there won't be any major developments in those areas at least until the Doom project's 2.0 release, which is now right on the horizon.

 

9 hours ago, maxmanium said:

Would you mind looking at some pickup and decorative sprites for adjusting offsets? Specific ones I think could use adjustment are COLU, BPAK, PMAP, and PVIS.

Due to their fixed and static nature coupled with the occasionally very precise visual placements by map authors, the offsets on decorations and items have rarely been touched over the years as any tweaks, even minor, have the potential of breaking intended map visuals. The few exceptions involved adding consistency between like items (Berserk Pack and Medikit, the different Keycards). Hence, no other offset tweaks are being considered for these item types at the moment.

 

9 hours ago, Eggman07 said:

Hi I have a question regarding the Baron walking frames. I read the change log and it mentioned you added extra walking frames from the alpha 0.2 version, however when I looked at the Full Modder's Resource WAD AND the current latest version of this pwad. All I see are just renamed frames (A2A8 to A2C8 for example) instead of the unique ones present in the alpha 0.2. Am I missing something or did you revert this change some time ago?

The use of the alpha sprites for the Baron was undone in the 1.2 version release, as the changelog mentions, since they were replaced by the relevant 1.0 Shareware sprites. These shareware sprites contained the official versions of the cosmetic fixes I had done manually beforehand, and the alpha sprites as a whole weren't necessary since they are 100% mirrored graphics, not actually unique, making them redundant since the extra frames didn't add anything of value.

Share this post


Link to post

The usual question: I assume none of the changes require updated brightmaps, right? It didn't seem to be the case in the betas already.

Share this post


Link to post
9 hours ago, NightFright said:

The usual question: I assume none of the changes require updated brightmaps, right? It didn't seem to be the case in the betas already.

The following Hell Knight sprites have had their dimensions altered in v2.0:
 

Quote

BOS2A6C4
BOS2A7C3
BOS2A8C2
BOS2B6D4
BOS2B7D3
BOS2B8D2

 

There were no fundamental changes to the artwork itself that would affect the art of the brightmaps. The brightmaps just need to be appropriately readjusted in positioning and dimensions.

Share this post


Link to post

Brightmaps for Sprite Fixing Project v1.92 have been released.

Thanks to Revenant100 for pointing out the relevant changes. Saved me a lot of time!

 

(I was wondering at first why only the Hell Knight frames were adjusted and not the Baron ones as well, but it's actually explained a few posts above.)

Edited by NightFright

Share this post


Link to post

I don't know if this is really an error or part of the art, but SARGA1 & SARGC1 have some brown pixels on one of the arms. Might look better with pink/red pixels?

Share this post


Link to post
On 12/1/2022 at 6:33 PM, maxmanium said:

I don't know if this is really an error or part of the art, but SARGA1 & SARGC1 have some brown pixels on one of the arms. Might look better with pink/red pixels?

I gather you mean the brown pixels used for the shadowing behind the Demon's left horn. For reference:

sfxBFh3.png

 

As a matter of lineage, we're able to trace this shading back to the revamped Demon sprites introduced around the time of the press release beta which brightened the highlights and darkened the shadows to emphasize the more exaggerated perspective of the redrawn walking frames.

RDbwber.gif

 

While it's true this brown color is not similarly used for the darkest shading in any other Demon sprite (or even earlier pre-press release beta sprite incarnations, for that matter), this is not the only example of such a circumstance. SARGB1 and its mirrored SARGD1 use pure black for the darkest shading in the same area of the body which is not done in any other Demon sprite as well. Check the right frame for comparison.

2fgUOde.png

 

Even though it's not within the pink range of the color palette which is otherwise used consistently throughout all of the other Demon sprites, I wouldn't say this one-off use of pure black for shading is an error as signs point to it being a deliberate use. Similarly, I can't say the use of brown in SARGA1/C1 is an outright error either for the same reason. I'd liken this to the few green pixels used for the shading in the Zombieman in that this can be regarded as yet another odd quirk of id's art. Since I can't expressly identify this as a mistake or oversight, it doesn't warrant a fix.

Share this post


Link to post

If these have been mentioned before, please disregard ...

 

1. Note that the arachnotron appears to fire is plasma from its left eye.

2. I think the cyber could use sprite subnumber 32773 for frames 685, 687 and 689.

3. Some of the hanging dead bodies could use a slight padding offset, to show the "rope"? dead centre.

Similar for the firecan.

 

 

Edited by hawkwind

Share this post


Link to post
On 12/5/2022 at 7:57 PM, hawkwind said:

1. Note that the arachnotron appears to fire is plasma from its left eye.

The Arachnotron's firing frames could be centered significantly more (more than I feel would be prudent in terms of the scope of the fixes), but that would still result in the plasma balls firing too high from its eyes. When it comes to demon projectiles visually matching the position they should emit from, Doom has a pretty spotty track record. The Cyberdemon's rocket comes from his crotch, the Mancubus' fireballs emit out of his belly, and the Revenant offers the most egregious sight as he clearly fires two different shoulder-mounted launchers simultaneously yet only produces a single missile every time! (Boy, I really hope somebody got fired for that blunder!)

 

Ultimately, making a monster's projectile origin visually match the position on the sprite is not something that can truly be fixed from the art side, hence this goal isn't within the scope of the project. Realistically, fixing this the proper way (i.e. with code) is rife with issues, so it's just a quirk we have to live with.

 

Quote

2. I think the cyber could use sprite subnumber 32773 for frames 685, 687 and 689.

For anyone who isn't clear, this is suggesting that the Cyberdemon's firing frames should be always lit. Well, you're in luck, as this fix has already been made in the Doom 1 and 2 Minor DeHackEd Fixes which are included in the Minor Sprite Fixing Project as an optional DeHackEd-based augmentation!

 

Quote

3. Some of the hanging dead bodies could use a slight padding offset, to show the "rope"? dead centre.

Similar for the firecan.

As mentioned above, the offsets on decorative objects have rarely been touched over time as their placements by map authors can be very precise and deliberate. Shifting things even a few pixels can make a big visual difference in Doom, especially with these objects that are assumed to be fixed and static, so moving the artwork around is not something mappers could account for. Additionally, one other aspect I didn't mention above is that, while centering sprites makes reasonable sense on a technical level, it's clearly not an aim id's artists were striving for when it comes to the decorations.  Hence, it's not really wrong or an error. Again, this is more like another quirk that's just become so deeply ingrained in the games.

Edited by Revenant100

Share this post


Link to post

I've made an unofficial patch for the arachnotron firing. Now is close to what it

should look like.  Now shoots from its gun and not its left eye. Not included in the official patch as was not considered to

come under the purview of the spritefix project and other reasons. I have Revenant100's approval for posting this.

Load the patch after loading D2SPFX20.wad ( or D1SPFX20.wad ) .

Enjoy.

arachfix.zip

Share this post


Link to post

I understand that there were some changes to the Hell Knight, Baron of Hell, and Revenant. May I ask specifically which frames were edited in the 2.0 release?

Share this post


Link to post
On 1/1/2023 at 5:32 PM, ChaoticReverie said:

I understand that there were some changes to the Hell Knight, Baron of Hell, and Revenant. May I ask specifically which frames were edited in the 2.0 release?

The following Hell Knight, Baron, and Revenant frames were visually altered in some appreciable fashion (including just offset adjustments) in v2.0:

Quote

BOS2A6C4
BOS2A7C3
BOS2A8C2
BOS2B6D4
BOS2B7D3
BOS2B8D2
BOS2G2
SKELB2E8
SKELB7E3

SKELI6
BOSSB2D8
BOSSC1
BOSSC5
BOSSD1
BOSSD5

 

The additional following frames, which only encompasses Revenant sprites, were "invisibly" altered in v2.0. These were affected by the duplicate palette color fix, but the changes are only visible under the very specific custom color palettes that are able to reveal these discrepancies. Under the normal Doom palette, these modified v2.0 frames look completely identical to their v1.9 counterparts.

Quote

SKELA5D5
SKELA6D4
SKELA8D2
SKELB3E7
SKELB4E6
SKELB8E2
SKELC1F1
SKELC2F8
SKELC3F7
SKELC4F6
SKELC6F4
SKELC7F3
SKELC8F2
SKELI7

 

Depending on your intent, you may not need to worry about anything in the second group here.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×