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

[Revenant100]

32 minutes ago, MugMonster said:

I was looking at Scientist in Crispy Doom since it got added to the Unity Add-Ons and noticed it doesn't seem to be compatible with this project.

If you're loading the WAD file for Scientist as taken directly from the Unity port right now, then all of the sprite fixes will be overridden because this WAD file is essentially its own IWAD, meaning it contains the entirety of Doom 2's sprites (and all other assets). For technical reasons, all of the Unity Doom add-ons are packaged as IWADs. If you want to play Scientist outside of the Unity port, I recommend waiting for the idgames archive version which is being uploaded right now which will omit all of the redundant IWAD resources and therefore allow more of the sprite fixes to take effect. Do note that Scientist does replace many Imp, Demon, and Doomguy sprites to give them glowing eyes, hence they'll override a lot of the sprite fix frames for those guys.

[MugMonster]

7 minutes ago, Revenant100 said:

If you're loading the WAD file for Scientist as taken directly from the Unity port right now, then all of the sprite fixes will be overridden because this WAD file is essentially its own IWAD, meaning it contains the entirety of Doom 2's sprites (and all other assets). For technical reasons, all of the Unity Doom add-ons are packaged as IWADs. If you want to play Scientist outside of the Unity port, I recommend waiting for the idgames archive version which is being uploaded right now which will omit all of the redundant IWAD resources and therefore allow more of the sprite fixes to take effect. Do note that Scientist does replace many Imp, Demon, and Doomguy sprites to give them glowing eyes, hence they'll override a lot of the sprite fix frames for those guys.

 

ya know, I had used the spfx wad with the unity wads before without issue, but it only just occurred to me that that's because with those ones, I had no issue putting the spfx higher in priority, while with this one I cant do that for obvious reasons.  so hey, that makes sense lol

I was aware the author was uploading another version to the archives as he mentioned it in the big thread for the unity port, but I brought it up here as a separate issue because of the aforementioned "not realizing the iwad was the problem, not the mod itself."  so, yeah, hopefully the archives version won't have any issues.  thanks for clarifying

[liPillON]

hey Revenant, thank you for keeping this updated over the years

 

I just noticed that BOSSB2D8 differs between D2SPFX20.WAD and D1SPFX20.WAD

The latter seems to be an older, un-fixed version: a pixel in Baron's elbow is missing

 

[MrHellstorm17]

Is this demo compatible?

[Billa]

18 minutes ago, MrHellstorm17 said:

Is this demo compatible?

No, it's not allowed for recording demos. Assuming you want to submit them to DSDA, nothing is stopping you recording for your own purposes

[MugMonster]

3 hours ago, MrHellstorm17 said:

Is this demo compatible?

 

it doesnt cause desync in crispy doom, at least

[Revenant100]

10 hours ago, liPillON said:

I just noticed that BOSSB2D8 differs between D2SPFX20.WAD and D1SPFX20.WAD

The latter seems to be an older, un-fixed version: a pixel in Baron's elbow is missing

 

Thanks for the report! This is indeed a mistake, and I've noted it for the next release.

 

10 hours ago, MrHellstorm17 said:

Is this demo compatible?

If you're recording a speedrun for formal submission to DSDA, you shouldn't have any unnecessary external WADs loaded while playing, and the sprite fixes fall under that umbrella.

 

However, for demo playback, the sprite fixes and the DeHackEd fixes are both demo compatible. The sprite fixes in the WAD are purely cosmetic graphic replacements, so there's no surprise there, but it is indeed unusual for a DeHackEd patch to be demo sync safe. The changes in the DeHackEd patch are also purely cosmetic, though, and they were carried out in such a way that they don't cause conflict with demo compatibility, hence they can safely be loaded while running demos.

[Foxface]

 

Capybara unofficial compatibility patch (load the sprite fixes after capybara.wad)

• D2SPFX-capybara.zip (129 KB)

[Pretend there is a nice clickable imgur thumbnail here]

 

[Foxface]

duplicate post? oops.

[DoomGappy]

