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

[Cire]

Yeah, true that.
Now I remembered that Sodaholic released a Doom Aesthetic Pack that I Think included texture fixes. Maybe it could contain useful fixes a Project such as mine?

[fraggle]

Revenant100 said:

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.

That's great. Although I'd really love to see the fixed sprites incorporated into the mods. If they're replacing all the sprites anyway, why not? IMO we should be encouraging authors of mods like this which change the palette to use the fixed sprites anyway.

By the way, great to see the sprite fix project is now in idgames!

[Da Werecat]

fraggle said:

If they're replacing all the sprites anyway, why not?

My thoughts as well.

[Manuel-K]

Thank you for you continuing work on this project and congratulations on the idgames archive release.

[kb1]

If the community could agree, it would be *really nice* to take perkristan's sound effects, the minor sprite fix project, and the minor texture fix, and combine them into an IWAD diff, and everyone could upgrade their IWAD to the community's own version 1.10 IWADs. This would only occur after everyone agreed that the resources were done and perfect. I guess you'd need a German version, and a BFG version, but it could be considered the definitive upgrade. Source ports could be adjusted as needed to see the IWAD as legit, and report "Community IWAD" vs "Retail", "Commercial", "Shareware", etc.

[wallabra]

kb1 said:

If the community could agree, it would be *really nice* to take perkristan's sound effects, the minor sprite fix project, and the minor texture fix, and combine them into an IWAD diff, and everyone could upgrade their IWAD to the community's own version 1.10 IWADs. This would only occur after everyone agreed that the resources were done and perfect. I guess you'd need a German version, and a BFG version, but it could be considered the definitive upgrade. Source ports could be adjusted as needed to see the IWAD as legit, and report "Community IWAD" vs "Retail", "Commercial", "Shareware", etc.

IWAD? Do you mean a separate game or distributing Doom as an IWAD with only minor sprite fixes?


If the case is the latter, then I fear there is a big problem: you shouldn't be distributing Doom WADs!

This patch can, though, be distributed freely as a PWAD (even merged with other PWADs) as long as it doesn't hold much copyrighted content from id Software et al.

[fraggle]

kb1 said:

the community's own version 1.10 IWADs.

It's a nice idea but good luck finding any adjectives left to name the project. We've already used up Ultimate, Maximum, Beautiful, Brutal, Wonderful, ...

[Reisal]

Is it permitted to upload the last two versions to the /idgames/ archive? They do need a permanent home and not just Google Drive or Mediafire.

[Da Werecat]

It's gonna be hard to make the community agree on what should be included in such a patch. For example, I don't like some of the enhanced sounds. Moreso, isn't it a lot like including high-res textures (if it would be possible for every engine)?

Minor Sprite Fixes should probably also be curated for something that claims to be a "definitive" anything.

[NightFright]

When it comes to tempering with original files, the rule should always be to not mess with them. I am fine with using external patches. Would never touch my iwads unless a patch is handed out by id directly.

[fraggle]

Glaice said:

Is it permitted to upload the last two versions to the /idgames/ archive? They do need a permanent home and not just Google Drive or Mediafire.

I mentioned it in my previous comment already, but:

https://www.doomworld.com/idgames/graphics/sprfix17

[Revenant100]

Thanks for all the kind words! With the advent of the idgames archive release, I've updated the download links accordingly. My gratitude to Bloodshedder and TheGreenHerring for taking the time to reevaluate the submission.

I'm still planning on Back to Saturn X and Sunlust compatibility patches, and as previously indicated, I'll put the Hexen fixes back on my radar now. I can't promise it will come particularly soon due to my current schedule, but I'll be keeping it in mind and will post any relevant updates on its development when applicable.

fraggle said:

Although I'd really love to see the fixed sprites incorporated into the mods.

They're certainly more than welcome to use these fixes, although I ultimately leave that decision to the mod authors in question. I've actually already put together a non-truncated version of the Ancient Aliens sprite fixes so the authors can easily merge the entire graphics set with a simple cut and paste, so I'll present that to them soon. The nice thing here is that switching out the sprites won't affect gameplay at all, so demo compatibility would be perfectly preserved. Unfortunately, this would still cause WAD mismatch errors in terms of on-line play unless the WAD was renamed, something not truly warranted by a purely cosmetic update, but we'll see how that may play out.

