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

[Revenant100]

29 minutes ago, kb1 said:

Good Lord, that's a ridiculous amount of work, isn't it? I'm sure I can modify my Wad editor to remap some colors, if you give me a WAD, and a list of colors to remap.

It does indeed seem this issue will require a fair bit of work, as after my first audit, it looks like roughly 200 sprites have become affected by this invisible palette issue over the years. I appreciate the offer for help, but unfortunately, there's no automated way to go about fixing this. My regular art editing process of exporting graphics from the IWAD in PNG format, making my changes, reimporting, and then converting the lumps back into Doom graphics format was destructive in terms of retaining the original palette index information. Since the palette mapping is lost, there's no automated method that can simply translate these indexes back to what they were originally. You might think undoing the problem would just be a simple task of remapping pink range indexes 45 and 47 to the red range indexes 190 and 191 in the appropriate frames, but sadly, it's not that simple. In my audit, it's become abundantly clear that id's artists had no idea that these duplicate colors were in the palette, so they regularly made use of all of them even within the same sprite despite half of them being visually redundant.
 

Here's a visual abstraction of what's happening:

 

This is just one example frame, but rest assured, this color usage is common practice throughout the IWAD, so many of the sprite fix frames unintentionally fell victim to the remapping issue. I'll have to think about how exactly I'm going to tackle this problem.

[Gez]

SLADE does have a color remapping tool, and if you need precision, be aware that you can use its pixel-editing feature with a translation pencil. I'm talking about these things:

 

 

The first icon serves to set a translation. Exact same interface as the color remap, except it doesn't affect the image immediately.

Second icon (the little dot) serves to set the brush. You can set it to up to a 9x9 square.

Third icon sets the color. Left click gives you the system's native color picker; right-click lets you choose a color from the game palette.

Fourth icon is the panning tool. When it's selected, drag and drop the image to change its offsets.

Fifth icon is the pencil tool. When it's selected, clicking the image will repaint it with the chosen color.

Sixth icon is the eraser tool. When it's selected, clicking the image will create transparent areas.

Seventh icon is the translator tool. That's the one that's interesting. When it's selected, clicking the image will apply the chosen translation.

 

So basically, set a translation, set a brush, and then selectively translate areas of the image without affecting other areas. For example:

Here I've set a radioactive-looking pink-to-green translation and scribbled on the pinky.

Edited April 28, 2018 by Gez

[Lila Feuer]

@NightFright These are much nicer than before, good stuff!

[kb1]

4 hours ago, Revenant100 said:

It does indeed seem this issue will require a fair bit of work, as after my first audit, it looks like roughly 200 sprites have become affected by this invisible palette issue over the years. I appreciate the offer for help, but unfortunately, there's no automated way to go about fixing this. My regular art editing process of exporting graphics from the IWAD in PNG format, making my changes, reimporting, and then converting the lumps back into Doom graphics format was destructive in terms of retaining the original palette index information. Since the palette mapping is lost, there's no automated method that can simply translate these indexes back to what they were originally. You might think undoing the problem would just be a simple task of remapping pink range indexes 45 and 47 to the red range indexes 190 and 191 in the appropriate frames, but sadly, it's not that simple. In my audit, it's become abundantly clear that id's artists had no idea that these duplicate colors were in the palette, so they regularly made use of all of them even within the same sprite despite half of them being visually redundant.
 

Here's a visual abstraction of what's happening:

 

This is just one example frame, but rest assured, this color usage is common practice throughout the IWAD, so many of the sprite fix frames unintentionally fell victim to the remapping issue. I'll have to think about how exactly I'm going to tackle this problem.

 

Ok, this is how I see it:

I have a WAD editor that I can set up to automatically pass through each sprite, do something, save, and continue through the list. So far so good.

 

Now, from what you're saying, you've edited a bunch of the original IWAD's graphics, and upon saving, your editor chose different color indices which, when using the original PLAYPAL, happen to reference the same RGB values.

 

