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

Doom 2 Minor Sprite Fixing Project - v1.9 Release (updated 1/27/18)

Recommended Posts

Hey, just to report, there's a little confusion/ambiguity about which is the latest version of SPRFIX19. The text  file for the version on /idgames is 11/29/17 even though the last update was 1/27/18 as per this thread title. I had to download it again and compare checksums to be sure I hadn't missed anything.


A feature request, could you consider including the .DEH file content as a DEHACKED lump in the respective PWADs? It would make it easier to mix and match with other PWADs and DEH files in some circumstances, e.g. vsmooth under chocolate doom.

 

Thanks!

Share this post


Link to post

These dehacked files are optional and should remain as such. The differences they make are negligible compared to the rest, anyway.

Share this post


Link to post
2 hours ago, NightFright said:

These dehacked files are optional and should remain as such. The differences they make are negligible compared to the rest, anyway.

 

Hmm ok. I guess if they were embedded, it would be difficult or impossible to disable them in most ports. I see. Thanks

 

I'm likely to merge vsmooth, pkdoomsfx sprfix and possibly some other stuff together for personal convenience anyway, so it's not a big deal.

Share this post


Link to post
On 3/26/2018 at 9:58 AM, Cire said:

Just saw that there is Another widescreen Hexen Project here: https://forum.zdoom.org/viewtopic.php?f=46&t=59917

Maybe could be useful?

Neoworm's work is wonderful, and I had indeed already been using his widescreen status bar graphics for both Heretic and Hexen. These widescreen weapon sprites for Hexen look great, but I see he did also make some significant art alterations to the existing portions of the weapon sprites as well. I can clearly see why he did this, but this does go much further than the purely utilitarian approach that's been taken with this fixes of simply extending the graphics. However, by technical necessity, the widescreen Hexen sprites do have to be split into a separate WAD for compatibility reasons, and I think that gives some leeway as to the artistic liberties required to make these weapons widescreen-friendly since it's all original anyway. Whatever the case, what's here is a fantastic base and reference to work from, and I will certainly make use of it. Thanks for pointing me to its release.

 

11 hours ago, Jon said:

Hey, just to report, there's a little confusion/ambiguity about which is the latest version of SPRFIX19. The text  file for the version on /idgames is 11/29/17 even though the last update was 1/27/18 as per this thread title. I had to download it again and compare checksums to be sure I hadn't missed anything.

The latest version was finalized on 11/29/17 to (almost) meet the exact five year anniversary of the original release, but I hadn't uploaded it to idgames or this thread until January due to time. It's a slight ambiguity, I agree, but no two versions of the WAD have ever shared the same filename. The "updated" in the thread title always refers to full releases, not incremental revisions, and rest assured that the thread links here and on ZDoom are always kept up-to-date.

 

Quote

A feature request, could you consider including the .DEH file content as a DEHACKED lump in the respective PWADs? It would make it easier to mix and match with other PWADs and DEH files in some circumstances, e.g. vsmooth under chocolate doom.

To elaborate on what Nightfright said, the DEH lumps are kept separate from the WADs not only due to intentionally being optional but also to maintain compatibility when loading them with the vanilla executables through DeHackEd itself and, more likely now, Chocolate Doom et al. Both could have been done for convenience, but they should be optional due the possible albeit rare chance of causing unintended gameplay conflicts with other WADs.

Share this post


Link to post

@Revenant100 Happy to help! Really looking forward to see what the Hexen sprite fixing Project has in store. I'm working on a small Project myself while waiting for yours. It mostly consists of me trying to collect fixes for Hexen and making them ChocoHexen compatible right now. Though I have encoutered a couple of problems on the way. One being that there seems to be now way to convert Graphics to the Raw Screen or Planar formats that Hexen uses for some Graphics in the SLADE editor I use (at least not as far as I've found). And it just doesn't seem possible to get ChocoHexen to accept widescreen HUD sprites without crashing for some reason I don't understand. So you're right in that in the widescreen sprites has to be split off into a separate WAD, just like the Heretic counterpart. Still the Doom Engine seems to be unaffected by this issue. Strange.

Share this post


Link to post

Actually, SLADE seems to be able to convert to Planar after changing a setting and raw screen is the same format as Flat apparently. Unfortunatly, there seems to be a max limit on resolution on that graphic formant so you can't do wide screen anyway. I included the converted 'de-widescreened' Graphics anyway, because at least TITLEPIC and INTERPIC has improvements, most noticably towards the right edge. I'm attaching the WAD I did in case anyone besides me finds it useful. Should work in most Hexen supporting ports I Think but not vanilla or ChocoHexen. Has been tested to work with ZDoom 2.8.1 at least. Credits and thanks to @NeoWorm and @DELUXE  who did the graphic fixes and @NeuralStunner who did the map fixes in the WAD.