I hope I'm not again making a fuss about nothing. I've noticed that the flaming barrels are very off center, which means that they spin around out of whack. You can see them completely different depending on where you stand. These are in a map I'm making and they were supposed to be in the middle, but they just keep changing places. Is this something this project aims to fix? I have the hypothesis that it's off-center like this because of the flame, and I don't know if it would break it to have it any other way. 

 

 

 

Evil eye as marker. Far side:

 

 

Near side: 

 

 

There may be other offsets worth checking, but this one is quite jarringly bad. 

Edited October 10, 2023 by jo2ukegappy

[Revenant100]

14 hours ago, jo2ukegappy said:

I've noticed that the flaming barrels are very off center, which means that they spin around out of whack. You can see them completely different depending on where you stand. These are in a map I'm making and they were supposed to be in the middle, but they just keep changing places. Is this something this project aims to fix? I have the hypothesis that it's off-center like this because of the flame, and I don't know if it would break it to have it any other way.

You are correct in that the offsets for the burning barrel decoration are not intuitively centered which would be to put the barrel itself smack dab in the middle. However, it is technically centered when taking the blowing flames into account which spill over the edge. The offsets could be adjusted to center them in a more natural fashion, but the problem here lies in the fact that these sprites are not seen in dynamic, roaming positions like monsters. The burning barrel is a static decoration placed into its fixed positions by mappers. Sometimes these placements can be very precise, and when you alter the sprite's offsets, you end up breaking the mapper's intended visuals.

 

Here are two examples of such burning barrels use that come to mind from All Hell is Breaking Loose MAP01 and TNT MAP02:

 

