Grubby Boom Lighting Hack

I found a hackish way of getting a masked texture to be lit independently of the upper/lower textures in Boom 2.02
compatible ports! It only draws [in]correctly in software renderers. :D

Works in:

Eternity
Legacy
Prboom 2.02
WinMBF

Draws incorrectly in:

Legacy GL (unlit)
Zdoom (unlit)
gzdoom (most gl ports upper/lower HOM maybe due to missing gl nodes but I don't care enough)
prboom 2.5.0 (software, but same as gl)
prboom-plus (software, but same as gl)
doom2.exe (upper/lower textures there, tutti frutti midtex, slowdown)

Crashes chocolatedoom on sight.



It uses some sector referencing mischief, my next goal is to use it in combination with various effects, so far I have it blinking in sync with the surrounding sector! Looks awesome if I may say so myself!

Example wad here: http://www.sendspace.com/file/9lddrd

Has anyone done this before??

Good luck with that. Crude doesn't even begin to describe it.

This totally depends on how the node builder splits a level though so you may have problems with it in more complex maps.

BTW, this crashes Doom.exe and Chocolate Doom because you are using a multipatch texture as mid texture (the light) - a big no-no for those engines.

An interesting effect.

I've tried to get the same effect a different way.
This one works with chocolate doom, zdoom, prBoom+, eternity (still not lit in GZDoom, Doomsday or glBoom+ though).
Also this one doesn't allow bullets / rockets etc to pass through.

Light2.wad

4mer: That does the job as well.

Graf Zahl said:

Good luck with that. Crude doesn't even begin to describe it.

This engine does my bidding. I take a dull hatchet to it whenever I open an editor.

Now I've created a voodoo doll sequence that raises the light level in 16 unit increments and starts the light blinking. I'm considering breaking more sectors to allow for the blinking light effect to affect multiple nearby sectors with differing heights.. seemingly.

This map is going to be a wondrous broken mess when I'm through, mark my words!

Yes, it has been done before. But better...

Linedef stacking is slightly more predictable, is compatible with v1.9 and is both software- and GL-friendly. The thing to remember is to use textures that are the same size as the gap you're trying to cover, or you'll get bleeding in GL ports.

iori said:

This map is going to be a wondrous broken mess when I'm through, mark my words!

Wow! That'd be an achievement. I wonder if you manage to beat the most broken hack map ever created for Doom (That'd be Eternal Doom III's Timeslip.) :P

It's still odd to me that Medusa error crashes Choco almost instantly whereas vanilla DOOM could tolerate it going on almost indefinitely. I think we need to do some research into exactly WTF *is* going on during the Medusa error.

Lee Killough did tell me years ago that Z_Malloc was implicated in the slowdown, but he declined to explain the mechanism as I'm sure I wouldn't have understood wtf he was on about back then.

As a guess I would say that the problem could be because r_things.R_DrawMaskedColumn expects a column_t but instead is being passed the column data which was extracted by R_DrawColumnInCache.

Maybe the following line (from R_DrawMaskedColumn) is causing the delay (column drawing repeats until this end of columns marker is found).

for ( ; column->topdelta != 0xff ; )

When the player is further away the pointer to the column data makes larger jumps through memory so perhaps can get to an 0xff quicker.
When the player is closer the pointer would move through memory a lot slower so maybe that is why the game slows down.
Chocolate Doom may be crashing due to the invalid memory access.

Also I think color 0xff is rarely used (if at all) in patches.

4mer said:

As a guess I would say that the problem could be because r_things.R_DrawMaskedColumn expects a column_t but instead is being passed the column data which was extracted by R_DrawColumnInCache.

Maybe the following line (from R_DrawMaskedColumn) is causing the delay (column drawing repeats until this end of columns marker is found).

for ( ; column->topdelta != 0xff ; )

When the player is further away the pointer to the column data makes larger jumps through memory so perhaps can get to an 0xff quicker.
When the player is closer the pointer would move through memory a lot slower so maybe that is why the game slows down.
Chocolate Doom may be crashing due to the invalid memory access.

Also I think color 0xff is rarely used (if at all) in patches.

Certainly makes some sense, although it doesn't seem like you could go too far in the zone heap without finding a 0xFF byte considering all the cached patches that are stored in there consecutively. Maybe the addresses being accessed are more outlandish, such that they're outside the heap entirely?

Either way if this is the case it makes what Lee said years back seem incorrect >_>

Andy Olivera said:

Yes, it has been done before. But better...

Linedef stacking is slightly more predictable, is compatible with v1.9 and is both software- and GL-friendly. The thing to remember is to use textures that are the same size as the gap you're trying to cover, or you'll get bleeding in GL ports.

That's an easier, more compatible way of doing it.
However there are texture constraints with that method, and the way I have done it allows me to sync the lighting effects of a sector regardless of heights with the masked midtex.

@Quasar
That's a point, for cached patches there should be 0xFF quite regularly but in the one being drawn there shouldn't be many unless some of the columns have a single patch.

Another thing that probably isn't helping is column->length being a color index.

Since Boom got transfer lights (floor and ceiling) linedefs. This is pretty pointless unless you're working with Vanilla.

kristus said:

Since Boom got transfer lights (floor and ceiling) linedefs. This is pretty pointless unless you're working with Vanilla.

If it were only that simple. Light transfer isn't dynamic - can't transfer flickering light onto another sectors floor for example. Probably grabs the light level at startup.



Well, to mess things up even more I've combined Andy's sector stacking with my method to produce this:



Managed to keep offsets intact using Andy's method for the unlit 'lower texture' portions. Works with sector lighting effects.

http://www.sendspace.com/file/hswlb0

iori said:

If it were only that simple. Light transfer isn't dynamic - can't transfer flickering light onto another sectors floor for example. Probably grabs the light level at startup.

Since when? I can tell you this is not true, nor has it ever been. BOOM pulls light transfers from sectors by using a reference to the source sector, and this is checked every frame that the sector is on screen, so if the source sector's light level changes, so will the transferred lighting.

Quasar said:

Since when? I can tell you this is not true, nor has it ever been. BOOM pulls light transfers from sectors by using a reference to the source sector, and this is checked every frame that the sector is on screen, so if the source sector's light level changes, so will the transferred lighting.

Indeed. I use light transfers on flickering or otherwise animating lights pretty frequently, and it works as you describe in all Boom-compatible ports I've tried.

It does work. Well fuck, there's a few hours wasted.

iori said:

It does work. Well fuck, there's a few hours wasted.

lolwut? The selective height lighting still cannot be achieved in Boom without hacks.

I didn't say it was all wasted, just the latest stuff I was experimenting with. A convoluted round-about method was easily replaced with boom transfers in 2 minutes. For some reason I thought they didn't transfer all the time.

printz said:

lolwut?

Pleasant.