So, here's what I can do: I can load up your sprite, and separately load up the original sprite, and compare each pixel from one to the other. If the color index from your sprite is different than the vanilla sprite, but the same RGB value, I'll swap in the original index. That should preserve all of your single pixel tweaks, and revert the rest of the sprite to original indices.

 

Now, for your single pixel tweaks, I can do a convert to the range you want. So, if you want me to do this, I need to know which of the seven duplicates to use when the RGB value of your pixel does not match the RGB value of the original.

 

The duplicates, in hex are:

00 = F7

04 = A8, D0, E0

2D = BE

2F = BF

CF = F0

 

Here's the PLAYPAL with the hex indices marked:

 

It's going to be tricky - I'm going to have to develop an algorithm that overlays both sprites for comparison in the proper place. If you've added pixels above, or to the left of the original sprite, they will not overlay properly without being moved. I know how to write it, but it's a bit of work - I may just manually overlay them. There's probably only a few that do not exactly overlay. I'll work it out.

 

I will not have access to DoomWorld until Monday, but that gives me time to set up a compare function. Don't do it manually - that's too much work, and error-prone. Just please give me that list when you can (I can guess what you want, but just to make sure.)

Ok?

 

Edited April 28, 2018 by kb1

[Manuel-K]

@kb1

I would ignore the tricky ones and focus on fixing the bulk first. The basic cases should be easy to fix automatically. https://en.wikipedia.org/wiki/KISS_principle ;-)

[NightFright]

7 hours ago, Bauul said:

I've long been somewhat stuck with this, as the Minor Sprite Fixing work Revenant has done is absolutely brilliant, but its incompatibility with the basic GZDoom brightmap is an issue in-game.  The only compatible brightmap I know (the one linked on this thread) is just too extensive for my liking - things like glowing eyes just changes the gameplay far too much imo.  So then you're kind of stuck with no good solution either way.

[...]

 

I may do a 1:1 conversion of brightmaps.pk3 that comes with GZDoom. Since I kept the spritefix brightmaps separate from the rest in my project, it would help a bit with the process. Will still be a lot of work since you have to check whether the sprite widths have been increased to the left or right side and by how many pixels. Unfortunately, I did not note that down for each and every of the affected sprites. This way I'd have to do a one-by-one sprite comparison again.

Edited April 28, 2018 by NightFright

[Revenant100]

On 4/27/2018 at 8:02 PM, Gez said:

SLADE does have a color remapping tool, and if you need precision, be aware that you can use its pixel-editing feature with a translation pencil. I'm talking about these things:

 

Thanks! As of recently, I've started doing as many manual art edits within SLADE as possible, and that will be the preferred workflow from here on out. It's just that I believe SLADE didn't have these tools in the past (I'm talking 4-5 years ago), so it wasn't an option at the time. A few things now in SLADE like the mirrorpad function were even spurred on by this project, but I had to do that all manually beforehand.

 

On 4/27/2018 at 11:50 PM, kb1 said:

So, here's what I can do: I can load up your sprite, and separately load up the original sprite, and compare each pixel from one to the other. If the color index from your sprite is different than the vanilla sprite, but the same RGB value, I'll swap in the original index. That should preserve all of your single pixel tweaks, and revert the rest of the sprite to original indices.

Much gratitude for the effort. I'll be as clear as I can with the information, but it's a tricky situation all around to describe.

 

On 4/27/2018 at 11:50 PM, kb1 said:

Now, for your single pixel tweaks, I can do a convert to the range you want. So, if you want me to do this, I need to know which of the seven duplicates to use when the RGB value of your pixel does not match the RGB value of the original.

 

The duplicates, in hex are:

00 = F7

04 = A8, D0, E0

2D = BE

2F = BF

CF = F0

Unfortunately, all of these duplicates palette colors have been affected. If it's necessary to narrow this range down for the sake of feasibility, 2D=BE and 2F=BF are the most significant to address here since they're causing the most potential visual issues as discussed. However, I've determined that all seven of these duplicates have manifested issues in these sprites.

 

To be clear, is it necessary for you to know which duplicates to use, or can you just take this data directly from the original sprites that you're using in the comparison?

 

