PowerLightAmp flag to disable "Enhanced Night Vision Mod"

[phantombeta]

Pretty much what says on the thread title. My mod has powerup shaders that rely on everything being fully bright to look correct, so the powerups are descendants of PowerLightAmp. However, this means I need to tell players to disable the "Enhanced Night Vision Mode" option, as it completely ruins the shaders' look.

[Graf Zahl]

I'd really like to see the enhanced mode implemented for the software renderer, and then give this powerup some options.
But apparently nobody feels compelled to do it. I once tried and failed to make it render the sprites inverted because there's too much black magic involved

In general I ageee - there should be 3 modes, forced fullbright, forced enhanced and switchable.

[Rachael]

Obviously there is not enough concern or interest for the software renderer or this would be fixed. That's a huge showstopper. If we do a release without that being fixed then we'll have to deprecate the software renderer, which would make the point in the previous post a bit moot.

[Graf Zahl]

I can tell you what happens: It is rendering some segs from a MiniBSP for polyobjects and trying to get light info from the MiniBSP's subsector. Which of course doesn't have any of the necessary info set. The bug is old, but in older versions it merely caused visual glitches at worst. But since the BSP builder has no idea what a section is, it leaves some data uninitialized.

In the hardware renderer this never matters because these subsectors are never used for anything.

I'll have to see how easy it is to fix. Normally it should be enough to pass on this data from the parent subsector when the MiniBSP has bee built.

[Rachael]

Did dynamic lights ever even work on polyobjects in software? I would not mind if the dynamic light check is skipped completely for polyobjects in software - that at least would not be a regression.

GZDoom 3.6.0:

[Rachael]

I'd really like to see the enhanced mode implemented for the software renderer, and then give this powerup some options.
But apparently nobody feels compelled to do it. I once tried and failed to make it render the sprites inverted because there's too much black magic involved

Alright, you fixed the major bug in the software renderer - so I'm going to write the drawer to do what you want here - but I do have one question:

Where is the code in your OpenGL code that determines whether something is inverted or not?

[Graf Zahl]

You mean for the sprites? At the moment that's a bit of a hack. Here's the code that sets the render info:

Code: Select all

		else if (cplayer->fixedlightlevel != -1)
		{
			auto torchtype = PClass::FindActor(NAME_PowerTorch);
			auto litetype = PClass::FindActor(NAME_PowerLightAmp);
			for (AInventory * in = cplayer->mo->Inventory; in; in = in->Inventory)
			{
				//PalEntry color = in->CallGetBlend();

				// Need special handling for light amplifiers 
				if (in->IsKindOf(torchtype))
				{
					FullbrightFlags = Fullbright;
					if (gl_enhanced_nv_stealth > 1) FullbrightFlags |= StealthVision;
				}
				else if (in->IsKindOf(litetype))
				{
					FullbrightFlags = Fullbright;
					if (gl_enhanced_nightvision) FullbrightFlags |= Nightvision;
					if (gl_enhanced_nv_stealth > 0) FullbrightFlags |= StealthVision;
				}
			}
		}

and it then uses the 'Nightvision' and 'Stealthvision' flags to render some things inverted and for fuzzy stuff translucent, so that it becomes more visible. 'Stealthvision' is for partially disabling the MF_STEALTH flag when the powerup is on.

Of course, once this is done properly as a feature, the code will be cleaned up to base its decisions on the item's settings.

[Rachael]

Okay, yeah, that's what I was looking for, thanks. Please keep in mind that what I'll be committing will be very beta and preliminary so it will need to be fleshed out a bit before it's finalized. To that end, I'll do it in a branch instead of master when I am done.

The main point will be to enable the drawers, at least, so that you can finish it out how you want, later.

[Graf Zahl]

I think for software rendering it is fully sufficient to use the default inverse color map for rendering these instead of explcitly inverting the color of each pixel.

[Rachael]

If you would prefer to do it that way, that's fine, it'll be easier for implementation to just use the drawers I wrote, though, and they can be adjusted anyway.

The reason for that is because it's going to take some tweaking to figure out how to activate the colormap. Even the truecolor renderer doesn't use it anymore, from what I've seen, it just forwards that work to the screen shader instead, now.

[Graf Zahl]

Ok then. Actually that was the reason why I switched to just inverting in the hardware renderer, too. It was a lot simpler to do, but on the other hand is a free operation with hardware rendering.

[Rachael]

I will finish this later, wrangling with software drawers tends to give one quite the headache. I already committed my in-progress work in the swnitevisdrawer branch a couple hours ago, but I am guessing you already saw it by now. I just need a break from coding, for now.

This commit can serve hopefully as a good example of how to create new drawers. It would be really nice, if in the future we could design a system to simplify this a bit more, but for now, that's what it takes to get everything to compile. The drawers are not yet tested but with how tightly contained the code is, I'm almost certain that it works as intended.

[Rachael]

https://github.com/coelckers/gzdoom/tre ... evisdrawer

This is as far as I want to go with this - I have no real interest in this feature, so I am hoping that I got at least the basic and the hard parts out of the way so that you can take it from there and do what you want with it. I don't anticipate that my code will be too hard to understand, if you have any questions feel free to ask.

It's functional, however it has no idea what objects should be thrown to the new drawers and what not to.