I do recall reading a few years back that the BTSX team was considering using an older release of these sprite fixes but chose not to due to problems with the palette converting and merging the sprites. However, I'll be doing all that heavy lifting on my own with my compatibility patch releases, so the matter will just be down to whether or not the relevant teams are interested in incorporating the fixes in their main releases.

kb1 said:

If the community could agree, it would be *really nice* to take perkristan's sound effects, the minor sprite fix project, and the minor texture fix, and combine them into an IWAD diff, and everyone could upgrade their IWAD to the community's own version 1.10 IWADs.

While a fanciful idea, that's likely to remain a pipe dream in the long run. It's probably best to leave these things as separate and distinct PWADs so matters of compatibility and player preference are not intruded upon. Rather, the most viable alternative would be to provide a single resource that conveniently links to the most up-to-date version of said projects for those interested.

Glaice said:

Is it permitted to upload the last two versions to the /idgames/ archive? They do need a permanent home and not just Google Drive or Mediafire.

As Fraggle mentioned, the latest 1.7 release is now up on the archive. However, if you mean older releases of the sprite fixes, I wasn't planning to upload those. It's not that I'm not interested in preserving them, but for the sake of avoiding confusion, I only planned on keeping the latest version uploaded on the archive. There's no issue with broken compatibility as you'd find with older level iterations and demos or some such, so at least there's no practical loss here. However, I do have all older versions backed up and can post them on request, although they don't offer much other than for curiosity value.

If you're referring to the Ancient Aliens compatibility patch, I'm not immediately planning to upload that either right now, but that's primarily because it was just released. I'd like to give it a bit longer testing to ensure no other changes or fixes are needed. If the authors are interested in officially incorporating the fixes, then there'd be no need for its own upload.

[Cire]

Yeah, congrats on the /idgames release! Glad to hear about the Hexen fixes too! :)

[kb1]

I can understand the enhanced sounds being not universally definitive. But the correction of sprites with misplaced pixels, and offsets, the addition of the missing rotations, and a thorough scrub of the textures and flats, could be turned into a bzdiff patch that everyone could agree with, right? Why not also include the TNT yellow key fix for Final Doom, and the sprite, texture and flat fixes, into bzdiff patches that hack your Doom 1.9 IWAD into what could be proudly called a Doom 1.10, Doom2 1.10, Plutonia1.10, and TNT1.10 set of IWADs? I mean, after all, we do have the "official" BFG-Edition abomination IWAD. Why not have a nice new IWAD? I have no problem fixing mine, anyway. Sure would be nice for it to be considered the new official IWAD.

[Cire]

Good luck with such a Project, though I'd prefer a PWAD. Also, if you plan on making such a Project, there are a lot more textures that needs fixing, I just did a few to start with. Also, there are a lot more maps with bugs than just TNT MAP31 that should be fixed also.

[Blastfrog]

A general quirk of the Doom engine is that when non-centered sprites are flipped in-game, the alignment becomes incorrect. The only workaround is to pad the image with transparency. The goal is to have the bounding box an even width of pixels and perfectly centered.

Given this project's focus on good alignment, this is something that should be addressed. Unfortunately, it's tedious to do by hand if dealing with a large volume of sprites.

Is there anyone out there that would be willing to write a utility to process sprites in this way?

[kb1]

Blastfrog said:

A general quirk of the Doom engine is that when non-centered sprites are flipped in-game, the alignment becomes incorrect. The only workaround is to pad the image with transparency. The goal is to have the bounding box an even width of pixels and perfectly centered.

Given this project's focus on good alignment, this is something that should be addressed. Unfortunately, it's tedious to do by hand if dealing with a large volume of sprites.

Is there anyone out there that would be willing to write a utility to process sprites in this way?

That's really a coding issue. An "IF" statement and a subtraction takes care of the issue.

[Blastfrog]

Yes, it is an engine issue, but there's nothing that can be done for stuff like vanilla.

A utility to work around it via padding is necessary.

[Spectre01]

