ZDoom

thugsta wrote:

Hey Doomer wrote:

Any chance of a LZDoom release as well?

It seems only function that is unknown is:-
flat[0].StripRight();
flat[1].StripRight();
text[0].StripRight();
text[1].StripRight();

I'm not familiar with LZDoom. Are you saying that StripRight() is a problem in LZDoom? If so, simple to fix.

Hey Doomer wrote:

thugsta wrote:

Hey Doomer wrote:

Any chance of a LZDoom release as well?

It seems only function that is unknown is:-
flat[0].StripRight();
flat[1].StripRight();
text[0].StripRight();
text[1].StripRight();

I'm not familiar with LZDoom. Are you saying that StripRight() is a problem in LZDoom? If so, simple to fix.

Yes.

Also you had warnings for x/y but they was fixed with a Pos.X/Pos.Y. You'll need to update those for the main release if you want to keep log clean.

thugsta wrote: Yes.

Also you had warnings for x/y but they was fixed with a Pos.X/Pos.Y. You'll need to update those for the main release if you want to keep log clean.

OK. Yeah I've fixed the warnings as a cleanup. Working on the string function...

Update: Uploaded v2.1. That should fix the StripRight() issue and a good thing, since I found another bug in the code.

Note: v2.1 fixes door line specials by allowing CheckProximity for LightSensors on those lines. Should eliminate light artifacts associated with doors opening and closing.

Working fine so far in LZ/GZ. Love your work.

How you feel with allowing your mods be use in created mods, full credit of course.

thugsta wrote:Working fine so far in LZ/GZ. Love your work.

How you feel with allowing your mods be use in created mods, full credit of course.

Thanks! Always good to hear nice things. Absolutely OK to use with credit.

I'm looking at Light Sensor placement in some detail, moving these to optimal heights, eliminating redundants, fixing little bugs, etc. Here are two screenshots that show how sensors now work together:

https://i.postimg.cc/yNPFpCTD/Screensho ... 194512.png
https://i.postimg.cc/d1VGzNW4/Screensho ... 194516.png

Note the light source (red ball) at the top of the lift and the two sensors (goggles) that see the light (ignore the one on the far right, it can't see the light). When the lift is down (top screenshot) both sectors are lit because both sensors see the light. When the lift is up (bottom screenshot), the bottom sensor can't see the light and so the sector is dark. I see a lot more of this kind of thing in the latest build.

I'm experimenting with adding dynamic lighting to Relighting. I'm not a fan of point lighting so far. DynamicLight.SectorLight, however, adds a nice touch to sector lighting in Relighting. Example screenshots:

https://i.postimg.cc/PrgF9XQW/Screensho ... 035120.png
https://i.postimg.cc/GpbHk3QL/Screensho ... 040703.png

This is most noticeable for white lights as in the above, but it also can add a subtle touch in areas otherwise pitch black as in the bottom shot from E2M1. (It makes sense that hot bricks would have a dull glow, I think, but that's me.) Still working on this, but it are some pretty.

The new colored lighting with a darker bias combine with dynamic lights can be quite interesting:

https://i.postimg.cc/PqLhRT4B/Screensho ... 054003.png
https://i.postimg.cc/y8t2W9mb/Screensho ... 055105.png

In the top screenshot, the walls are colored by the blood pools. (Note the texture above the door.) This works well, and as a darker flat color it makes this "bright" sector darker and much more sinister. (Remember that bright sectors don't change light levels, because they don't have any light sensors.)

The bottom screenshot also shows this effect to some degree enhanced by dynamic lights. In this case the nukeage and the door entryway have static sector lighting. I haven't cherry picked this stuff, but this strikes me as a good example of what Relighting can do.

Again this all depends on how textures are defined in the text lumps (these can be commented out). All sectors start out lit with the Settings minimum. The more I look at this the more I tweak this or that shade, all a matter of taste. This mod should work with any maps and any texture set, including Heretic. I have not yet made allowances for slopes, 3D floors, etc. Also, I haven't done anything at all to sector specials that affect lighting (blinking, etc). In some cases that works, and in others it's another case of light coming from nowhere. So far I have decided not to change that.

Let me know what you think!

I'm not a fan of PBR textures in GZDoom, mostly because they appear bland using sector lighting. The performance cost is too high for so much work and so little eye-candy. However, I am working on added a reflections lump to Relighting. I assume this can have a smaller performance impact than PBR and add realism. Here's what it looks like:

https://i.postimg.cc/tJ3Vp5RH/Screensho ... 115139.png

There aren't many reflective surfaces in the game - mostly fluids and perhaps metal floors like the above - but they add to lighting as can be seen in this example. The lump is similar to others with reflection amount substituted for color. Coming for the next release...

Getting closer... I have posted v2.32b of Relighting. I've spent time looking at colors and dynamic lighting.

Screenshots:
https://i.postimg.cc/FRz4gShS/Screensho ... 051855.png
https://i.postimg.cc/XvQWCL63/Screensho ... 052758.png

The top illustrates the effect of colored sector lighting on a "bright" sector with static lighting. The sector light level is adjusted according to perceived brightness of the color, but adding a "gray goose" color to outside sectors adds a nice overcast touch. Depends on how one feels about colored sectors, I suppose. I'm pleasantly surprised at how some colors work to enhance an otherwise dull area.

The bottom illustrates how dynamic lights work and why they are needed. Much of Doom is deliberately dark, but Doom 2 is just darker with few light sources. Dynamic sector lights can fix that as shown. In this case the lights are attached to the elevator supports with this line in rl_gldefs.txt:
This is just boring yellow; a different shade can change how this looks and feels.

There appears to be limits to how and where the engine allows dynamic lights. That's pretty much impossible to manage in a script. Some areas that should be lit with dynamic lights may not be for that reason, although I've added code to reduce the number of dynamic lights that are too close to each other. Let me know what you think!

Hey Doomer wrote:.

Hey there is a bug/error on startup ...

thugsta wrote:

Hey Doomer wrote:.

Hey there is a bug/error on startup ...

Hm... I wonder if that's an LZDoom problem. I don't see any warnings or errors on E1M1 using GZDoom.

Are you able to see what the CVar rl_tid is when that happens?

This is running on GZ. running 4.7.1. Just as a note I would state if on LZ as i have to test on both environments for compatibility with Desktop(GZ mainly, LZ only to test before sending it off to be played in VR) and VR. Sorry for confusion.

How do i check the cvar rl_tid? turning on debug?

thugsta wrote:This is running on GZ.

How do i check the cvar rl_tid? turning on debug?

You can just type it in the console. I've made rl_reflections default to false for now and uploaded this version as 2.321b. Let me know if that works.

Hey Doomer wrote:

thugsta wrote:This is running on GZ.

How do i check the cvar rl_tid? turning on debug?

You can just type it in the console. I've made rl_reflections default to false for now and uploaded this version as 2.321b. Let me know if that works.

I figure out what was wrong, You did a typo as the command was not working in console. You added an s to the cvarinfo file. It is running now. Should be user string rl_tid