Brightmaps Plus (spritefix compatible)

[Agitatio]

In my experience, Software "Sector light mode" looks closer to Software Renderer than Vanilla. Vanilla is really dark.

[Grizzly]

And Sigil isn't intended to be too dark

Software renderer on can still be quite dark if your map just has little sector lightning. Take the side by side comparison in the attachments.

I'll consider doing a "lite" version without any texture brightmaps and glowing eyes removed (even official brightmaps.pk3 has some, at least for the zombie, sergeant and chaingunner) for the absolute purists or special cases like Sigil.

The purist in me says that the way to do this is to only give brightmaps to sprites and textures that are fullbright initially, like the lost souls and candles.

[phantombeta]

In my experience, Software "Sector light mode" looks closer to Software Renderer than Vanilla. Vanilla is really dark.

That's because it is. The reason for that is because the "Software" sector light mode is meant to emulate ZDoom's software renderer, which has a particularly nasty and ill-advised change by randi that makes it much brighter than vanilla Doom's software renderer. "Vanilla" is exactly as it says in the name - the lighting emulates what it looks like in vanilla Doom.

[Agitatio]

Interesting. Thanks for the explanation!

[Grizzly]

In my experience, Software "Sector light mode" looks closer to Software Renderer than Vanilla. Vanilla is really dark.

That's because it is. The reason for that is because the "Software" sector light mode is meant to emulate ZDoom's software renderer, which has a particularly nasty and ill-advised change by randi that makes it much brighter than vanilla Doom's software renderer. "Vanilla" is exactly as it says in the name - the lighting emulates what it looks like in vanilla Doom.

Ooh! I was not aware of this, and this runs contrary to everything I've been told about the lightning systems thus far. Thanks!

(Also how did I not notice this myself whilst I play on Chocolate Doom quite often...)

((Also, question, why does GZDoom default to "Dark" rather then Vanilla?))

[NightFright]

This is mostly an internal restructuring for better overview. The only real change is moving brightmaps for the burning barrel (FCAN) from Doom 2 to Doom 1 since it also appears in doom.wad, so definitions for it should not only be available in Doom 2. I have also updated the compatibility package for GZD 4.0.0 (and lower) to reflect these changes.

CHANGELOG (v1.63):
[GENERAL] Brightmaps dir restructured into "sprites" and "textures" branches
[DOOM/HERETIC/HEXEN] Moved "flats" folders to textures subdirs
[DOOM] Separate folders for Doom 1 and Doom 2 content
[DOOM] Burning barrel (FCAN) moved from Doom 2 to Doom 1 definitions
[PLUTONIA] Moved "plutonia" folder to textures\doom
[TNT] Moved "tnt" folder to textures\doom

[Caligari87]

Split light mode posts to a new thread.

[Tesculpture]

Bug: sprite SARGA2C8 from the spritefix is missing a brightmap. Looking at an idle pinky in a dark area from in front/to their left, their eyes erroneously blink on and off.

[NightFright]

Was really easy to fix. Thanks for the report!

CHANGELOG v1.64:
[DOOM] Added missing spritefix brightmap for Demon (SARGA2C8)

[Skafsgaard]

Hey, NightFright - thank you for this!

I'm not exactly sure what the difference between 1.64 and 1.64a is, though. Is it just that 1.64a has backwards compatibility with pre-4.0.0 versions of GZDoom, while 1.64 does now? And if so, why not just have 1.64?

Thanks!

[NightFright]

1.64a is identical to 1.64 except for using the old names for lump filtering (e.g. doom.doom1 instead of doom.id.doom1). Theoretically I could have stayed with the old definitions since I doubt they will ever be removed due to compatibility reasons, but you can't be sure. Eventually I will probably drop support of pre-4.0.0 versions and add instructions how to make the brightmaps pack compatible manually. It's just about removing the "id" part from four folders (doom.id.doom1, doom.id.doom2, doom.id.doom2.plutonia and doom.id.doom2.tnt).

[Skafsgaard]

Hmm, I'm not sure I understand, sorry.

But the practical difference is that one of them is only compatible with 4.0.0+, while the other has backwards compatibility - is that the gist of it? If so, which one has backwards compatibility? And if not, then is there any practical difference for the end user at this point in time?

[NightFright]

In GZD 4.0+, it doesn't matter right now. Both versions work - unless support for the old syntax is dropped.

At the end of the day, if all this is too confusing, I will consider discontinuing one of the two versions with the next release.

[Skafsgaard]

It is slightly confusing, yeah.

But all right, good to know. Which one of the two is backwards compatible, then, though?
Sorry about all the questions!

[okbuddy]

1.64a