On 4/27/2018 at 11:50 PM, kb1 said:

If you've added pixels above, or to the left of the original sprite, they will not overlay properly without being moved.

Yes, that is going to be the case in several frames due to the aforementioned sprite padding. The horizontal dimensions of several sprites were changed, although this literally just means extra blank space, not new art. Additionally, many sprites were renamed for adjusted rotation purposes. The sprites themselves are identical, but the lump names won't match.

 

If it will help cut down work, I've listed out the 199 sprites within D2SPFX19.WAD that exhibit one or more of the duplicate palette color reduction errors:

Spoiler

STTNUM2
STTNUM5
STTNUM8
STFGOD0
M_ROUGH
CHGFA0
CHGFB0
MANFA8A2
MANFA7A3
MANFA6A4
MANFB8B2
MANFB7B3
MANFB6B4
MISFA0
MISFB0
MISFC0
MISLA6A4
SHT2E0
SHT2I0
BFGFA0
SARGF1
TROOA1
TROOA2C8
TROOB1
TROOB2D8
TROOC1
TROOC2A8
TROOD1
TROOD2B8
TROOE1
TROOE2
TROOE8
TROOF1
TROOF8
TROOG2
PLAYU0
PLAYV0
PLAYW0
POSSH0
POSSN0
POSSO0
SKULB8B2
SKULC8C2
SKULC6C4
SKULD8D2
SKULD6D4
SKULE8E2
SKULE7E3
SKULE6E4
HEADA2A8
HEADA3A7
HEADA4A6
HEADB2B8
HEADC2C8
HEADD2D8
HEADB3B7
HEADC3C7
HEADD3D7
HEADB4B6
HEADC4C6
HEADD4D6
HEADE2E8
HEADF2F8
HEADE3E7
HEADF3F7
HEADE4E6
HEADF4F6
PAINA2A8
PAINB2B8
PAINC2C8
PAIND2D8
PAINE2E8
PAINE3E7
PAINF2F8
PAINF3F7
PAING2G8
BSPIA1D1
BSPIA2D8
BSPIA3D7
BSPIA4D6
BSPIA5D5
BSPIB1E1
BSPIB2E8
BSPIB4E6
BSPIB5E5
BSPIC1F1
BSPIC2F8
BSPIC3F7
BSPIC4F6
BSPIC5F5
BSPID2A8
BSPID3A7
BSPID4A6
BSPIE2B8
BSPIE3B7
BSPIE4B6
BSPIF3C7
BSPIF4C6
BSPIG2G8
BSPIG3G7
BSPIG4G6
BSPIH1
BSPIH2H8
BSPIH3H7
BSPIH4H6
BSPII6
BSPII7
BSPIL0
SKELA5D5
SKELA6D4
SKELA8D2
SKELB3E7
SKELB4E6
SKELB8E2
SKELC1F1
SKELC2F8
SKELC3F7
SKELC4F6
SKELC6F4
SKELC7F3
SKELC8F2
SKELI7
FATTC3F7
FATTC4F6
FATTH2H8
FATTH3H7
FATTH4H6
FATTI4I6
FATTJ4
FATTJ6
SSWVN0
CYBRA3
CYBRA6
CYBRB2
CYBRG1
CYBRG3
CYBRH0
CYBRI0
CYBRJ0
CYBRK0
CYBRM0
CYBRN0
CYBRO0
CYBRP0
SPIDA1D1
SPIDA2D8
SPIDA3D7
SPIDA4D6
SPIDA5D5
SPIDB1E1
SPIDB2E8
SPIDB3E7
SPIDB4E6
SPIDB5E5
SPIDC1F1
SPIDC2F8
SPIDC3F7
SPIDC4F6
SPIDC5F5
SPIDD2A8
SPIDD3A7
SPIDD4A6
SPIDE2B8
SPIDE3B7
SPIDE4B6
SPIDF2C8
SPIDF3C7
SPIDF4C6
SPIDG2G8
SPIDG3G7
SPIDG4G6
SPIDG5
SPIDH2H8
SPIDH3H7
SPIDH4H6
SPIDH5
SPIDN0
SPIDO0
SPIDP0
SPIDQ0
POL5A0
BEXPE0
BON1A0
BON1B0
POL6A0
GOR1A0
GOR1B0
GOR1C0
GOR2A0
GOR3A0
GOR4A0
GOR5A0
SMRTC0
HDB1A0
HDB2A0
HDB3A0
HDB4A0
HDB5A0
HDB6A0

 

