Changing Brightness with Gradients

[Lutz]

Action 12 (W1 Change Lights to Brightest Adjacent) is cool and all, but it tends not to work when you are trying to brighten lights with gradient effects all at once -- generally, all of the gradient sectors end up with uniform brightness despite the presence of dummy sectors connected to other dummy sectors with variable brightnesses.

Is this a limitation with using one tag with multiple sectors? Or is it is related to sector numbering (i.e. can I get around it by always sorting the sector numbers in increasing/decreasing order from darkest to brightest)? Or is it "check all adjacent sectors of those sectors changed in this tick" (meaning I am forced to use multiple line triggers that are sufficiently far apart)?

Basically, can anyone offer a good (vanilla-ish) way to instantly brighten gradient lighting without using multiple, well-spaced triggers?

[durian]

Yeah it can be done (a little demo).

All you need to do is have the light in your gradient sectors set by 261/213 transfers. Have the dummy sectors that your transferring from - not the gradient sectors - set to change to brightest adjacent, and make sure their only adjacent sectors have the light level that you want to change to. Then, when they change with the line action, the gradient sectors will change too. I can knock up a demo map if this isn't clear.

Oh, but not vanilla! Maybe vanilla-ish?

[Lutz]

Thanks -- I know you mentioned fighting this same battle recently. I will give this a try, and send up a virtual flare if I can't figure it out.

However, I thought that whether or not sprites are affected by 213 tags is port-dependent -- in certain ports, sprites do NOT reflect the floor brightness value.

[scifista42]

Doomwiki said:

Lights to Maximum Neighbor
Each tagged sector is set to the maximum light level found in any adjacent sector. The tagged sectors are changed in numerical order, and this may influence the result.

---

So that you don't have to care about the 1-tic thing, I guess, only the sector numbers. However, in vanilla:

ZDoomwiki said:

Doom had a logical bug in its algorithm to search for the highest light level in neighboring sectors, which prevented it from looking past the first tagged sector's neighbors. This bug was fixed in Boom, and later ZDoom adopted the fix as well.

In other words: ...when a light level changes to the highest light level found in neighboring sectors, the search is made only for the first tagged sector...

---

So I guess the safest solution should be to use multiple tags and put multiple linedefs with the same action very close to each other? It seems so, to me, although I'm not entirely sure if I'm right.

[durian]

Lutz said:

However, I thought that whether or not sprites are affected by 213 tags is port-dependent -- in certain ports, sprites do NOT reflect the floor brightness value.

Yes I think you're right there - mouldy made a thread about this recently. I don't recall what the variations were exactly, but prb+ and ZDoom exhibit (what I would take to be) the desired behavior - that is, the sprite lights up when the levels change.

Here's a demo map - I stuck a zombie in there so you can see what different ports do with it.

EDIT

Oops! I messed that up - sectors joined when they shouldn't have been. Link updated to better illustrate what I meant, and - unlike the previous version - this doesn't work properly in prb+. The fact that the messed up version does work in prb+ is surprising to me - I'll have to investigate!

[durian]

Apologies for the double post but this seemed like it was worth a separate entry. scifista was correct!

The previous version worked simply because - for whatever reason - I'd used individual lines and tags for the brightness change. In this case, it seems there's no need to mess around with transfers!

This works properly in prb+. It could be done in a vanilla compatible way, except I used a voodoo doll on a scroller, just to ensure that the player doesn't miss any of the lines.

[durian]

Gah!
I just tried to implement this in the map from which the above gif is taken, and it doesn't work :( All sectors are changing to the brightest sector - the problem Lutz highlights. I'm not sure what accounts for the difference in behavior - perhaps sector/line numbering? In any case, I guess I'll stick with the transfer method. I've devised a somewhat cheap solution to prb+'s not taking the transferred brightness. The result is that sprites light up, but without the gradient being distributed across them (link). It'll work fine for static sprites, but might be noticeable for things which move through and out of the light.

[Lutz]

Wow -- go, smart people. Thanks guys.

I'm going to play around with the transfer method and see how that looks (it might actually be pretty cool to have dark actors on a lit floor). If nothing else, I'll put something in the text file to inform everyone how *I* tested it.

[durian]

Good stuff! I'm keen to see what you'll come up with. One thing to note is that the transfer method will only work in ZDoom if compat_light is set to false, which won't be the case if ZDoom's compatibility options are set to 'DOOM strict' (and I assume I'm not the only person who regularly uses this). But you can force this in an unobtrusive way via mapinfo.

[TimeOfDeath]

Here's a vanilla method: vanlight.wad

The gradient sectors are separated from each other with tiny dark sectors that have higher ceiling and lower floor with missing textures. The gradient sectors have different tags, but all the triggers are placed on top of each other and activate at the same time.

[Linguica]

Wouldn't you have to be careful with that though, so you didn't overflow spechits?

[TimeOfDeath]

Sure, but 8 triggers is still kind of a lot. :)
Even then, from what I understand, a spechits overflow might not harm the map anyway.