HEXENFIX.zip

Share this post


Link to post

I have made a small update for the brightmaps pack. It always pissed me off how the teeth of the demon face on dem1_3 and dem1_4 were glowing in the dark. As if demons are using special toothpaste or something. xD Finally, I took the time to fix that.

 

Spritefix-compatible brightmaps for GZDoom v1.42 (PK3, 4.4 MB)

 

Just in case you didn't know: It is possible to completely deactivate brightmaps for textures. To do it, find the gldefs.bm file in subdir filter\<game> and uncomment the line ending with _textures.bm by adding "//" at the beginning.

 

Example for Ultimate Doom:

// Brightmaps for vanilla sprites
// #include brightmaps/doom_sprites.bm

// Brightmaps for Revenant100's spritefixes
#include brightmaps/doom_spritefixes.bm

// Brightmaps for textures
// #include brightmaps/doom_textures.bm

Anyway, these brightmaps are designed in a "smart" way so they automatically deactivate whenever a texture replacement from a pwad is used.

Edited by NightFright

Share this post


Link to post
On 3/29/2018 at 8:56 AM, Jon said:

 

Hmm ok. I guess if they were embedded, it would be difficult or impossible to disable them in most ports. I see. Thanks

 

I'm likely to merge vsmooth, pkdoomsfx sprfix and possibly some other stuff together for personal convenience anyway, so it's not a big deal.

What is vsmooth? Is there I link where I can check it out? (thanks in advance)

Share this post


Link to post
On 4/3/2018 at 7:21 PM, Cire said:

@Revenant100 ... And it just doesn't seem possible to get ChocoHexen to accept widescreen HUD sprites without crashing for some reason I don't understand. So you're right in that in the widescreen sprites has to be split off into a separate WAD, just like the Heretic counterpart. Still the Doom Engine seems to be unaffected by this issue. Strange.

Some of the graphic offsets might be hard-coded in the engine, which is expecting graphics of a certain size. I ran into such problems in my port, until I added code to prevent drawing off the screen.

Share this post


Link to post

Looks like a pretty straightforward error and fix. I do believe this is the first time layer ordering was the problem in a sprite, though. Keen eye pointing that out, @JudgeDeadd, and thanks for the heads up, @Linguica.

 

Edit: And just when I assumed the fix would be a simple copy and paste from one frame to another, it turns out it's not that simple. While that upper trailing flame burst in VILE frames P2, P3, and P8 are identical, they don't match when overlayed onto P1's flame. The upper flame in P7 is also different, being entirely unique on its own. However, P7 does provide a reference point in that its only alteration was a slight shortening by shifting the bottom half of the P2/3/8 flame art upwards a few pixels. I mimicked the same process for P1, this drawn out and pedantic route ending up with what is hopefully a more accurate recreation of the fire portion hidden in this frame.

Edited by Revenant100

Share this post


Link to post

Sorry for being 'thick' here, but what actually was the problem (before your eventual fix)? What I mean is, this was not a problem in vanilla, right? Can you quickly explain the issue a little more? Thanks.

Share this post


Link to post

P7 was shortened a bit because it is slightly further away from that vantage point. If anything, P1 should be grown a little.

Share this post


Link to post
3 hours ago, kb1 said:

Sorry for being 'thick' here, but what actually was the problem (before your eventual fix)? What I mean is, this was not a problem in vanilla, right? Can you quickly explain the issue a little more? Thanks.

Part of the fire in the last front-facing frame (P1) of the Arch-Vile's attack sequence appears to be layered behind his head instead of in front of him. The suggested fix in the other thread is to copy the fire from the Vile's P2/P3/P8 angle frames (which looks the same) and paste it on top of the P1 frame to correct the order layer. However, I've found that overlaying said P2/P3/P8 fire on top of P1 doesn't result in a perfect match. P1's fire appears to be adjusted in shape, like P7's unique fire shape. Thus, I did my own manual edit to bring the P2/P3/P8 fire closer to what seems to be the obstructed P1 fire. It's not a huge difference, but it certainly matches better. Here's a comparison:

 

IeoErL6.png

 