Edited April 29, 2018 by Revenant100

[kb1]

@Revenant100

My editor also currently screws up duplicates, I noticed. In my editor, when you edit an image, the image is rendered into a TrueColor bitmap, which, of course, erases the uniqueness of the dups. Then, upon save, it finds the first matching index, probably just like Slade, and every other editor out there. The easy fix for this is for me to create a new PLAYPAL, with 256 unique colors, and load the WADs up with that new PLAYPAL. This will give my save function a way to keep track of all indices.

 

I didn't see you list the new rotation frames (but I didn't look too far). I see there being 3 classifications here:

1. Images that exist in Doom, and match the Doom lump's dimensions

2. Images that exist in Doom, that don't match the Doom lump's dimensions (because pixels were added, or removed)

3. Images that don't exist in Doom (like the new rotations)

 

#1 - is (relatively) easy: If a pixel's RGB matches both, but different indices are used, use Doom's index.

#2 - easy, but the images need to be "aligned" so they overlay, to do the proper compare. This may become a manual process, cause the code to automatically align the images is pretty involved (You'd have to overlay the images in memory, and count the number of pixels that are filled in in both images. Then move one of the images in the X, or Y dimension, and do the count again. Choose the offset where the most pixels match. It's a lot of work which is not worth it for 200 images or so - easier to do manually).

#3 - Because these are new images, one might argue that it doesn't matter. I think it does, for consistency. For these images, I could do this: Take a comparable image (like for a new CPOS rotation, compare it to the 180-degree rotation that does exist in Doom). Identify all the indices used in the Doom image, and only use those indices in the new image. That will add some consistency, I think, especially for the person creating brightmaps, or when people use a new PLAYPAL.

 

The #3 method can also be used for new pixels added in image type #1 and #2 above. However, there's still the possibility that you've added a pixel somewhere, that:

• happens to be one of the dups
• is not found in any "comparable image"

In this case, I won't know which duplicate to use. So, what I really want to know is: If all else fails, which of the dups do you prefer that I use, in that situation? Here's the usage for Doom II, in pixels, for all images (sprites, wall patches, flats, images):

Spoiler

[Black]
00 - 163,496
F7 -   4,632

[White]
04 -  25,402
A8 -     276
D0 -     190
E0 -   1,670

[Red 14]
2D -  54,549
BE -  15,949

[Red 16]
2F -  76,950
BF -  81,496

[Blue 16]
CF -  18,144
F0 -     350

 

I don't know if that's the right way to look at it, but, if we did, 00 wins out for black, 04 for white, 2D for red 14, and CF for blue 16. For red 16, it's almost a tie (2F vs. BF).

 

So, I have an idea what the Right Thing to do is, but I don't have the time today to type it all up. Give me about a week or so, to include the next weekend - is that ok? I can fix them, in a way that should satisfy everyone. It doesn't seem so, but it's actually a pretty tricky thing to get right!

 

Question: If I fix the Doom II file, can you use that to fix the Doom 1 file, or does the Doom 1 file have anything in it that's not in the Doom II file?

 

 

 

Edited May 1, 2018 by kb1

[Revenant100]

55 minutes ago, kb1 said:

3. Images that don't exist in Doom (like the new rotations)

There are only three groups of sprites which fall under this umbrella: the new walking, firing, and pain rotations for the Zombieman, the new similar rotations for the Shotgun Guy, and the new firing rotations for the Imp. The Zombieman exhibits some duplicate color palette reduction errors only in his gibbing frames, outside of the group of new rotations. The Shotgun Guy exhibits no errors at all in this regard.

 