Quick question, does this mod cause demo desync for those not running it? I've had some issues with Boom Enhanced before which added smooth weapon animation and I'm wondering if this addon has the same demo-related issues in GL/PRBoom+ or if it's safe to use.

[Revenant100]

Blastfrog said:

A general quirk of the Doom engine is that when non-centered sprites are flipped in-game, the alignment becomes incorrect. The only workaround is to pad the image with transparency. The goal is to have the bounding box an even width of pixels and perfectly centered.

I am aware of this issue. Strictly speaking, this is a general core engine matter, so it's not a problem with the sprites themselves. Compensating for the problem by adding padding to the artwork is feasible, but this is a significant blanket change that I'd want to ensure does not result in any unintended side effects.

For the record, many source ports already correct the sprite mirroring issue. Here's a brief rundown of the common ports that do:

Spoiler

• PrBoom+
  
• ZDoom
  
• GZDoom
  
• Eternity
  
• Doom Retro
  
• Zandronum (both software and OpenGL renderers)

The following source ports do not fix the sprite mirroring:

Spoiler

• Chocolate Doom (obvious, I know)
  
• Crispy Doom
  
• ZDaemon
  
• Odamex
  
• GLBoom+

rileymartin said:

Quick question, does this mod cause demo desync for those not running it?

The included WAD files only contain graphic lumps for the sprite fixes, so those cannot cause demo desyncs.

The only parts that might cause issues are the optional DeHackEd fixes. However, I've had these DEH patches autoloaded while running dozens of demos, including full game runs, and I've yet to see a desync occur.

Someone with more intimate knowledge of the engine is free to confirm or deny this assertion, but I believe the minor changes made in the DeHackEd patches will not affect game logic sync:

• Some non-bright frames were made bright, and vice versa. I'm certain these are innocuous.
  
• The length of the Super Shotgun's two muzzle flash frames were each reduced by one tic. This is the only alteration that could theoretically cause problems, but the muzzle flash frames are rendered independently of the weapon so that they don't affect its performance, and the called Light1 and Light2 codepointers are purely cosmetic.

[fabian]

Revenant100 said:

The following source ports do not fix the sprite mirroring:

Do you mean these lines in src/r_things.c:R_ProjectSprite() (example taken from PrBoom+)?

    /* calculate edges of the shape
     * cph 2003/08/1 - fraggle points out that this offset must be flipped
     * if the sprite is flipped; e.g. FreeDoom imp is messed up by this. */
    if (flip) {
      tx -= (patch->width - patch->leftoffset) << FRACBITS;
    } else {
      tx -= patch->leftoffset << FRACBITS;
    }
    x1 = (centerxfrac + FixedMul(tx,xscale)) >> FRACBITS;

[Revenant100]

Yes, that bit of code properly mirrors sprites based on their non-mirrored offsets. The vanilla doom2.exe behavior is to automatically recenter all mirrored sprites, thus erasing any manual offsets that had been set.

As an example, here's a side-by-side comparison of the issue alongside what a fix looks like:



This is by no means the most extreme manifestation, but it's a good illustration of how the problem only affects the mirrored versions of sprites. This also demonstrates that introducing the right amount of padding to the sprites does appropriately compensate for the improper recentered offsets. As noted, though, the above code snippit equally addresses the problem on an engine level with identical results.

[Blastfrog]

I want Slade 3 to have a padding feature regardless for cases where an engine-side fix can't be relied on, such as vanilla.

[fabian]

Revenant100 said:

Yes, that bit of code properly mirrors sprites based on their non-mirrored offsets.

Fixed in GIT, thank you!

[kb1]

fabian said:

Do you mean these lines in src/r_things.c:R_ProjectSprite() (example taken from PrBoom+)?

    /* calculate edges of the shape
     * cph 2003/08/1 - fraggle points out that this offset must be flipped
     * if the sprite is flipped; e.g. FreeDoom imp is messed up by this. */
    if (flip) {
      tx -= (patch->width - patch->leftoffset) << FRACBITS;
    } else {
      tx -= patch->leftoffset << FRACBITS;
    }
    x1 = (centerxfrac + FixedMul(tx,xscale)) >> FRACBITS;