The problem is, just vertically shifting the columns isn't enough to account for all of the differences inherent in the front-facing P1 fire. There are signs of deliberate art touch ups on the sides and especially where the fire meets the head outline, indicating that this visual appearance is very intentional from id's artists. No such manual touch ups occur in any other angle. I'm beginning to wonder if this is an error at all. If this was truly just a layering problem, then we should be able to see the dark brown border of the head silhouette, just as is visible around the sides of the head and around the arms and such (also much more clearly around the head in other angles). However, although the head outline is discernible, it's not a clear delineation that a layering problem would leave behind. There's almost a soft blend between the fire and the head.

Rather, what I'm beginning to see here is what seems to be intended partial transparency. Although the fire has a hard edge when it's in front of nothing else (i.e. every non-front-facing angle), it's not meant to be perfectly opaque. It's a floating ball of blinding light, and indeed, in every frame where the fire's edges overlaps the Vile's body, it lacks the hard brown edges that you see in the P2/P3/P7 frame. In which case, the fire is in fact properly rendered in the foreground of the Vile's front-facing P1 frame. It's just been drawn in such a way that reflects its translucency.

Hence, after having made my edit and tested it out for a bit in-game, I'm heavily leaning towards reverting this change. It's not merely the simple cut and paste fix it seemed to be at a glance, and scrutinizing it further, it can't rightly be justified as a simple layering order error to begin with when there are signs of willful art touch ups consistent with the other frames. I think we've just jumped the gun and misinterpreted the intentions here as we're only looking at this one Vile frame (and its angles) as an isolated instance. In the context of the rest of the Vile's attack frames and angles, it's looks well within the same style and approach taken by the others.
 

3 hours ago, Linguica said:

P7 was shortened a bit because it is slightly further away from that vantage point. If anything, P1 should be grown a little.

That's true from the correct art perspective, but the hand drawn elements in Doom's sprites tend to be inconsistent in that regard, especially in the adjacent rotations. The visible portion of the P1 fire warranted that the bottom half shift upwards to match, thus making it shorter. I suppose this is a moot point as it's not the outright error it appeared to be at first.

Edited by Revenant100

Share this post


Link to post

I'm not sure it's really represented "behind" the head. Imagine if it were a separate sprite rendered with additive translucency to make it look more like a bright flame than like an opaque yellow blob.

Share this post


Link to post
17 hours ago, Revenant100 said:

Part of the fire in the last front-facing frame (P1) of the Arch-Vile's attack sequence appears to be layered behind his head instead of in front of him.

But that's how it always was. I mean, it's not 2 sprites that are Z-fighting - the flame is baked right into the sprite with the Archvile. Did someone decide that id drew that frame wrong - is that what the issue is?

 

If so, I fully agree with your notion that, in the P1 frame, the head doesn't have that brown outline, and it's totally intentional. I vote for "Don't fix it if it ain't broke". Fire would be a bit translucent, and having it in front of the Archvile (as it is in all the other P frames) would absolutely eliminate any shadow you'd otherwise expect on the top of the head. This effect is also somewhat visible on the O frame (VILEO1).

 

I don't know why I missed the original post, especially when Linguica quoted it. Honestly, I think the "fixed" version makes the flame look like a banana, or a yellow diamond, or anything other than a flame, because of the brown outline on the bottom of the flame, overlayed on the Archvile's head. I'm convinced that special consideration was intentionally given to VILEP1 by id, specifically to eliminate "banana-head".

 

Thanks for the detailed explanation.

 

Edit: If you absolutely could no longer stand VILEP1, I would suggest looking at VILEN1 which still shows a bit of non-yellowed Archvile head. Instead of pasting the flame onto VILEP1, you could add a few non-yellow skull parts to the left and right of the flame, to suggest that the flame actually extends in front of the head. But, it's looked good to me for 25 years... And, this is not an errant pixel or two: This is a two-dimensional field of pixels, under the assumption that id screwed up the attack angle everyone sees the most - I don't buy it.

Edited by kb1

Share this post


Link to post

Damn, this is a mighty fine addition to my Dooming, I'll have to try those brightmaps supplied, seeing as my custom set aren't compatible with this. If it turns out I really like this I may consider this a replacement, it looks more comprehensive than my cobbled together one anyway.

E: Which means I'll have to update the brightmaps supplied with my Doom Plus, argh. Maybe while I'm at it come up with a better name!

Share this post


Link to post
3 hours ago, cyan0s1s said:

Damn, this is a mighty fine addition to my Dooming, I'll have to try those brightmaps supplied, seeing as my custom set aren't compatible with this. If it turns out I really like this I may consider this a replacement, it looks more comprehensive than my cobbled together one anyway.