These are not the best or most extreme examples as the centered offsets in these instances appear satisfactory enough, but they do illustrate just how much tweaking the offsets of decorations can alter the visuals that would never have been originally envisioned or could be accounted for by the mappers. The All Hell is Breaking Loose fireplace (an example of a sprite viewed from a fixed perspective as you can't circle around it) now has a strange open gap to the left side while the flame clips into the right brick wall. In TNT MAP02, the human barbecue visible as soon as you enter is the very namesake of the map, and with centered offsets, the fire doesn't seem to quite fill the eponymous barbecue pit, and the flame seems to be missing the hanging human corpse above. However, the hanging corpse decoration itself is intuitively (again, not technically) off-center. Hence, you can also see here the potential domino effect where adjusting the offsets of some decorations and not others can create problems, and while in this case both decorations could be centered so they at least maintain their relative positions, unavoidable visual conflicts would occur with other object combinations.

 

The last thing to consider here is whether or not this is actually an outright error. While we can discern a lot of the intent about the intended sprite offsets for the monsters, there's no such evident aim from id's artists when it comes to the decorations. As I've alluded to in the past, this is another one of the game's quirks that's become deeply ingrained into what's been built with it in mind. Although there's certainly merit in the notion, centering the decorations in a more natural fashion is not truly a "fix", and it'll cause problems in both past and future WADs which makes it unsuitable for this project.

[DoomGappy]

3 hours ago, Revenant100 said:

You are correct in that the offsets for the burning barrel decoration are not intuitively centered which would be to put the barrel itself smack dab in the middle. However, it is technically centered when taking the blowing flames into account which spill over the edge. The offsets could be adjusted to center them in a more natural fashion, but the problem here lies in the fact that these sprites are not seen in dynamic, roaming positions like monsters. The burning barrel is a static decoration placed into its fixed positions by mappers. Sometimes these placements can be very precise, and when you alter the sprite's offsets, you end up breaking the mapper's intended visuals.

 

Here are two examples of such burning barrels use that come to mind from All Hell is Breaking Loose MAP01 and TNT MAP02:

 

These are not the best or most extreme examples as the centered offsets in these instances appear satisfactory enough, but they do illustrate just how much tweaking the offsets of decorations can alter the visuals that would never have been originally envisioned or could be accounted for by the mappers. The All Hell is Breaking Loose fireplace (an example of a sprite viewed from a fixed perspective as you can't circle around it) now has a strange open gap to the left side while the flame clips into the right brick wall. In TNT MAP02, the human barbecue visible as soon as you enter is the very namesake of the map, and with centered offsets, the fire doesn't seem to quite fill the eponymous barbecue pit, and the flame seems to be missing the hanging human corpse above. However, the hanging corpse decoration itself is intuitively (again, not technically) off-center. Hence, you can also see here the potential domino effect where adjusting the offsets of some decorations and not others can create problems, and while in this case both decorations could be centered so they at least maintain their relative positions, unavoidable visual conflicts would occur with other object combinations.

 

The last thing to consider here is whether or not this is actually an outright error. While we can discern a lot of the intent about the intended sprite offsets for the monsters, there's no such evident aim from id's artists when it comes to the decorations. As I've alluded to in the past, this is another one of the game's quirks that's become deeply ingrained into what's been built with it in mind. Although there's certainly merit in the notion, centering the decorations in a more natural fashion is not truly a "fix", and it'll cause problems in both past and future WADs which makes it unsuitable for this project.

 

I appreciate your dedication and well thought out responses. It seems to be one of those things that is good in some situations but bad in others. It really bothers me a lot how the barrel changes places so much when you see it in a 3D environment where it's supposed to be static, but I can make a simple fixed barrels mod just for my own use. It's ultimately one of those cases of things that are weird but we've grown used to. Icidentally, I also used 12 for the offset. Thanks again!

[Bytefyre]

Hello!  I would like to request sprite fix patches for some of Nirvana's PWADs, most notably Fractured Worlds, Breathless, and Entropy, please.  Thank you!

[Revenant100]

5 hours ago, Bytefyre said:

I would like to request sprite fix patches for some of Nirvana's PWADs, most notably Fractured Worlds, Breathless, and Entropy, please.  Thank you!

I appreciate the suggestions. In order to keep the number of compatibility patches I need to continue maintaining over time reasonable, I do limit the scope of what necessitates a compatibility patch in the first place. For the most part, this means the project in question is large enough to warrant the endeavor. As of now, all of the compatibility patches available are (or are planned to be) megawads in size (or close to it) with one exception. Dimension of the Boomed only consists of six real maps, but I created a compatibility patch at the time with the notion that these Quake-styled assets could serve as the base resources for future similar Quake-styled projects, hence the patch may have use beyond just this one PWAD. Were I posed with the same choice today, though, I would have to give the prospect some serious consideration.

 

And therein lies the issue with the Nirvana projects you've mentioned. Breathless and Entropy are both single-level PWADs, and while they're undoubtedly grand in scale, they realistically don't meet the threshold for compatibility patches. Fractured Worlds, having eight real levels, is just on the cusp of what I would consider justifying the ongoing support of a compatibility patch, but there's one other factor at play here. Many of the overriding sprites included in Fractured Worlds are outright graphical edits of the original monster sprites, albeit mostly recolors. This means that I would have to manually redo the relevant sprite fixes on these edited sprites, and in some cases, it would necessitate accurately recreating the original color palette translations first, thus putting even more of the burden on me. Unfortunately, I can't commit to the creation and the ongoing support and maintenance of sprite fix compatibility patches for these particular PWADs.

 

I don't want to end this on a down note, so I'll say this in regards to any and all future projects: I encourage map authors to integrate these sprite fixes of their own volition. For everyone else, perhaps feel free to inform said map authors of the open availability of such sprite fixes and that you would like to see them integrated into their projects. It by no means has to just be me to ensure sprite fix compatibility. As I've said from day one, this project is an open resource for use by the entire community. I've long provided the resources tailored for modders to make this a simple task, which several out there have already taken advantage of, and it requires no more work than what would already be needed to modify the original IWAD artwork. In the end, these sprite fixes have been around for quite some time and won't be going anywhere, the greater awareness of and their adoption rate will only continue to increase, and the development of the project isn't going to end any time soon. (And by the by, happy 11th anniversary to the Minor Sprite Fixing Project!)

[Bytefyre]

9 hours ago, Revenant100 said:

I appreciate the suggestions. In order to keep the number of compatibility patches I need to continue maintaining over time reasonable, I do limit the scope of what necessitates a compatibility patch in the first place. For the most part, this means the project in question is large enough to warrant the endeavor. As of now, all of the compatibility patches available are (or are planned to be) megawads in size (or close to it) with one exception. Dimension of the Boomed only consists of six real maps, but I created a compatibility patch at the time with the notion that these Quake-styled assets could serve as the base resources for future similar Quake-styled projects, hence the patch may have use beyond just this one PWAD. Were I posed with the same choice today, though, I would have to give the prospect some serious consideration.

 

And therein lies the issue with the Nirvana projects you've mentioned. Breathless and Entropy are both single-level PWADs, and while they're undoubtedly grand in scale, they realistically don't meet the threshold for compatibility patches. Fractured Worlds, having eight real levels, is just on the cusp of what I would consider justifying the ongoing support of a compatibility patch, but there's one other factor at play here. Many of the overriding sprites included in Fractured Worlds are outright graphical edits of the original monster sprites, albeit mostly recolors. This means that I would have to manually redo the relevant sprite fixes on these edited sprites, and in some cases, it would necessitate accurately recreating the original color palette translations first, thus putting even more of the burden on me. Unfortunately, I can't commit to the creation and the ongoing support and maintenance of sprite fix compatibility patches for these particular PWADs.

 

I don't want to end this on a down note, so I'll say this in regards to any and all future projects: I encourage map authors to integrate these sprite fixes of their own volition. For everyone else, perhaps feel free to inform said map authors of the open availability of such sprite fixes and that you would like to see them integrated into their projects. It by no means has to just be me to ensure sprite fix compatibility. As I've said from day one, this project is an open resource for use by the entire community. I've long provided the resources tailored for modders to make this a simple task, which several out there have already taken advantage of, and it requires no more work than what would already be needed to modify the original IWAD artwork. In the end, these sprite fixes have been around for quite some time and won't be going anywhere, the greater awareness of and their adoption rate will only continue to increase, and the development of the project isn't going to end any time soon. (And by the by, happy 11th anniversary to the Minor Sprite Fixing Project!)

That's totally fair and I understand completely.  Thanks for getting back to me so quickly!

[Revenant100]

Happy 30 years of Doom! And you know what that means! That's right, it's time for another sprite fix release for another SIGIL installment! Hence, I present to you this fine anniversary today the SIGIL II Sprite Fixing Project!

 

While you've been playing the recently released hot new WAD SIGIL II, you've undoubtedly noticed something was wrong the moment you launched the game. Your instincts serve you well, for that's because you've noticed and been distracted by the very same error that plagued SIGIL I nearly half a decade ago: The new Christopher Lovell artwork included in SIGIL II is unnaturally stretched vertically by 20%. This is due to the fact that the aspect ratio was not considered when importing the graphics in the WAD. As such, I have yet again taken the liberty of tracking down the original artwork and redoing the new graphics while taking the aspect ratio correction into account. I also ensured that my adjustments and processing of the artwork was faithful and authentic to the appearance of the original SIGIL II graphic lumps.

 

As of this writing, these sprite fixes are up to date with v1.0 of the WAD and are compatible with both the SIGIL_II_V1_0.WAD and SIGIL_II_MP3_V1_0.WAD versions of SIGIL II. Simply load SIGIL_II_V1_0_SPFX.WAD after either one.

 

Download:
https://drive.google.com/file/d/1hXHQb2zkgSteHXyoJPKYz4S-id1rbbaZ/view?usp=sharing

 

Preview comparison:

 

And also, I am aware of the release of Eviternity II and its dire need of sprite fixes. Do not fret, for a compatibility patch is now in production and on its way soon!

Edited December 10, 2023 by Revenant100

[DoomGappy]

9 minutes ago, Revenant100 said:

Happy 30 years of Doom! And you know what that means! That's right, it's time for another sprite fix release for another SIGIL installment! Hence, I present to you this fine anniversary today the SIGIL II Sprite Fixing Project!

 

While you've been playing the recently released hot new WAD SIGIL II, you've undoubtedly noticed something was wrong the moment you launched the game. Your instincts serve you well, for that's because you've noticed and been distracted by the very same error that plagued SIGIL I nearly half a decade ago: The new Christopher Lovell artwork included in SIGIL II is unnaturally stretched vertically by 20%. This is due to the fact that the aspect ratio was not considered when importing the graphics in the WAD. As such, I have yet again taken the liberty of tracking down the original artwork and redoing the new graphics while taking the aspect ratio correction into account. I also ensured that my adjustments and processing of the artwork was faithful and authentic to the appearance of the original SIGIL II graphic lumps.

 

As of this writing, these sprite fixes are up to date with v1.0 of the WAD and are compatible with both the SIGIL_II_V1_0.WAD and SIGIL_II_MP3_V1_0.WAD versions of SIGIL II. Simply load SIGIL_II_V1_0_SPFX.WAD after either one.

 

Download:
https://drive.google.com/file/d/1hXHQb2zkgSteHXyoJPKYz4S-id1rbbaZ/view?usp=sharing

 

Preview comparison:

 

And also, I am aware of the release of Eviternity II and its dire need of sprite fixes. Do not fret, for a compatibility patch is now in production and on its way soon!

Why is it called sprite fixing project if those are textures? I sure hope someone got fired for that blunder!

[Revenant100]

Greetings again, this fine 30th anniversary! I come this time with yet another sprite fix project release, this time one that fixes actual sprites! You got it, I'm bringing you the initial work-in-progress release of the Eviternity II compatibility patch!

 

Of course made for Eviternity II, the entirety of the relevant sprite fixes have been converted and will take effect on the unmodified monsters, weapons, items, and so forth. However, I've also gone a small step beyond and performed an offset adjustment pass on several of Eviternity II's new monsters, bringing them more in line with the rest of the project. This isn't going to be a full sprite fix pass on all of these new graphics, but I will be continuing on the cursory work I've started here for the sake of more consistency and to fix small errors I've found throughout Eviternity II's sprites.

 

So without further ado, the download link has been added to the OP and is copied here as well for convenience.

 

As of this writing, this release of the sprite fixes is compatible with the "RC5" build of Eviternity II.

 

Eviternity II compatibility patch (load the sprite fixes after "Eviternity II RC5.wad"):

• (Outdated, see original post)

 

Preview image:

 

This sprite fixing project is in its effectively complete state. However, given the work-in-progress nature of Eviternity II, I recommend checking on this thread in the near future for further updates as new versions of the PWAD are released. Also, should you come across any sprite fix-specific issues, please report them in this thread.

Edited September 8 by Revenant100

[Devalaous]

Would be ideal if those above sprite fixes got integrated into the wads officially, since both of them arent 'final', like how BTSX's ones got officialised

[maxmanium]

9 hours ago, Devalaous said:

Would be ideal if those above sprite fixes got integrated into the wads officially, since both of them arent 'final', like how BTSX's ones got officialised

 

@Dragonfly

[Dragonfly]

Awesome stuff; I wouldn't be against it's inclusion into Eviternity II!

 

That said, I would prefer to wait until it's more widely tested / refined (I've not checked myself but Revenant100's post indicates how it's WIP atm), and to also wait until Evi2 is closer to a final build. :)

