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

Doom 2 Minor Sprite Fixing Project - v2.0 Beta 1 Release (updated 1/18/22)

Recommended Posts

1 hour ago, DarkShotX45 said:

Is it just me, or are the weapons not fully centered?

Which weapons do not appear to be centered to you?

For reference, this illustrates the current centered offsets of the weapons:

emZB0rJ.png

 

Centering was based on the weapon sight or the closest analog, i.e. the Chaingun's center barrel. For weapons that have perfectly mirrored sides aka even pixel widths (Pistol, Shotgun, Super Shotgun, Chaingun), the offsets place the weapon center straight down the middle. Can't get any better than that. For weapons that have uneven widths (Rocket Launcher, Plasma Rifle, BFG), their weapon center was chosen with a bias of one pixel to the left since that errs towards how id's artists originally centered the sprites, and they literally cannot be centered any better than that. The remaining Fist and Chainsaw are asymmetrical and had no adjustments made to their offsets in terms of centering.

And here's an example comparison to give an idea of how the offset adjustments actually affected the visual weapon center:

vvbeRCj.png

Edited by Revenant100

Share this post


Link to post

So some weapons are off by 1 pixel?

I really need to stop nitpicking because of an extremely minor thing...

Thanks for the answer

Share this post


Link to post
1 hour ago, DarkShotX45 said:

So some weapons are off by 1 pixel?

by 0.5 of pixel. that's why it is impossible to center them perfectly.

Share this post


Link to post

I am not sure if this is fixable however the mancubus pain sprites are well not mirrored per say but the cannons dont really match the positions of the front facing sprite.

Share this post


Link to post

Also whenever i try to play it with Chocolate doom I get the error "R_InitSprites: No patches found for TROO frame I"

Share this post


Link to post
6 hours ago, Spooky Skeleton boi said:

I am not sure if this is fixable however the mancubus pain sprites are well not mirrored per say but the cannons dont really match the positions of the front facing sprite.

The Mancubus' pain frame is missing the proper rotations for the 6, 7, and 8 angles as they're simply mirrored in the original Doom 2 IWAD. This can only be fixed if these missing non-mirrored Mancubus pain sprites had been originally created by id back in 1994 and are publicly shared with us today, like the non-mirrored Doomguy/zombie sprites were given to us by Romero some time ago. However, Romero is likely the only person in the world to still have these Doom assets, and he hasn't released any remaining materials from his archive in about half a decade now. We do know that the monster sprites are among his last major Doom asset collections he has yet to show us.

 

45 minutes ago, Spooky Skeleton boi said:

Also whenever i try to play it with Chocolate doom I get the error "R_InitSprites: No patches found for TROO frame I"

You are loading the sprite fix WAD with the "-file" parameter. In Chocolate Doom, you must load the sprite fix WADs with the "-merge" parameter. Example for Ultimate Doom:

chocolate-doom -iwad doom.wad -merge D1SPFX19.WAD


Or for Doom 2:
chocolate-doom -iwad doom2.wad -merge D2SPFX19.WAD

Share this post


Link to post
9 minutes ago, Revenant100 said:

We do know that the monster sprites are among his last major Doom asset collections he has yet to show us.

 

Does he, though?

 

What other pieces would be missing from the puzzle?

Share this post


Link to post
1 hour ago, seed said:

Does he, though?

Romero released the full rotations of the Zombieman, Shotgun Guy, Doomguy, and even the Commando (which we already had) based on a request on Twitter:

 

This was not among the assets he was sharing elsewhere earlier, and had he not fulfilled that Twitter request, we likely still wouldn't have these long lost rotation sprites today. But I digress, this clearly indicates he still has the full Doom and Doom 2 monster sprite sheets in his possession that he has yet to unveil. Whether they contain additional long lost sprites is a matter we can only speculate on at this time, but this was all five years ago when he was sharing such artifacts in celebration of the 20th anniversaries of the Dooms. The recent 25th anniversaries didn't yield anything new from his (hopefully well secured and backed up) historical archives. I guess we'll just have to wait and see what happens come the 30th anniversaries.

 

Hopefully no later than the 50th.

Edited by Revenant100

Share this post


Link to post

Here's something I don't think was brought up before:
yTnsmnl.png
The STFST1 status bar faces are supposed to give Doomguy a bloody nose and ruffled hair, however I just noticed that the STFTL10, STFTR10, & STFKILL1 faces (bottom 3) don't have a bloody nose and I guess id forgot to add it to them. I think it'd be good if you added some red pixels to these faces so that the nosebleed is consistent in this set.