E: Which means I'll have to update the brightmaps supplied with my Doom Plus, argh. Maybe while I'm at it come up with a better name!

DAIWITB: "Doom, as id wanted it to be"

DAISY: "Doom, as it should (have been) yesteryear". Now, I'm reaching...

Share this post


Link to post

The red line on the bottom left is the edge of Doomguy's pants. It might look a bit odd because it seems like his pants are transparent since they match the background colors, but that's how colored lighting was rendered in some cases throughout the artwork. The red line at the upper right is one of the wires coming out of the Cyberdemon's arm. You can see it more clearly in Brom's original artwork. It's been drawn a bit too straight in the TITLEPIC, but it's correct.

d2cyberwire.jpg.d2361a3d536107ae65613816104f9812.jpg

Share this post


Link to post

Wow! Thanks for clarification! Now I see it. The wire is also red on CYBR sprites. I haven't noticed it until now.

Share this post


Link to post

There's a downside to that brightmaps pack, when using a bloodcolors.wad I did which replaces the Lost Soul, Caco, HK and Baron actors, it causes issues with the brightmaps as well as the graphics for those actors.
 

Also, can't say I'm a fan of the hands being fullbright for the Hell Nobles, or the orange Lost Soul skull, I prefer it the hands and skull to be blacked out like a brightmaps I have as it emphasizes the fire more and makes them look more spooky in low light areas.

Share this post


Link to post

It does have the originals, you have to opt out of the fixed sprites from within the PK3. It was the only way my blood colors wad worked otherwise. I should try out that Blood Fixer thing.

Share this post


Link to post

On another note, there are some wads such as Mapgame and Port Glacia that change the palette, not really to the extent that they'd need their own sprite fixing patches, but there are still some unfortunate inconsistencies, regardless of load order.

dI6J4Po.png

This one's from Mapgame, and shows the fixed 5 with a darker outline than the numbers that don't have new graphics and are only changed by the new palette. The fixed graphic for the Hey, Not Too Rough difficulty has the same problem, but GZDoom wouldn't let me take a screenshot of that.

AwtVrAV.png

The opposite is true for Port Glacia, where the numbers are supposed to have dark outlines but the fixed ones don't.

 

This doesn't seem to be true for everything though. PalPlus seems to give consistently dark outlines to the HUD numbers, for example.

Share this post


Link to post
14 hours ago, cyan0s1s said:

[...]

Also, can't say I'm a fan of the hands being fullbright for the Hell Nobles, or the orange Lost Soul skull, I prefer it the hands and skull to be blacked out like a brightmaps I have as it emphasizes the fire more and makes them look more spooky in low light areas.

 

I have to agree. I never liked the orange Lost Souls and the brightly glowing Hell Knight/Baron hands. Therefore, I have decided to change this now.

 

Spritefix-compatible brightmaps for GZDoom v1.5 (PK3, 4.3 MB)

 

Changelog:

- Removed orange/yellow tints from all Lost Soul frames
- Replaced Hell Knight/Baron of Hell frames with those from brightmaps.pk3 (more subtle "burning claws" effect)

 

See a Lost Soul comparison in the attachments below (first image: bm v1.42, second image: bm v1.5). Hope you like it better now!

 

 

lostsoul_bm142.png

lostsoul_bm15.png

Edited by NightFright

Share this post


Link to post
10 hours ago, SiFi270 said:

On another note, there are some wads such as Mapgame and Port Glacia that change the palette, not really to the extent that they'd need their own sprite fixing patches, but there are still some unfortunate inconsistencies, regardless of load order.

Big thanks for this report. This revealed a flaw in the way any sprite fixes with manual art edits were being converted back to Doom's palette, and it's an unfortunate side effect of the duplicate color entries in the PLAYPAL lump. The two darkest shades in the red range, indexes 190 and 191, are identical to two of the darkest shades at the end of the pink range, indexes 45 and 47 respectively. Since it has no possible way of knowing otherwise, SLADE was always remapping these particular colors to the pink range indexes. In normal Doom/Doom 2, this had no visual consequence at all since they're identical colors regardless, but with PWADs using custom palettes that treat these ranges in distinct and individual manners, this disparity becomes visually evident. I'll do a very meticulous pass on all modified sprites using these affected colors to address this issue.

 

Also, I don't normally bump the thread for compatibility patch updates, but since I'm replying now anyhow, I've just updated the WIP Dimension of the Boomed compatibility patch in the OP in accordance with the recent DotB Beta3 release. This is an old preview pic, but it still stands:

 

u9HLXZHm.png

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
×