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

[kb1]

22 hours ago, Blastfrog said:

Good rule of thumb, but still very subjective. How about monster eyes, for instance? I've always assumed them to be glowing; Doom 3 does ^{(which yeah it's not classic Doom but id still consisted of many of the same key folks at that time, in a sense it's more Doom than 2016, just (de)emphasized the opposite aspects (horror/action))}.

 

Pinky had bright yellow eyes, possessed and imps had bright red. It also fits with the high contrast, scary stuff coming at you from the dark thing they were going for. Doom's aesthetic was heavily based on seeing highlights in the increasingly-dark distance, I'd think the eyes were supposed to glow in the dark if they bothered to go to that level of effort back then.

 

Granted, if they are given brightmap highlights, they should probably be more subtle than not in order to avoid changing the original experience too heavily. Just a hint of emphasis on the apparent intent, not an overhaul.

The glowing eyes are definitely cool, but I don't believe id ever wanted the Doom/Doom II monsters' eyes to glow. Why do I say this? Because it's rather trivially possible to do in vanilla, with no performance loss. If they had wanted it, they probably would have done it.

[fraggle]

They probably just didn't think of it?

[Lila Feuer]

I always liked how the Pig Cop's eyes glowed in the dark in Duke 3D and having eye brightmaps in Doom satisfies this.

[NightFright]

It's going to remain a controverse discussion. To glow or not to glow, that's the question! 

 

Anyway, my edition will always have them. Maybe it's not "vanilla", but it looks cool, at least if you ask me. If you don't like it, feel free to change it for yourself, that's quite alright. Everybody is going to be happy!

[kb1]

6 hours ago, NightFright said:

It's going to remain a controverse discussion. To glow or not to glow, that's the question! 

 

Anyway, my edition will always have them. Maybe it's not "vanilla", but it looks cool, at least if you ask me. If you don't like it, feel free to change it for yourself, that's quite alright. Everybody is going to be happy!

I do like the effect, especially when the badguys are up ahead, in a dark hallway, and all you can see are the eyes! Seems like just about any change becomes controversial, doesn't it?

[NightFright]

I am releasing a new version of the spritefix brightmaps today. Main focus was on optimization, nothing ground-breaking new. The pack is a lot smaller now and some of the powerups look nicer (e.g. only the eyes of the Mega-/Soul-/Invulnerability Spheres are highlighted instead of the whole item). A few brightmaps I removed because they were kinda unnecessary and made the sprites look too bright.

Brightmaps Plus v1.51 (2.1 MB)

 

CHANGELOG v1.51:

[GENERAL] PNG compression applied to all brightmaps (file size reduced by 50%)
[DOOM] Improved: Armor Bonus (BON2B/C), Evil Eye (CEYE), Powerup spheres (MEGA/PINS/PINV/SOUL), Computer Area Map (PMAPA/B), Light Amp Visor (PVISB)
[DOOM] Removed: Armors (ARM1/ARM2), Health Bonus (BON1), Keycards (BKEY/RKEY/YKEY), Skull Keys (BSKU/RSKU/YSKU)

 

[Ah, yeah, before I forget: The file is now called "brightmaps_plus.pk3" instead of "gzd_brightmapsXXX.pk3" which I think is a bit more convenient.]

 

Prepare for another bigger update of the pack next Monday (April 8).

 

Edited April 8, 2019 by NightFright

[NightFright]

Hopefully this will be the last update (unless new spritefixes require more adjustments). I have finally removed colors from Doom and Heretic brightmaps which caused overbright colors until now. This makes sprites look more authentic and brightmaps effects also more subtle in many cases. I also compared all existing brightmaps with those from GZDoom's brightmaps.pk3, always choosing the best version. This should be the best-looking brightmaps pack yet!

 

Brightmaps Plus v1.6 (2.1 MB)

 

CHANGELOG v1.6:

[DOOM/HERETIC] All colored brightmaps converted to greyscale graphics to preserve original sprite colors
[DOOM] Imported better brightmaps from brightmaps.pk3 for:
- Archvile (all 80 available frames)
- Burning barrel (FCAN)
- Chaingunner firing (CPOS E/F)
- Cyberdemon firing/exploding (CYBR F/J-O)
- Player firing (PLAY F)
- Sergeant firing (SPOS E/F)
- Spider Mastermind exploding (SPID M-R)
- Zombie firing (POSS E/F)
[DOOM] Improved brightmaps for Cacodemon (HEAD)
[DOOM] New brightmaps for Health Bonus (BON1)

 

*EDIT July 22, 2020*
Please find future Brightmaps Plus updates on Github.

Edited July 22, 2020 by NightFright

[Xfing]

BTW, not really in the loop and haven't been following the thread so forgive me pls, 

but has this reincorporated the missing rotational sprites for imps/zombies that Romero released on Twitter some time ago? 

[Bauul]

1 hour ago, Xfing said:

but has this reincorporated the missing rotational sprites for imps/zombies that Romero released on Twitter some time ago? 

 

Yep, it has indeed! 

[Xfing]

1 minute ago, Bauul said:

 

Yep, it has indeed! 

Sweet :D

[LemonWolf3322]

I don't know if you ever plan on updating this project again, but I've spotted a lot of issues and inconsistencies that would do well to be included in a Sprite Fixing Project 2.0 or a Minor DeHackEd Fixes 1.1. Apologies in advanced for the large post.

 

As for sprite changes, the 3 garbage pixels in the SKELI7 frame are actually intended to be part of the SKELI6 frame, as seen in the spritesheets that Romero released. decino mentions this in his "Interesting Findings About Doom's Monster Sprites" YouTube video, which is where I found out about it.

 

There are also a lot of inconsistencies and errors in various menu and font graphics.

• STCFN036 is missing a row of pixels at the top, resulting in an unfinished outline.
• STCFN064 is missing a row of pixels at the bottom, resulting in an unfinished outline.
• M_SAVEG reads "Save game" instead of "Save Game". (Game should be capitalized, as seen in M_QUITG, M_NGAME, and M_ENDGAM)
• M_LOADG reads "Load game" instead of "Load Game". (Game should be capitalized, as seen in M_QUITG, M_NGAME, and M_ENDGAM)
• M_DETAIL is missing a column of pixels on the left, resulting in an unfinished outline around the G.
• M_MSENS reads "Mouse sensitivity" instead of "Mouse Sensitivity". (This one might be intentional, but M_DETAIL, M_SCRNSZ, and M_SVOL all have their second word capitalized)
• M_SFXVOL reads "Sfx Volume" instead of "SFX Volume". (This one also might be intentional.)
• M_SFXVOL and M_MUSVOL are both missing a column of pixels on the right, resulting in an unfinished outline around the E.

 

On the topic of DeHackEd fixes, I found a few more inconsistencies in states and frames that should probably be corrected. It would also be a good idea to include the entirety of uhbooh's SNDFIX.DEH patch, as it fixes all of the inconsistencies with the game's audio.

• On both the green and blue armor, the fullbright frame is swapped; the A frame should be fullbright, as the sprites show, but the B frame is the one marked with the fullbright tag.
• The green armor's B frame lasts for 7 tics instead of 6. The blue armor's B frame lasts for 6 tics, and the A frame for both lasts 6 tics.
• The death state for Romero's head uses the A frame rather than the B frame. Since this head is never seen in normal gameplay, this is only a minor nitpick and may not even count as an inconsistency at all.

This one might or might not be considered a bug, but was worth mentioning nonetheless. The small pickup for shotgun shells uses the string "Picked up 4 shotgun shells." even if the user is playing on ITYTD/NM where it gives 8. The GBA version of Doom fixed this by changing the string to "Picked up the shotgun shells." It should be possible to change this using DeHackEd, but I can't remember if there was enough character space to allow it or not.

 

I could try to throw together some fixed files myself and upload them here for use, but I'm not at my main working computer so it might take a few days.

[Revenant100]

Thanks for the suggestions! A 2.0 update will happen at some point as there are already a handful of fixes in the queue. The main delay is getting around to addressing the aforementioned invisible palette issue, so there's still plenty of time until the update.

 