Yep. And, yes padding the sprites fixes it everywhere. Note that this padding can also affect Revenant100's carefully placed offsets. Basically you start with the monster's center of gravity (inbetween their feet, for example). Then, from that center, the width of sprite to the right of that center point should match the width to the left of center. The offset is then total sprite width divided by 2. With an odd width, the offset is (W/2)+1, and you have an exact center. So, it may make sense to make the width odd (or even) at times - whatever looks less wobbly.

[Blastfrog]

With padding, the sprite width should always be even and the bounding box should be perfectly centered. In no way would it screw the offsets up, the results would be identical to an unpadded sprite in a port with correct mirroring behavior.

On another note, I believe there might be an error in the number 5 for the status bar. It appears they neglected to give it a full outline, inconsistent with all other status bar numbers.

I made an adjusted version:



Compare:



Also, when digging through Romero's stuff I found that POL5A0 actually had a couple extra pixels that were cut off when imported into the game. This is the full version:



Lastly, I do think there should be an effort to make a texture fix project. I made these:

[kb1]

Blastfrog said:

With padding, the sprite width should always be even and the bounding box should be perfectly centered. In no way would it screw the offsets up, the results would be identical to an unpadded sprite in a port with correct mirroring behavior.

Not necessarily - the bounding box is perfectly centered regardless. It will be identical regardless (0 to 12 vs. 12 to 0 reversed, or 0 to 13 vs. 13 to 0 reversed). The only effect even vs odd has is whether the center lies on a pixel (odd) or between a pixel (even).

Regardless, objects don't freely reverse or rotate, so the only time you'll be able to detect a wobble is during a walking animation. If you're consistent (all even or all odd), it really won't matter much, but if you mix it up, you might be able to see a half-pixel wobble. It depends largely on how the sprites are drawn, and, again, at that scale, it would be difficult to notice anyway.

Having said all that, if you use odd widths, you will have a definite center line. For a left-to-right symetrical monster, I'd choose the center line that most correctly divided the monster in half. If that occurs on a pixel, use an odd width. Otherwise if it occurs inbetween a pixel, use even width. You can't really go wrong with that approach.

Blastfrog said:

On another note, I believe there might be an error in the number 5 for the status bar. It appears they neglected to give it a full outline, inconsistent with all other status bar numbers.

I made an adjusted version:

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

Compare:

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

Also, when digging through Romero's stuff I found that POL5A0 actually had a couple extra pixels that were cut off when imported into the game. This is the full version:

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

Nice finds.

Blastfrog said:

Lastly, I do think there should be an effort to make a texture fix project. I made these:
http://i.imgur.com/uiJq8ZX.pnghttp://i.imgur.com/OmOYxrY.png

Totally agree. I've mentioned before that I'd love to see the community develop a once-and-final v1.10 iwad. I think it could be possible.

[HavoX]

Blastfrog said:

Lastly, I do think there should be an effort to make a texture fix project.

Then allow me to contribute.
https://www.dropbox.com/s/uq4wui6vkyzbu0m/W105_1.png

A few days ago, I noticed the W105_1 texture in the IWADs was not cropped properly. I'm not sure if there are other wads that contain this fixed texture, but it was more than an easy fix for me...

[Da Werecat]

I did some texture fixing last year, although some of it it pretty intrusive.

[Medis]

Revenant100 said:

I am aware of this issue. Strictly speaking, this is a general core engine matter, so it's not a problem with the sprites themselves. Compensating for the problem by adding padding to the artwork is feasible, but this is a significant blanket change that I'd want to ensure does not result in any unintended side effects.

For the record, many source ports already correct the sprite mirroring issue. Here's a brief rundown of the common ports that do:

The following source ports do not fix the sprite mirroring:

Spoiler

• Chocolate Doom (obvious, I know)
  
• Crispy Doom
  
• ZDaemon
  
• Odamex
  
• GLBoom+

After seeing this post, we (Thanks noncom!) made a commit to ZDaemon that fixes this. Nice findings guys. If lucky and gets accepted it will appear in next release/beta (1.10b08)

https://www.youtube.com/watch?v=ms2Cg0UJVO8&feature=youtu.be