[esselfortium]

TimeOfDeath said:

Sure, but 8 triggers is still kind of a lot. :)
Even then, from what I understand, a spechits overflow might not harm the map anyway.

A spechits overflow will break demo recording, as far as I know.

[TimeOfDeath]

- Spechits, Reject and Intercepts Overflow Lists
- Overflow of array of the crossed special lines

I guess it's best to be safe and try to avoid them, but the gist I got from those threads was that they can lead to desyncs but not necessarily. Myself, I've recorded on two maps with a spechits overflow and neither desynced.

[mouldy]

The brightness changes in the order of the sector numbers, so if you make sure the sectors of the gradient are numbered in the order of darkest to brightest then you can do it with dummy sectors.

Here's a test wad to show:
http://www.mediafire.com/download/b4e7qfr6byhlbjc/light-gradient.wad

[durian]

Ah ha! That'll be why it worked in the test map but not when implemented in a proper map. Cheers mouldy!
All that's needed now is a straightforward way of renumbering sectors, short of manually changing all the line references(?)

[TimeOfDeath]

Just a note that mouldy's wad requires boom compatibility.

[mouldy]

TimeOfDeath said:

Just a note that mouldy's wad requires boom compatibility.

Right, as scifista mentioned above, in complevel 2 it just uses whatever brightness of the first sector for all others.

[Linguica]

Here's a random question, is there any way to implement a functionally complete logic gate with one of the light-changing linedef specials? I was trying to imagine a diagram but couldn't figure out how (or if) it would be possible.

[scifista42]

Linguica said:

Here's a random question, is there any way to implement a functionally complete logic gate with one of the light-changing linedef specials? I was trying to imagine a diagram but couldn't figure out how (or if) it would be possible.

IMO, no. There are only linedef actions to brighten a sector, and other actions to darken a sector. Also, there is no action to "check" for a light value. I cannot imagine a combination of lines that would work as a "smart toggle" (dark->bright, or bright->dark) when triggered together. Maybe I misunderstand you, though. How exactly would you imagine the function of such a "logic gate" in Doom?

[Linguica]

I was thinking along of the lines of using the "change to brightest adjacent" special along with a specially crafted collection of sectors that are set up in such a way that given two "input" sectors and an "output" sector, when Boom steps through all the tagged sectors in numerical order, it works like a NAND gate or whatever.

I doubt it's possible, but I don't have any sort of education in the subject to really make a determination or explain why it wouldn't be.

[scifista42]

Wait...

OR is the simplest, obviously doable function - first make sure that your output sector is darkened, and then just use "change brightness to brightest adjancent" action on it. (assuming that there is one output sector, connected to both input sectors and to nothing else)

On a similar principle, I can imagine AND. First, light up the input sector, then use "change brightness to darkest adjancent" action on it.

I'm still unsure about NAND, NOR, or even NOT - though they might be simple and I'm just unable to imagine it. This is relatively basic logic. Doom's linedef actions simply don't have "negation". I've been thinking about combining the actions for the last hour, but whatever I thought off always failed somehow. But maybe... I'll think about it some more. My thought process is not really scientific, mind you - even though it should be, I'm studying a lot of mathematics at IT university (logic, proofs and such), but I still prefer "non-systematic" thinking when trying to solve problems like this (again, I know that I shouldn't be). :P

P.S.: Gez (or whoever), please, if you already know the answer along with an explanation to this simple logical riddle, tell us! :P

[scifista42]

Let's say that 0 = dark light level, 1 = bright light level. We have a system of sectors, each of them assigned a light value of 0 or 1, and each of them connected to some other sectors (however we need). Since we want to simulate a digital system, let's say that no other values than 0 or 1 exist. Here is a list of possible operation we can do with the sectors, using Doom's linedef actions:

-Set value 0.
-Set value 1.
-Change value to the value of "input" (=one of neighboring sectors): First we need to darken the sector and all its neighboring sectors except input sector, then "change brightness to brightest adjancent".
-Therefore, we can use a chain of sectors to "move" input sector's value to any other sector in the system.
-Do <OR> from 2 or more inputs: As I described in my post above.
-Do <AND> from 2 or more inputs: As I described in my post above.

So once again - we can:
1. Set a given value.
2. Move one sector's value to another sector.
3. Do OR.
4. Do AND.

I've come to a conclusion that there is no way to implement "negation" with these tools only. I can't think off an algorithm that would give output 1 if input was 0 and give output 0 if input was 1. There's no way to create such "1" when input is 0, without also being "1" when input is 1. And the same for 0. I give up. I don't believe that there can be anything else than AND and OR.