Edited by Triple_sSs

Share this post


Link to post
On 6/2/2020 at 12:53 PM, Triple_sSs said:

Here's something I don't think was brought up before:
yTnsmnl.png

Good catch. That's a rather obvious inconsistency. Nonetheless, I'll mention that I've gone through the status bar face graphics before and compared them to their press release beta versions, and it's evident that one of id's artists actually did go through and make a handful of minor touch-ups to the face shortly before release. These changes are much more minuscule and unnoticeable than the disappearing bloody nose there. Not to say that this could have been an error that went overlooked all the way to release, but they clearly did take the time to go over these face graphics again.

 

I'll probably add the missing bloody nose by borrowing some red pixels from the following damaged state for the sake of addressing such a conspicuous visual inconsistency, but I can't rightly say this is an unintended omission on id's part since they certainly had and waived the opportunity to fix it themselves.

Share this post


Link to post
1 hour ago, Revenant100 said:

I'll probably add the missing bloody nose by borrowing some red pixels from the following damaged state for the sake of addressing such a conspicuous visual inconsistency, but I can't rightly say this is an unintended omission on id's part since they certainly had and waived the opportunity to fix it themselves.

Something I've considered since I made my post is that it may have been for a certain effect?
Just a theory but it could be that when the player first goes from 200%-80% health to 79%-60%, showing the first pain state without the nosebleed and then the normal status with it, it might have been made to look like a "slow bleed" from the nose during that state switch. That might be an interesting effect to add a touch more realism I suppose, however this of course is a problem with consistency as the player is still likely to get hurt or fire continuously while in 79%-60% health and the nosebleed will keep flickering in and out during that health state.

So perhaps it may have been done for an interesting, if subtle, effect here, but yeah, IMHO I still think it'd be a fair trade-off whatever the case, and having the nosebleed be there continually would both look better and be more in line with the mechanics of the rest of the face graphics.

Edited by Triple_sSs

Share this post


Link to post

@Revenant100What do you think about how BFG's muzzle flash looks? In original Doom it looks like BFG fires from above the muzzle. The edited flash frame on the right feels right to me.

Screenshot_Doom_20200605_163946.png

Share this post


Link to post

There's no indication the appearance of the BFG's muzzle flash is anything other than intentional, and it's indeed another sprite that received minor touch-ups after the press release beta which similarly received no major alterations at that point when id was definitely reviewing their artwork shortly before release.

 

The BFG's barrel appears intended to be identical in form to the Plasma Rifle's (certainly a great departure from the barrel's known original design), and the Plasma Rifle's barrel is shown to have openings that allow some of the weapon's muzzle flash to visibly vent through. The Rocket Launcher's barrel has similar venting holes where we can see the muzzle flash completely overlap the end of the gun through these holes while firing. The idea behind the BFG's firing visuals seems to be that the weapon's projectile is so powerful that the enormous muzzle flash completely engulfs the barrel through its ventilation openings.

 

cYIKkLI.png

Share this post


Link to post

You've got a convincing argument! Sorry for overthinking.

Share this post


Link to post

Oh yeah, there's another thing I wanted to request: Would you be able to add compatibility with GZDoom's internationalization feature?

It's something that was added to GZDoom last year so Doom can have extensive support for other languages besides English. Problem is, the text fixes in this mod seem to conflict with the translations; it's most noticeable on the difficulty screen where the "Hey not too rough" fix is visible when it shouldn't be English text, as shown here for example: 

 

dNYIOZr.png

 

Maybe you could add flags or something so that the text fixes aren't used by GZDoom when it's not set to English?

Edited by Triple_sSs

Share this post


Link to post

I think this may require GZDoom to get these "flags or something" first.

Share this post


Link to post

Glancing over the documentation, I don't see any obvious way that would allow GZDoom to force its localized strings to take priority over something in a loaded PWAD. That seems counterintuitive to how the engine should behave in this scenario. It just so happens that the sprite fixes work in a fairly atypical fashion compared to most PWADs, so we're experiencing a nearly nonexistent edge case to account for.

 

If you're playing in a different language setting, which in and of itself is essentially a mod, you may as well go a step further and mod the sprite fix WADs themselves to accommodate your own specific needs. In this case, open the sprite fix WADs in SLADE or some such editor and manually delete the offending graphic lump, M_ROUGH. This is likely the most feasible solution to deal with this issue since I can't see any reasonable fix from my end, and I don't imagine there's something GZDoom could implement engine-side to handle this very particular circumstance in a graceful manner.

Share this post


Link to post

Yeah, I think it would need a new feature to be able to A) flag lumps as being only for the English language version of the game while B) being in a vanilla-compatible archive (that is to say, a plain old wad file that works as intended in non-ZDoom ports).

 