52 minutes ago, LemonWolf3322 said:

As for sprite changes, the 3 garbage pixels in the SKELI7 frame are actually intended to be part of the SKELI6 frame, as seen in the spritesheets that Romero released. decino mentions this in his "Interesting Findings About Doom's Monster Sprites" YouTube video, which is where I found out about it.

This was one of the first fixes I considered at the beginning of the project, and for reasons I can't remember now, I decided not go with it. I believe it may have been related to compatibility concerns with changing the actual sprite dimensions, but in the half decade since then, similar adjustments haven't proven any issues, so I'll revisit this again for 2.0.

 

52 minutes ago, LemonWolf3322 said:

There are also a lot of inconsistencies and errors in various menu and font graphics. 

I've avoided delving into these menu graphics since they're technically not part of the gameplay sprite sets which have been the central focus of the project from the beginning. I've made a few exceptions over the years, but there are several other known menu graphics errors which I've intentionally omitted due to the conflicts between the IWADs. For instance, Doom 2's CWILV00 lump for Entryway is missing its top row of pixels, but I'm not going to touch that since that will also end up overriding TNT's and Plutonia's CWILV00 lumps unless I were to start breaking up the fix into even more WADs, which I'm not going to do.

 

That said, I'll examine all of your suggestions, the ones regarding the incomplete outlines being the most viable candidates.

 

52 minutes ago, LemonWolf3322 said:

• STCFN036 is missing a row of pixels at the top, resulting in an unfinished outline.
• STCFN064 is missing a row of pixels at the bottom, resulting in an unfinished outline

Addressing these would result in font characters that are 9 pixels tall, larger than anything else in the character set. I'm not inclined to touch these as that has the potential of messing with the text alignment in unpredictable ways, especially across different source ports.

 

52 minutes ago, LemonWolf3322 said:

• M_SAVEG reads "Save game" instead of "Save Game". (Game should be capitalized, as seen in M_QUITG, M_NGAME, and M_ENDGAM)
• M_LOADG reads "Load game" instead of "Load Game". (Game should be capitalized, as seen in M_QUITG, M_NGAME, and M_ENDGAM)
• M_MSENS reads "Mouse sensitivity" instead of "Mouse Sensitivity".(This one might be intentional, but M_DETAIL, M_SCRNSZ, and M_SVOL all have their second word capitalized)
• M_SFXVOL reads "Sfx Volume" instead of "SFX Volume". (This one also might be intentional.)

These don't look to be errors. Inconsistencies, yes, but that's just how id chose to write the text, tantamount to an artistic choice.

 

52 minutes ago, LemonWolf3322 said:

On both the green and blue armor, the fullbright frame is swapped; the A frame should be fullbright, as the sprites show, but the B frame is the one marked with the fullbright tag.

While changing bright frames has been demonstrated to be demo-sync safe, I won't be changing this as it has the potential of conflicting with PWADs that have modified the armor graphics and maybe their DeHackEd definitions as well for their own purposes (i.e. making the armor not blink).

 

52 minutes ago, LemonWolf3322 said:

The green armor's B frame lasts for 7 tics instead of 6. The blue armor's B frame lasts for 6 tics, and the A frame for both lasts 6 tics.

Changing frame tics is very demo-sync unsafe. The DeHackEd fixes are secondary in the big picture, and they, at minimum, cannot compromise demo compatibility. I know of other minor frame timing inconsistencies that I have deliberately omitted as well for the same reason.

 

52 minutes ago, LemonWolf3322 said:

The death state for Romero's head uses the A frame rather than the B frame. Since this head is never seen in normal gameplay, this is only a minor nitpick and may not even count as an inconsistency at all.

While a cosmetic change like this is possibly demo-sync safe, it'll almost certainly cause conflicts with PWADs, either existing or future, that utilize the Romero head graphics and states for their own purpose.

 

52 minutes ago, LemonWolf3322 said:

This one might or might not be considered a bug, but was worth mentioning nonetheless. The small pickup for shotgun shells uses the string "Picked up 4 shotgun shells." even if the user is playing on ITYTD/NM where it gives 8. The GBA version of Doom fixed this by changing the string to "Picked up the shotgun shells." It should be possible to change this using DeHackEd, but I can't remember if there was enough character space to allow it or not.