[pudz]

Thank you for the great work - for over a decade at that! 

I'm just wondering, when using WadSmoosh, which of the fixes should I load? Just Doom 1's/Doom 2's (and optionally Sigil's if that's also added) or both? Thanks again. 

[Revenant100]

6 hours ago, Dragonfly said:

Awesome stuff; I wouldn't be against it's inclusion into Eviternity II!

These Eviternity II sprite fixes are absolutely all yours to integrate and use when you need. In their current state, the implementation is as simple as directly cutting the lumps from the sprite fix WAD and pasting them into the Eviternity II PWAD (and deleting the original lumps) since all graphics and sprites are included in the sprite fix WAD (which is a lot of unnecessary redundancy, but it helps make updating and maintaining future fixes much easier, and it happens to have this convenient benefit of making a complete and official integration into the base PWAD incredibly trivial).

 

I still have further testing and forthcoming updates to make to the sprite fixes which will also naturally accommodate any relevant graphics changes the upcoming release candidates of Eviternity II will bring, so it would indeed be prudent to wait a little while before performing a full integration.

 

And speaking of which, I can confirm that the current version of the Eviternity II sprite fixes is still compatible with the just-now-released "RC2" build of the PWAD, so no redownloading is necessary as its still perfectly applicable.

 

4 hours ago, pudz said:

I'm just wondering, when using WadSmoosh, which of the fixes should I load? Just Doom 1's/Doom 2's (and optionally Sigil's if that's also added) or both? Thanks again. 

For the main Minor Sprite Fixing Project, you only need to run D2SPFX20.WAD which has full compatiblity as-is with WadSmoosh's Doom: Complete package.

 

When it comes to the Sigil sprite fixes, however, these are not compatible in their current form with the WadSmoosh editions of Sigil 1 and 2. Of course, Sigil 2 isn't supported yet by WadSmoosh, but the program renames the graphic lumps used by the two so they don't conflict with the default Doom 1 graphics. This means my Sigil sprite fix WADs will override the wrong graphics when loaded with Doom: Complete. I'm happy to create a WadSmoosh-compatible version of my Sigil sprite fixes, but I'll need to wait for Sigil 2 support to be added first so I know what to name my lumps.

[Revenant100]

I've completed the extent of the sprite fixes I was aiming for in Eviternity II and am releasing this new version right now. This is a minor update, but it does fulfill my goal of bringing the rest of the new monsters in line with the original monsters in terms of sprite offsets which offers a nice visual improvement in motion. I've also gone through an adequate amount of testing by now, and no abnormalities have cropped up. Thus, this compatibility patch is essentially in its final state barring any reports/suggestions and any forthcoming release candidates from Eviternity II itself which may warrant future sprite fix updates. All download links for this compatibility patch in this thread have been updated which I'm also copying here for convenience.

 