The Imp is the only one here that exhibits the color palette error in the new rotations. However, they're technically not "new" since these sprites did come from from a previous beta IWAD (0.5 to be exact), so a direct comparison can still be made with the said older IWAD. Also, the problem is limited to just two frames: TROOE8 and TROOF8. I've already determined I can easily fix this manually by doing the 2D->BE and 2F->BF palette translations. Hence, there's no reason for you to go to the trouble of accounting for your #3 classification since it's limited to only two sprites that can already be considered accounted for.
 

55 minutes ago, kb1 said:

So, what I really want to know is: If all else fails, which of the dups do you prefer that I use, in that situation? Here's the usage for Doom II, in pixels, for all images (sprites, wall patches, flats, images):

  Reveal hidden contents

[Black]
00 - 163,496
F7 -   4,632

[White]
04 -  25,402
A8 -     276
D0 -     190
E0 -   1,670

[Red 14]
2D -  54,549
BE -  15,949

[Red 16]
2F -  76,950
BF -  81,496

[Blue 16]
CF -  18,144
F0 -     350

 

I don't know if that's the right way to look at it, but, if we did, 00 wins out for black, 04 for white, 2D for red 14, and CF for blue 16. For red 16, it's almost a tie (2F vs. BF).

The number of sprites which use pixels of these particular colors that don't meet any of the above stated conditions are very small in number, and choosing which dupe color to use in those cases is going to require manual review regardless. Nonetheless, I agree with the dupe colors you've suggested in this scenario: 00 for black, 04 for white, 2D for red 14, 2F for red 16, and CF for blue 16. In short, the most commonly used colors. That way, I only have to address the smaller number of exceptions.

 

55 minutes ago, kb1 said:

So, I have an idea what the Right Thing to do is, but I don't have the time today to type it all up. Give me about a week or so, to include the next weekend - is that ok? I can fix them, in a way that should satisfy everyone. It doesn't seem so, but it's actually a pretty tricky thing to get right!

Take as much time as you feel is necessary. There's absolutely no rush here as the next release can be held off for as long as it requires, and that was already aiming for the very end of this year. We're going on six years now with this project, so time is most certainly a luxury.

 

55 minutes ago, kb1 said:

Question: If I fix the Doom II file, can you use that to fix the Doom 1 file, or does the Doom 1 file have anything in it that's not in the Doom II file?

Everything fixed for the Doom 2 PWAD can be directly used in the Doom 1 PWAD. You do not need to make any accommodations for Doom 1 as I'll be handling that once the Doom 2 fixes are ready.

 

And once again, many thanks for lending a hand here!

Edited May 1, 2018 by Revenant100

[kb1]

3 hours ago, Revenant100 said:

There are only three groups of sprites which fall under this umbrella: the new walking, firing, and pain rotations for the Zombieman, the new similar rotations for the Shotgun Guy, and the new firing rotations for the Imp. The Zombieman exhibits some duplicate color palette reduction errors only in his gibbing frames, outside of the group of new rotations. The Shotgun Guy exhibits no errors at all in this regard.

Aren't there also new rotations for Chaingun Guy?

 

3 hours ago, Revenant100 said:

 

The Imp is the only one here that exhibits the color palette error in the new rotations. However, they're technically not "new" since these sprites did come from from a previous beta IWAD (0.5 to be exact), so a direct comparison can still be made with the said older IWAD. Also, the problem is limited to just two frames: TROOE8 and TROOF8. I've already determined I can easily fix this manually by doing the 2D->BE and 2F->BF palette translations. Hence, there's no reason for you to go to the trouble of accounting for your #3 classification since it's limited to only two sprites that can already be considered accounted for.
 

The number of sprites which use pixels of these particular colors that don't meet any of the above stated conditions are very small in number, and choosing which dupe color to use in those cases is going to require manual review regardless. Nonetheless, I agree with the dupe colors you've suggested in this scenario: 00 for black, 04 for white, 2D for red 14, 2F for red 16, and CF for blue 16. In short, the most commonly used colors. That way, I only have to address the smaller number of exceptions.