You're correct; this not possible to fix in a vanilla-compatible DeHackEd patch. This particular string cannot accept any more characters.

 

[LemonWolf3322]

Alright, great. Thanks for getting back to me so quickly.

 

If nothing else, I'll probably be "fixing" these myself and packaging them together for my own personal use. Just thought I'd share them in case you might be able to harvest a few for usage in the main project.

[Diabolución]

From Doom Classic for iOS. John Carmack changed certain text strings of that source port based on PrBoom.

 

#define GOTSHELLS   "Picked up shotgun shells."        // JDC: removed number 4 so baby mode isn't incorrect

 

/* p_doors.c */        // JDC: added punctuation to these
#define PD_BLUEO    "You need a blue key to activate this object."
#define PD_REDO     "You need a red key to activate this object."
#define PD_YELLOWO  "You need a yellow key to activate this object."
#define PD_BLUEK    "You need a blue key to open this door."
#define PD_REDK     "You need a red key to open this door."
#define PD_YELLOWK  "You need a yellow key to open this door."
/* jff 02/05/98 Create messages specific to card and skull keys */
#define PD_BLUEC    "You need a blue card to open this door."
#define PD_REDC     "You need a red card to open this door."
#define PD_YELLOWC  "You need a yellow card to open this door."
#define PD_BLUES    "You need a blue skull to open this door."
#define PD_REDS     "You need a red skull to open this door."
#define PD_YELLOWS  "You need a yellow skull to open this door."
#define PD_ANY      "Any key will open this door."
#define PD_ALL3     "You need all three keys to open this door."
#define PD_ALL6     "You need all six keys to open this door."

/* g_game.c */
#define GGSAVED     "Game saved."    // JDC: capitalized per testing report

 

 

[Revenant100]

That shotgun shell text alteration looks good (it's nice that it's technically "canon"), and it's viable in a vanilla-compatible DeHackEd patch. I'll do more checking to be certain this wouldn't result in any conflicts, but this seems like it should be a safe inclusion. It does introduce an inconsistency, however, since the ammo pickup messages, while not all specifying the exact ammo count received, do specify the exact amount of the item being picked up with at least an indefinite article, i.e. a clip, a box, a rocket, an energy cell, a backpack. In light of the lower priority of the DeHackEd fixes, it's usually better to leave well enough alone.

 

I can't add punctuation to all of the key door/object messages in a vanilla-compatible DeHackEd patch as not all of these strings have any additional characters available, and I can't touch the Boom messages unless I change the DeHackEd patch format which would mean losing vanilla compatibility. The missing periods will have to remain so.

 

The capitalization in the "game saved" message (and all in-game text, for that matter) is a non-issue in the PC version since the font characters are all-caps.

Edited May 29, 2019 by Revenant100

[Daamer]

I found something worth fixing: E1M8's map name (the file WILV07.lmp) has the first column of pixels colored red instead of grey, as you can see:

Edited August 31, 2019 by Daamer

[Revenant100]

Nice catch. I also see the same coloring error in WILV11, WILV17, and WILV24. I'd normally have to exclude these intermission map name fixes, but unlike Doom 2, Doom 1 doesn't have an equivalent TNT or Plutonia IWAD which would cause map name sprite conflicts. These look like they'd be safe additions to the Doom 1 fixes PWAD.

[Trov]

Any plans for this project to also cover map fixes?

 

For example, one of the Doom 2 patches notoriously offset all the Things on many maps, resulting in the sergeants and barrels stuck in walls in Map02 for example

[Revenant100]

I'm afraid that's not a possibility as modified IWAD maps cannot be distributed. The right way to go about that would be some sort of delta patch that also generates a PWAD so as not to modify the original IWAD, but that's an immense amount of effort for ultimately minuscule gain. Some of Doom's quirks are better lived with as the solutions can be more troublesome than the defects.

[NightFright]

Also note this is called SPRITE Fixing Project. Map fixes = different thing.

[Gez]