As of this writing, this release of the sprite fixes is compatible with the "RC5" build of Eviternity II.

 

Eviternity II compatibility patch (load the sprite fixes after "Eviternity II RC5.wad"):

• (Outdated, see original post)

 

Here's the changelog for everything I ultimately did in this compatibility patch:

Spoiler

• Full conversion of all Doom 2 sprite fixes to take effect on the unmodified monsters, weapons, items, and so forth
• Adjusted sprite offsets on Eviternity II's new Former Corporal, Astral Arachnotron, Nightmare Demon, Annihilator, Astral Cacodemon, Veilimp, Golden Astral Caco, Duke of Hell, Nightmare Astral Cacodemon, and Astral Mancubus monsters to be consistent with their base Doom monster sprite offsets
• Filled in erroneous transparent pixels in a few Annihilator frames
• Fixed incorrectly converted blue and green colors in the Cacodemon's new (unused?) HEADM0 death frame

And just for fun, here's one animated demonstration of the effects of the sprite offset adjustments using the Duke of Hell's attack frames as an example:

Edited September 8 by Revenant100

[The Almighty Egg]

Those mod makers really need to pay attention to their sprites. Look at those offsets! How did they not notice it!

[somerandommarineguy]

15 hours ago, Revenant100 said:

I've completed the extent of the sprite fixes I was aiming for in Eviternity II and am releasing this new version right now. This is a minor update, but it does fulfill my goal of bringing the rest of the new monsters in line with the original monsters in terms of sprite offsets which offers a nice visual improvement in motion. I've also gone through an adequate amount of testing by now, and no abnormalities have cropped up. Thus, this compatibility patch is essentially in its final state barring any reports/suggestions and any forthcoming release candidates from Eviternity II itself which may warrant future sprite fix updates. All download links for this compatibility patch in this thread have been updated which I'm also copying here for convenience.

 

As of this writing, this release of the sprite fixes is compatible with the "RC2" build of Eviternity II.

 

Eviternity II compatibility patch (load the sprite fixes after "Eviternity II RC2.wad"):

• D2SPFX-Eviternity2-RC2.zip (18.1 MB)

Here's the changelog for everything I ultimately did in this compatibility patch:

  Reveal hidden contents