Without a feature to do that, the burden is either on the maintainer to keep several different versions of the packs, or on the users to edit the pack as needed. I'm not sure where such a thing would go. MAPINFO is stretching it a bit. LANGUAGE makes thematic sense but not technical sense.

 

Or perhaps a different approach. Essentially we want the content of the spritefix archive to be treated as if it were the IWAD, so that when IWAD content is overridden for a reason or another (like internationalization) then spritefix's content would likewise be overridden. This could fit GAMEINFO I suppose.

Share this post


Link to post
8 minutes ago, maxmanium said:

what language is that?

It's a language that's very close to Romance ("mi estas tro juna por morti" looks vaguely Spanish-like, without being Spanish), but with a heavy use of the letter K (and removal of the X), so among the languages listed on the ZDoom Wiki pages, I'm going to say only Esperanto looks like it'd fit.

Share this post


Link to post
7 hours ago, maxmanium said:

@Triple_sSs, what language is that? If you can tell me what the proper translation is, I try to make a replacement sprite lump for you.

Yes it's Esperanto, like Gez correctly guessed. I actually helped out with the translation for that language too. A replacement sprite lump would certainly be appreciated.

11 hours ago, Gez said:

Or perhaps a different approach. Essentially we want the content of the spritefix archive to be treated as if it were the IWAD, so that when IWAD content is overridden for a reason or another (like internationalization) then spritefix's content would likewise be overridden. This could fit GAMEINFO I suppose.

Hmm yeah, maybe this is worth a shot? Sounds like a GAMEINFO lump could work.

Edited by Triple_sSs

Share this post


Link to post

Also IIRC, the DOOM II X-Treme & Extreme Gold PWADs created by Chuck Lai contained minor modifications to the existing DOOM II sprites.

 

Neither PWAD are available on the idgames archive due to it's usage of some maps from TNT Evilution (and the second secret level consisting of E1M8, E2M8, E3M8, & E4M8 as a single level) in the former, & The Plutonia Experiment (and a few levels from TNT Evilution & Memento Mori II) in the latter, but are available on Doom Wad Station. http://www.doomwadstation.net/main/extreme.html

Share this post


Link to post
On 9/17/2016 at 8:43 AM, Revenant100 said:
  • 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.

Is the SSG fire sprite still fixed in the most recent version (19)?
I downloaded it, but I can still see this:

ssg.png.bd80d96a49dfa2e6cde2728d707ff374.png

I'm loading both the Doom2 WAD and DEH files in GlBoom+ (2.5.1.4). These are my command line arguments:

glboom-plus.exe -iwad DOOM2.WAD -file sprfix19\D2SPFX19.WAD sprfix19\D2DEHFIX.DEH -complevel 2

I also tried loading the DEH first, and then the WAD, but the problem persisted.

The lost souls front-facing sprite animation is fixed, so I know the WAD did load successfully.

 

What am I doing wrong?

Share this post


Link to post
1 hour ago, maxmanium said:

@Coincident, you need to use the -deh parameter. Looks like you just tried loading it with -file.

Thank you! It's working now. Forgive my clumsiness, not sure how I didn't see that earlier.

By the way, the attention to detail that was put into this project is amazing. These kinds of minor fixes were exactly what I was looking for. Loving it!

Share this post


Link to post

Hi @Revenant100, as a GZDoom user, I've repackaged this mod to make use of its "filter folder" feature, and also converted all the Dehacked work to ZScript so that I can have this mod as a single file dropped into my autoload - makes things cleaner and easier to organize for me while also being compatible with other Dehacked mods I might want to load in for a particular playthrough.

 

I haven't posted this anywhere, it's just a personal tweak I play with.

 

Although you've already stated in the readme that your mod can be used as a base for further modifications, I'd just like to check with you if it's okay for me to post my edit of your mod (most likely in a separate thread to keep clutter out from this one).

 

If it's not OK, then that's fine too. :)

Cheers and keep up the amazing work!

Share this post


Link to post

Absolutely, you're more than welcome to modify and repackage the sprite fixes for whatever you'd like to do with them. They're always meant to be an accessible resource that the community is wholly entitled to make use of.

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
×