GZDoom actually features a way to fix map errors with a text file. But the idea is to only use it to address issues that can break a map, not for harmless glitches. A sergeant stuck in a wall does not prevent the player from completing the map with max stats, so it's not a map-breaking issue.

[The Almighty Egg]

Sorry for posting on an old thread, but where exactly are the uncropped weapons?

First Person Weapon Sprites - Restored uncropped Fists, Pistol, and Shotgun sprites taken from the press release beta. The cropped portions still aren't visible, but why not include them anyway?

I think that was one of the first changes done to the mod. However, when I play it the sprites are still the same as the original.

   

 

 

 

 

 

 

 

 

[UndeadRyker]

16 minutes ago, Spooky Skeleton boi said:

Sorry for posting on an old thread, but where exactly are the uncropped weapons?

First Person Weapon Sprites - Restored uncropped Fists, Pistol, and Shotgun sprites taken from the press release beta. The cropped portions still aren't visible, but why not include them anyway?

I think that was one of the first changes done to the mod. However, when I play it the sprites are still the same as the original.

They're already included. They just aren't visible because their offsets have been modified to be visually identical.

[The Almighty Egg]

4 minutes ago, UndeadRyker said:

They're already included. They just aren't visible because their offsets have been modified to be visually identical.

Are they perhaps something like this?https://gamebanana.com/skins/132102

 

[UndeadRyker]

Yes. I'm not sure if you understand what I'm saying. As an example, this is the original pistol sprite from Doom:

 

And this is the same sprite but in DSPFX.

 

The sprites are included, just like what you wanted. And of course, they aren't visible like you'd expect because the extended portion of the arm is hidden behind the status bar (see Revenant's accurate explanation below). To me it sounds like you want the entire sprite showing (and the idea just doesn't sound good at all). If you want the entire sprite showing, you can always adjust them up yourself with SLADE or a similar program.

Edited September 23, 2019 by UndeadRyker : spelling

[Revenant100]

40 minutes ago, Spooky Skeleton boi said:

Sorry for posting on an old thread, but where exactly are the uncropped weapons?

 

I think that was one of the first changes done to the mod. However, when I play it the sprites are still the same as the original.

The uncropped weapon sprites are indeed already there. See this comparison:

 

However, the reasoning behind the original cropping is that the deleted portion is never visible on-screen. Even when the weapon is bobbing around, it will never rise above the cropped point. Hence, the restoration of the uncropped artwork is effectively invisible since the extra parts of the sprites will never be seen under normal circumstances. However, they are included nonetheless because they're completely benign to normal functionality and the Chaingun, Rocket Launcher, and BFG sprites were left uncropped anyway, plus there's the off chance that some unorthodox modding or source port may allow viewing of the uncropped areas.

Edited September 23, 2019 by Revenant100

[The Almighty Egg]

Is there perhaps any way I can view the full sprites on SLADE?

[Revenant100]

I'm not quite sure I understand the question. If you want to raise the cropped portions of the sprites into the viewing area, you can edit the WAD in SLADE and raise the pertinent weapon sprites by +32 on the y-axis.

[Gez]

33 minutes ago, Revenant100 said:

Even when the weapon is bobbing around, it will never rise above the cropped point.

If I'm not mistaken, at some point during development, weapons bobbed upward, along a sort of V shape. This was then changed to ∩ shape so that they didn't need to extend the weapon sprites beyond what's visible at rest.

[The Almighty Egg]

On 9/23/2019 at 7:39 PM, Revenant100 said:

The uncropped weapon sprites are indeed already there. See this comparison:

 

However, the reasoning behind the original cropping is that the deleted portion is never visible on-screen. Even when the weapon is bobbing around, it will never rise above the cropped point. Hence, the restoration of the uncropped artwork is effectively invisible since the extra parts of the sprites will never be seen under normal circumstances. However, they are included nonetheless because they're completely benign to normal functionality and the Chaingun, Rocket Launcher, and BFG sprites were left uncropped anyway, plus there's the off chance that some unorthodox modding or source port may allow viewing of the uncropped areas.

 

I can't for some reason find the Pistol firing sprite, was it included in the wad or am I missing something?