Ignoring #3, and just using these hard-coded choices makes the project considerably easier, but I don't think it will yield results that are as good. Some of the #3 logic was to also be used on #2 new pixels. I'll have to study the images a bit more.

 

3 hours ago, Revenant100 said:

 

Take as much time as you feel is necessary. There's absolutely no rush here as the next release can be held off for as long as it requires, and that was already aiming for the very end of this year. We're going on six years now with this project, so time is most certainly a luxury.

Thanks - that's music to my ears, cause a week was cutting it close. I'm already 3 Doom projects late :) But this isn't too bad, so far.

 

3 hours ago, Revenant100 said:

 

Everything fixed for the Doom 2 PWAD can be directly used in the Doom 1 PWAD. You do not need to make any accommodations for Doom 1 as I'll be handling that once the Doom 2 fixes are ready.

 

And once again, many thanks for lending a hand here!

You're most welcome. You know, one of the easiest things to do is to make 2 new PLAYPALs:

#1. Change the pink (0x20 - 0x2F) range to, say, blue-green.

#2. Change the red (0xB0 - 0xBF) range to blue-green.

 

Overwrite the IWAD PLAYPAL with one of these, and add the other to your PWAD. That should make these issues stick out like a sore thumb. Maybe use some other new, gaudy colors for the other dups. Not so good for fixing, but great for testing!

 

I'll let you know as soon as I have something.

 

 

 

[kb1]

On 4/28/2018 at 2:56 AM, Manuel-K said:

@kb1

I would ignore the tricky ones and focus on fixing the bulk first. The basic cases should be easy to fix automatically. https://en.wikipedia.org/wiki/KISS_principle ;-)

Problem is, knowing which ones are tricky involves doing all the work, anyway. Yes, make it as simple as possible. But not more simple.

[Revenant100]

1 hour ago, kb1 said:

Aren't there also new rotations for Chaingun Guy?

Even though Romero released the sprite sheets for the Commando, the IWAD already had full rotations for his sprites.

[Bauul]

On 4/28/2018 at 12:23 AM, NightFright said:

 

I may do a 1:1 conversion of brightmaps.pk3 that comes with GZDoom. Since I kept the spritefix brightmaps separate from the rest in my project, it would help a bit with the process. Will still be a lot of work since you have to check whether the sprite widths have been increased to the left or right side and by how many pixels. Unfortunately, I did not note that down for each and every of the affected sprites. This way I'd have to do a one-by-one sprite comparison again.

 

To be honest, I don't think one would need to go back to square one with the brightmaps.pk3 in GZDoom.  Your brightmaps are generally much better quality than the GZDoom defaults and already take into account the Minor Sprite Fixing.  It would seem to me to be an easier job to take your brightmap and reduce it down.

 

I appreciate brightmaps are an entirely subjective thing and there's no "one best way" of having them.  In my mind though, if a brightmap that followed the same philosophy as the Minor Sprite Fixing project, it would just follow a single rule:

 

1) No brightmaps on textures or sprites (or parts of textures or sprites) that weren't previously lit (or artistically demonstrated to be lit).

 

