override void tick()
{
for (int i = brightLights.size() - 1; i >= 0; i--)
{
if (!brightLights[i])
brightLights.delete(i);
}
// freed itself
if (!checkNoDelay())
return;
// Advance the state
if (tics != -1)
{
if (tics > 0)
{
tics--;
}
while (!tics)
{
// mobj was removed
if (!setState (curState.nextState))
{
return;
}
}
}
}
If you're also adding lights after any light sensors are created, you'll also need to make other, more complex changes to the light sensors for them to be aware of the new lights.
I've posted 2.42b that includes the patch from phantombeta (great!) and changes the marker placement code to be the same for everything. I haven't had a chance to look at this for many levels, but it seems more natural in some areas such as here:
Note the improvement from the previous MAP01 screenshot above. In this one, the light is evenly pouring in through the window and the glitch to the left is gone (another bug fix thanks to something Enjay pointed out).
Getting better all the time. It's a great way to play through familiar maps and get a new perspective on them - makes old familiar maps creepy again.
I was wondering is anything can be done to allow for sectors that change appearance.
e.g. E1M2
The nukage pool is creating a green fog environment (be nice if the platform sector was also included, but I can see why it isn't).
After hitting the switch, the nukage disappears but the green fog persists.
Re: Relighting Doom v2.321b [Updated 1/19/22] - Now With DL
Posted: Sun Jan 23, 2022 5:49 pm
by SLON
Enjay wrote:I don't know how much use this is, but I thought I'd record a video of the performance hiccups that I was talking about.
It's a little strange because I have a noticeably older system, but everything went smoothly.
As for the lighting issues, the only way to overcome this is to change all the lighting to dynamic, instead of the old-school scheme that is hard-coded to sectors.
Enjay wrote:Getting better all the time. It's a great way to play through familiar maps and get a new perspective on them - makes old familiar maps creepy again.
I was wondering is anything can be done to allow for sectors that change appearance.
I've seen the same thing. Perhaps, in the World Line Activated event and iterate through sector tags. I'll have to check into it.
The above sector is linked to the wall switch with action 9 linked to tag 8. It seems I would need to iterate through all sectors, since multiple sectors can have the same tag. Sounds possible.
Update:
The above works - sort of - but for present I've decided to disable fog. I'd rather avoid this kind of exception programming... thanks for pointing this out.
I've posted a small update (v2.43b) in which I've disabled fog. It's possible to find out which sectors have changed where when, but I'm not a fan of exception programming in this case. I suspect this would just break many maps, so I've chosen to disable fog while I ponder this.
I have added support for adding dynamic light actors to top, middle, and/or bottom textures. Previous versions averaged colors and stuck a dynamic light actor in the middle. While this version may add more dynamic lights they are placed logically depending on definitions.
Update: I see that some of the colors are now more noticeable, as in the Exit on MAP01. I suspect this is a color definition more than a coding problem. In previous versions colors were incorrectly averaged, because I didn't check for null textures. This version fixes that bug. I'll look at colors again I guess.
Update:
Working on sizing based on texture area. Much better since part of the issue is the top or middle (as well as window height) may not doesn't match width. Next update.
Previous code was dealing with diluted color and so dynamic lights were much stronger. I have tweaked this calculation to be based on sidedef area, which makes more sense than just the width of a texture.
Minor release with dynamic light calculation tweaks and more subtle lighting. Still working on this regarding colors and size of textures, but this will give you a better idea of the direction. Also experimenting with subtractive lighting.
The white balls are not spirit orbs. They are for my benefit in testing and represent dynamic light objects.
I've added dynamic light windows as an option, since this is used to cast light from much brighter into much darker areas and can be a performance hit since it increases the number of dynamic lights. I've reordered the light code to determine the sector light levels before attaching any dynamic lights and added an option to select the perceived brightness calculation that determines the strength of the light. (Perhaps someone with more knowledge can enlighten me - yes, ha ha - on that subject.)
Many bug fixes and other things, so this will be an important but incremental release, possibly tomorrow.
fixed a lot of little bugs related to dynamic light placement
added an option to select one of two formulas for perceived brightness (converting RGB to luminance); note this only affects strength of dynamic lights added by Relighting.
there was a bug in certain areas, such as the closet at the start of E1M4, that has been fixed
There are still far too many areas of the game without any visible light at all, but then Doom is meant to be a horror game. Some areas work well with dynamic lights:
Note that "window" lights are not only outside windows but any opening from an area of light to dark exceeding limits. I've added a Settings option to turn window lights off completely, since it does add quite a few dynamic lights in some areas.
A handful of oddities that I quickly spotted:
It might be an idea to include a brightmap for the exit signs to prevent situations like this.
Is this sector meant to be green? To me it looks odd - especially with the water being so blue. There is no obvious reason in the map for it to look so green IMO.
For some reason, the nukage pool is very dark in an otherwise bright outdoor area.
Enjay wrote:Looking nice and still performing well.
A handful of oddities that I quickly spotted:
It might be an idea to include a brightmap for the exit signs to prevent situations like this.
Is this sector meant to be green? To me it looks odd - especially with the water being so blue. There is no obvious reason in the map for it to look so green IMO.
For some reason, the nukage pool is very dark in an otherwise bright outdoor area.
Originally my problem with MAP02 was no light sources at all, and since I'd give NUKAGE3 a color I added one to FWATER1. Then I added a greenish color for the PIPEWAL textures. But you're correct, this looks dumb. Here's a revised look: https://i.postimg.cc/YCR5y1y2/Screensho ... 185440.png
As an aside, I've looked at spotlights. Currently this uses sector or point lights with support for subtractive lights (not sure about the latter). I tried an overhead spotlight, and this didn't add to or replace the sector-based lighting. Most of Relighting is still sector based, so I've abandoned (for now) the idea of adding texture spotlights.
adds 5 sector lighting steps (should be no performance hit)
moves the "Luma" calculation to Light Performance Settings, since this also affects sector lighting
optionally change the number / distribution of light source markers
I'm continually disappointed using dynamic lighting as light sources; they don't seem to be suited for it. Doom has sector-based static lighting, and a primary goal of Relighting has been to improve that feature. That's the intention of this minor update. Increasing lighting steps below 512 map units creates subtle gradients of light. The light sensors only see placed light source markers, so increasing the number of markers also helps lighting quality at a performance cost. I haven't noticed this on my rig, but it certainly hits performance. What this means, since light markers are prioritized at doors and then two-sided lines, is that sensors respond quicker and in more locations.
Increasing the number of steps below 512 won't impact performance, but it will make the game a bit brighter in some areas, and I also tweaked these limits.
I forgot initially that the calculation to determine perceived lightness of color (RGB->Luma) also affects sector lighting, so I've moved this to the Color Settings menu. I've not tested this extensively, but theoretically it adjusts lighting based on however the human eye perceives light. Rods and cones are not evenly distributed and have different wavelength sensitivities; our eyes are more sensitive to some colors than others. This "perceived brightness" is the idea behind adjusting sector lighting and dynamic light strength. Both formulas give more weight to the color green, for example, to which our eyes are most sensitive. BT.601 emphasizes red and blue more.
Thus, the colors chosen in the text lumps can significantly affect lighting. Darker colors result in a gloomier game.