• Full conversion of all Doom 2 sprite fixes to take effect on the unmodified monsters, weapons, items, and so forth
• Adjusted sprite offsets on Eviternity II's new Former Corporal, Astral Arachnotron, Nightmare Demon, Annihilator, Astral Cacodemon, Veilimp, Golden Astral Caco, Duke of Hell, Nightmare Astral Cacodemon, and Astral Mancubus monsters to be consistent with their base Doom monster sprite offsets
• Filled in erroneous transparent pixels in a few Annihilator frames
• Fixed incorrectly converted blue and green colors in the Cacodemon's new (unused?) HEADM0 death frame

And just for fun, here's one animated demonstration of the effects of the sprite offset adjustments using the Duke of Hell's attack frames as an example:

Remember doing something like this for the original Eviternity as well. Though, it was mainly changing the nightmare demons blood color to red like on the tittle screen and the original hellforged sprite. Here's a screenshot below.

https://www.dropbox.com/scl/fi/z41rfqqai6bfdusvc3y0s/Eviternityspritefixes.wad?rlkey=mx40d4lgv9sptzfv1u9sri5sr&dl=0

[Scuba Steve]

On 12/13/2023 at 8:42 PM, Revenant100 said:

I've completed the extent of the sprite fixes I was aiming for in Eviternity II and am releasing this new version right now. This is a minor update, but it does fulfill my goal of bringing the rest of the new monsters in line with the original monsters in terms of sprite offsets which offers a nice visual improvement in motion. I've also gone through an adequate amount of testing by now, and no abnormalities have cropped up. Thus, this compatibility patch is essentially in its final state barring any reports/suggestions and any forthcoming release candidates from Eviternity II itself which may warrant future sprite fix updates. All download links for this compatibility patch in this thread have been updated which I'm also copying here for convenience.

 

As of this writing, this release of the sprite fixes is compatible with the "RC2" build of Eviternity II.

 

Eviternity II compatibility patch (load the sprite fixes after "Eviternity II RC2.wad"):

• D2SPFX-Eviternity2-RC2.zip (18.1 MB)

Here's the changelog for everything I ultimately did in this compatibility patch:

  Hide contents

• Full conversion of all Doom 2 sprite fixes to take effect on the unmodified monsters, weapons, items, and so forth
• Adjusted sprite offsets on Eviternity II's new Former Corporal, Astral Arachnotron, Nightmare Demon, Annihilator, Astral Cacodemon, Veilimp, Golden Astral Caco, Duke of Hell, Nightmare Astral Cacodemon, and Astral Mancubus monsters to be consistent with their base Doom monster sprite offsets
• Filled in erroneous transparent pixels in a few Annihilator frames
• Fixed incorrectly converted blue and green colors in the Cacodemon's new (unused?) HEADM0 death frame

And just for fun, here's one animated demonstration of the effects of the sprite offset adjustments using the Duke of Hell's attack frames as an example:

@Dragonfly Maybe these changes should just be added to the base mod itself?

[Dragonfly]

29 minutes ago, Scuba Steve said:

@Dragonfly Maybe these changes should just be added to the base mod itself?

 

I agreed earlier on in the thread, just need to get around to testing and adding it. 👍

[Scuba Steve]

Also, WTF, there are Eviternity Barons now!?!

[Dragonfly]

I've taken the time to look at the WAD and notice that loads of assets irrelevant to improving offsets are included from Eviternity II - before I feel comfortable merging this into the main release of Eviternity, could I please be a colossal pain in the ass and ask that you reduce the wad down to only the amended assets?

 

This will make it easier to split apart and integrate into our build process (We're using DoomTools), and, much more importantly, ensure we're not overwriting various assets that have been changed since RC1. A simple example is the titlepic which features a tiny little "RC1" in the corner (I believed it slipped through with the RC1 tag even in RC2, as that was an emergency patch to handle some serious softlocks).

 

It's also worth noting we've re-included some sprites from the original IWADs to adjust them to show correctly with our new palette. (WADs like Ancient Aliens have had to do the same, just an unfortunate by-product of indexed colour I suppose!)

 

Hope this isn't too much to ask! 🙏