My half-thought-out plan was to basically make a fork of your brightmap pack (which is so high quality it's awesome) and once I had a spare weekend remove all the extras: all textures and flats, all sprite frames that weren't previously lit (like walking animations) and any parts of the sprite that weren't lit on otherwise lit frames (like glowing eyes).  I think that would result in a brightmap that fit in with the goals of the Minor Sprite Fixing Project neatly.

[NightFright]

Well, you can try. As I stated earlier, you can turn off texture brightmaps in current releases by simply commenting out the texture lines in the definitions. If you do that, you are basically half-way there already.

[Manuel-K]

6 minutes ago, NightFright said:

Well, you can try. As I stated earlier, you can turn off texture brightmaps in current releases by simply commenting out the texture lines in the definitions. If you do that, you are basically half-way there already.

That's the first thing I do each time you release a new version. Glowing textures might seem like a good idea at first, but they break too many levels.

[Lila Feuer]

Amusingly, I seriously adore the mixture of texture brightmaps in combination with GLDEFs for specified flats, because it can really transform some scenes, much like the GL lights already do.

Oh, and bloom.

Edited May 1, 2018 by cyan0s1s

[kb1]

15 hours ago, Revenant100 said:

Even though Romero released the sprite sheets for the Commando, the IWAD already had full rotations for his sprites.

Really? I saw a few frames in your WAD, and just assumed they were to add missing rotations. Just fixing offsets, huh? I think when they made Doom II, they forgot about saving memory and floppy disk count (and missiles triggering linedefs, and that you can't use gametic for Revenant missiles, or demos go out of sync, and that Lost Souls are monsters and should be counted as such, and that crushed monsters have 0 height, so resurrecting them is problematic.) Doom II was a pretty lazy slap-together job, I think.

 

You know, I'm thinking that any frame you clicked "save" on probably got its pixels recalculated and re-indexed, unless the editor specifically tests to see if any pixels were modified, which it might have. I'm probably going to run them all through my fixers, so I don't have to research them.

 

6 hours ago, Bauul said:

I appreciate brightmaps are an entirely subjective thing and there's no "one best way" of having them.  In my mind though, if a brightmap that followed the same philosophy as the Minor Sprite Fixing project, it would just follow a single rule:

 

1) No brightmaps on textures or sprites (or parts of textures or sprites) that weren't previously lit (or artistically demonstrated to be lit).

Yeah, I kind of agree with this. I mean, glowing eyes are cool and all. I think I'd leave that for a couple of new monsters.

 

4 hours ago, NightFright said:

Well, you can try. As I stated earlier, you can turn off texture brightmaps in current releases by simply commenting out the texture lines in the definitions. If you do that, you are basically half-way there already.

I think the computer textures should glow, and maybe textures with obvious lights on them are ok. But things like the gargoyle eyes...it looks cool, but it's not what I would expect to see.

[Bauul]

So I had a go at forking NightFright's Minor-Sprite-Fixing-Compatible brightmap pack into something more vanilla.  I did this mostly for myself, but it's here if anyone else wants it.

 

Features:

• Brightmaps limited to frames that were either Fullbright before, or artistically look like they should be lit (e.g. explosions)
• No brightmaps on textures
• No glowing eyes

Using brightmaps instead of Fullbright does change the gameplay a little (it's harder to spot monsters that are shooting at you in the dark if they don't suddenly light up like a Christmas tree), but the overall effect is still pretty similar to the original gameplay experience.

[DELUXE]

Well done, it's a perfect mix between old and new. Fancy light effects, but without the potential to see any glowing eyes revealing enemies in the dark. I still have trouble figuring them out, but I quite like them.

 

As for sprite touch-ups, I've thrown together a list of various things that may or may not be issues, along with a little HacX fix WAD. I chose HacX because it's popularity pales to the other games, the errors I noticed were egregious, and I doubt many will care. The other games I’ll hold off on for the mean time, since Doom is still the primary focus. 

 

The zip includes the WAD along with two text files, one that details the HacX changes I made, and the to-do list I mentioned.

hacx_and_todo.zip

Edited May 5, 2018 by DELUXE

[Medis]

Hey people,

I wonder... Is the colormap subject to this as well? There is a known issue that the colormap was badly scaled, using 33 fade-leves rather than 32. This results into an issue where you are able to see in total light level 0 darkness which was never supposed to be.

[Revenant100]

4 hours ago, Medis said:

I wonder... Is the colormap subject to this as well? There is a known issue that the colormap was badly scaled, using 33 fade-leves rather than 32. This results into an issue where you are able to see in total light level 0 darkness which was never supposed to be.

The scope of this project aims solely at the sprites. There are other non-sprite fixes that could be slotted in a PWAD (the broken D_DDTBL2 and D_DDTBL3 music lumps come to mind), but these start introducing additional compatibility issues and complexities. A modified COLORMAP probably wouldn't cause too much trouble, but it's outside the purview here.

Nonetheless, I don't think I've seen fix for this COLORMAP issue before, and I believe many would appreciate someone making it and releasing it separately. Can't say I know how to go about making such a fix myself.

Edited May 7, 2018 by Revenant100

[Medis]

 Original

 Fixed one

 

The only practice difference can really be seen in total 0 darkness light level. 

Originaly created by Marisa Kisame from zdoom using original properities but correct number of fade-levels. 

They also coded a tool in BASIC that allows to generate those.

Edited May 7, 2018 by Medis

[Linguica]

I don't think being able to see slightly in 0 light is a "bug" exactly...

[Medis]

5 minutes ago, Linguica said:

I don't think being able to see slightly in 0 light is a "bug" exactly...

 

It is a small quirk, It happened in doom beta during development as they kept changing them. Obviously you are not supposed to "see" anything in Light0 sector but normally you can see walls. The colormap above fixes that by using proper amount of light levels. There are even some unused colormaps. I believe dev's become aware of it whenever they coded around.

Edited May 7, 2018 by Medis

[Linguica]

45 minutes ago, Medis said:

Obviously you are not supposed to "see" anything in Light0 sector

 

Again, I don't know that this is something obvious. It's possible that the id guys didn't know / care that you could still vaguely see some things in a 0-light-level sector, especially given that they were developing on CRT monitors. It's also possible that Carmack knew perfectly well what his colormap generation algorithm did and wanted there always to be some minimal amount of detail visible. In any event, even if you could conclusively prove that it was a "bug", what exactly is the benefit to making the game ever so slightly darker and what issue does it solve?

[Medis]

No, its not about that. It's just they wrote a code that rendered the colormap during beta. But later they forgot to update it to reflect final amount of light levels. It would not make sense to make it otherwise or just to boost lightning. I think that it is even comented in sources somewhere. But I have no other idea than just that  I am aware of it.

[kb1]

7 hours ago, Medis said:

No, its not about that. It's just they wrote a code that rendered the colormap during beta. But later they forgot to update it to reflect final amount of light levels. It would not make sense to make it otherwise or just to boost lightning. I think that it is even comented in sources somewhere. But I have no other idea than just that  I am aware of it.

Are you saying specifically that you've seen a disassembly of the beta executable, and it has a colormap generator within it, that uses an algorithm that creates a colormap with a darker level 0? Can you post the disassembly? Or if I'm wrong about you seeing a disassembly, I must ask: How do you know this? What is your source? (I believe you, I am just curious to see the algorithm, and I want to understand id software's intentions.)

 

Personally, I kinda like being able to see the walls a little bit, in total darkness. But if they meant for the colormap to be different, I might consider offering that as an option in my port.

 

By the way, I'm working on the sprite indexing issue. I think I can fix them properly.

[Blastfrog]

On 5/1/2018 at 12:43 PM, Bauul said:

1) No brightmaps on textures or sprites (or parts of textures or sprites) that weren't previously lit (or artistically demonstrated to be lit).

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.

 

 

[Bauul]

4 hours ago, Blastfrog said:

Good rule of thumb, but still very subjective. How about monster eyes, for instance?

 

Of course, every Brightmap is subjective because they didn't exist in the original game. 

 

Without derailing this thread (we should take it elsewhere if we want to continue discussing) I do disagree with your assessment of glowing eyes being the original design.

 

Any amount of glow would deviate from the original gameplay experience, so while by all means use glowing eyes if you want to, we'd be getting into the territory of trying to live up to supposed artistic visions rather than maintaining the original gameplay.

[Jon]

7 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))}.

 

Members of the Doom team who worked on Doom 3:

John Carmack

Adrian Carmack

Kevin Cloud

 

Members of the Doom team who didn't:

 

Shawn C. Green

Dave D. Taylor

Tom Hall
American McGee

Sandy Petersen

Bobby Prince

John Romero

 

To be clear, in case it's not obvious, I don't think 3 counts as "many of the key folks", although I massively respect their contributions. It's also amusing that ⅔ of them did it under duress.

 

Another interesting fact: ⅔ of the Doom-and-Doom-3 contributors also worked on Doom 2016 (John Carmack confirmed doing some of snapmap, Kevin Cloud)

Edited May 8, 2018 by Jon