Sky transfer bug

I should have post about this bug several months earlier but thanks to kmxexii who reminded me about it, I post it now.

Eternity engine's sky transfer rendering differs from PrBoom+ and even from vanilla MBF. I've encountered this problem while working on my The Last Sanctuary level, which features day/night cycles done by voodoo dools. While it work properly in PrBoom+, there are 2 ports that don't render it properly - GZDoom and Eternity Engine.

The main concept of this feature is to transfer main sector's light level to another (control) sector and use 242 boom action (property transfer) to bind them. So, each sector has its unique control sector with same floor and ceiling heights. The reason of 242 action usage is because there are only 2 actions in Boom to set sector's light level : to nearest brightest and nearest darkest (I don't count 255/35 change actions). Thus, you can't use them directly on main sectors, because it will change the light level to the brighest/darkest light level from adjacent sectors. So, all control sectors should be separated and have only one adjacent sector: the sector that will copy the light level from reference sector (brighest/darkest action) and transfer it to control sectors (another brighest/darkest action), which, at last, will change the main sector's light level. Yes, I know, it's really tricky and messy :)

The Eternity Engine's bug is that it does not render sky properly. The bug shows itself on places with different ceiling heights. Here are screenshots in PrBoom+ and Eternity Engine from the same place on level:

PrBoom+:


Eternity Engine:

Jesus Christ, did you do this map by hand or did you use WadC or other automation tools? It's so high tech I don't even.

I'm looking into the problem, though I hope I can reproduce it in a simpler map.

I once noticed that this map defines a sky in the middle part of a Boom-242 sector while having a valid upper part. That was causing massive glitches in GZDoom.

Who knows if it also affects the (ill-advised) changes SMMU made here, which Eternity inherits? That'd be the first thing I'd look for.

Fixed, but not fully. You'll see parasitic vertical sky planes blocking the view (more often than with regular sectors, i.e. without having to change light level), unlike in MBF and PrBoom. In this map they won't be easily noticeable, though. It's not easy to isolate this to exactly emulate MBF/PrBoom rendering.

The issue had nothing to do with MBF sky transfers, but everything to do with Boom height transfers.

Graf Zahl said:

I once noticed that this map defines a sky in the middle part of a Boom-242 sector while having a valid upper part. That was causing massive glitches in GZDoom.

Who knows if it also affects the (ill-advised) changes SMMU made here, which Eternity inherits? That'd be the first thing I'd look for.

Can you be more specific about the SMMU changes in question?

This makes me wonder:

How much sense would it make to actually revert these SMMU-based changes to the 242 type and then implement a proper colored lighting system rather than piggybacking on this?

AFAIK that's Eternity's biggest compatibility problem.

kb1 said:

Can you be more specific about the SMMU changes in question?

Sure.

In Boom when you set a colormap with the 242 type, the view position determines use and then affects the entire view. So when you are in a sector with a blue colormap the entire screen becomes blue.

SMMU changed it so that it effectively works as colored lighting only in the sector it's in.

Here's an old discussion from the ZDoom forum about this issue:

http://forum.zdoom.org/viewtopic.php?f=7&t=28450&hilit=eternity+smmu

I also had a dilemma on how to treat midtexture clipping, as it happens always in Eternity in sectors with fake flats, unlike in MBF where they can still bleed (but in fewer situations than without fake flats). The seg rejection code seems quite different between Eternity and PrBoom+, so I can't use one as reference. Maybe I should also check the MBF renderer code.

The only change I made was fix a mistaken removal of the sky-hack internal flag when drawing over-ceiling areas (above 242 fake ceilings) even though these areas still had sky ceilings. The bug in the OP is the unwanted rendering of upper textures when the sector behind has a sky. Everything you see in the OP is rendered above a fake 242 ceiling, with zero tall underfloor and main area.

printz said:

Jesus Christ, did you do this map by hand or did you use WadC or other automation tools? It's so high tech I don't even.

Of course not, I'm not that crazy. All used tools are mentioned in "Editor(s) used" section of txt.
I've programmed an utility (boomlightgen) that takes light values of all sectors with tag>10000 and generates a script for WadC, which builds a "voodoo doll script" for day/night cycle.
The only big disadvantage of this method is big linedefs/sidedefs usage (50% of map is day/night cycle "script", heh)
I also have an advanced version, it could build different lighting for night based on 2 wads which are identical except for light levels (so first wad is day light, the second is night light). The cost is 2x more linedefs/sidedefs.
I see WadC as a really cool utility to script in Boom-format maps.

Anyway, thanks for the fix!

cybermind said:

I've programmed an utility (boomlightgen) that takes light values of all sectors with tag>10000 and generates a script for WadC, which builds a "voodoo doll script" for day/night cycle.
The only big disadvantage of this method is big linedefs/sidedefs usage (50% of map is day/night cycle "script", heh)
I also have an advanced version, it could build different lighting for night based on 2 wads which are identical except for light levels (so first wad is day light, the second is night light). The cost is 2x more linedefs/sidedefs.
I see WadC as a really cool utility to script in Boom-format maps.

I'd be very interested in seeing this - I found https://launchpad.net/boomlightgen but no code there. Care to share? :)

(I've got some WIP WadC helpers for managing boom effects, that try to handle all the sector generation stuff for you, and yeah, you can quite quickly have hundreds of control sectors)

I've updated the code, check it out now. Haven't really bothered with the style, it only does its job and nothing more.

Graf Zahl said:

In Boom when you set a colormap with the 242 type, the view position determines use and then affects the entire view. So when you are in a sector with a blue colormap the entire screen becomes blue.

SMMU changed it so that it effectively works as colored lighting only in the sector it's in.

That reminds me that Legacy did the same thing with their initial implementation of Boom 242. On the one hand, it would be very handy to have the ability to fine-tune coloured regions like zdoom does, but unfortunately boom didn't do that so the other ports should not coerce 242 behaviour, but add another tag or something.

I think I hit this in Eternity recently with some stuff I was doing with WadC, where you go under water and have a view from a lower sector, under the water, to a higher sector which has the water in it too, but when the player would be in that sector they would have been above the water level. The colormap transitioned back to normal. I might still have that test WAD around.

Jon said:

That reminds me that Legacy did the same thing with their initial implementation of Boom 242. On the one hand, it would be very handy to have the ability to fine-tune coloured regions like zdoom does, but unfortunately boom didn't do that so the other ports should not coerce 242 behaviour, but add another tag or something.

Agreed. In ZDoom the colormaps just work like Boom - for colored light there is a different method that creates its colormaps on the fly instead of requiring the mapper to provide them. And that should be something Eternity can replicate easily, instead of depending on SMMU's broken colormap handling for that. That's an odd choice for a port that considers backwards compatibility as one of its selling features.

Here's some fun story: In the very early days of GZDoom, long before it had a name or I even thought about releasing it to the public I actually did copy this code into it - but removed it very quickly after I noticed that it caused more problems than benefits with existing maps.

I have seen maps in the past that do not display correctly in Eternity due to this. Some underwater areas in P:AR, for example, have no colormap set and depend on one provided by the current viewpoint.

Strangely enough a few years back this difference in behavior between ZDoom and Eternity got reported as a ZDoom bug... :D

Graf Zahl said:

And that should be something Eternity can replicate easily, instead of depending on SMMU's broken colormap handling for that. That's an odd choice for a port that considers backwards compatibility as one of its selling features.

I prefer to let the user specify a full colormap, than limit myself to standard effects like color filters or fading. Same goes with translucency maps. In fact I'm really tempted to add an EDF thingtype feature where besides standard stuff like blend/additive/subtractive translucency, also allow custom tranmaps. The feature is already there!

Now I hope I can reconcile all this with the true-colour evolution that Quasar wants to put into Eternity.

Regarding the compatibility topic, there are indeed past mistakes made by Lee Killough and Fraggle. An example is this, about Boom attractor things.

Here's my quick take about:

printz said:

I prefer to let the user specify a full colormap, than limit myself to standard effects like color filters or fading.
Same goes with translucency maps.

As you say:

printz said:

Now I hope I can reconcile all this with the true-colour evolution that Quasar wants to put into Eternity.

Short and quick: Not really doable. Especially the tranmap is a totally palette locked feature. It utterly depends on having a 256-color palette. You may be able to deduce an alpha from it, but that's really all that can be done.

For colormaps you may be able to deduce a blending color, ZDoom has some code for that which gets used by GZDoom to turn them into something usable.

Any more complex colormaps will pose a rather large problem for true color rendering.


And let's not forget that you buy that flexibility at a very high price.
Imagine a mapper wanting to do some red, green, blue or yellow light.
Are they more likely to create four colormaps manually or would they prefer a simple OPEN script or UDMF property that allows them to set the color without any fuss?

I guess the answer is clear here. Even if you want to keep the colormaps, i t wouldn't really prevent you from implementing a more mapping friendly method.

Same for translucency. Internally you can still create a tranmap from an alpha value, but guess what would be more convenient to a mapper!

How about both? Expose both programmatic standard parametric filters which are easier to use, and also let the user specify colormaps and translucency maps for more complex effects.

Regarding true colour: instead of mapping discrete colours, map ranges to ranges. Or let user define more complex programmatic filters if a colormap is no longer feasible.

Personally I wouldn't bother with true colour (unless I can still implement these special effects) but I don't have the full prerogative here. I wouldn't like to see a cool new vanilla colormap mod (or even megawad with such a colormap!) that won't look properly in Eternity. I also don't like when people are discouraged from doing stuff because advanced ports are incapable.

Not allowing to use colormaps takes a lot of flexibility away. It's like having the limitations of true color rendering without true color rendering.

But I don't see how this is related to the fact that a certain Boom effect doesn't work like it's supposed to. Is it necessary to modify said effect to have colormap-based colored lighting in Eternity?

printz said:

I wouldn't like to see a cool new vanilla colormap mod (or even megawad with such a colormap!) that won't look properly in Eternity.
I also don't like when people are discouraged from doing stuff because advanced ports are incapable.

Such a map will already not look correct in any existing hardware accelerated port.

I wouldn't disable those feature in a paletted software renderer - but one has to be realistic here: The mere fact that two of the more popular ports already have a hardware renderer which is technically incapable of supporting such palette-based features (and ZDoom only having superficial support of TRANMAP) means that there's already some significant discouragement going on, IOW, using this stuff would inevitably restrict the audience quite drastically.

I let history be the judge here.
How have these features fared in the past?
How many mods are there with custom TRANMAP lumps?
And how many of those do anything beyond a simple translucency mapping?
And how many mods are there which use a custom colormap outside the handful of precreated one made for Boom?

Not many, that's for sure.

Da Werecat: sorry for going off-topic. I'll consider fixing this discrepancy. Knowing the low quantity of SMMU (and above) mods, I'll probably setup an EMAPINFO compatibility setting, console command, command-line parameter or wad signature hack that enables the SMMU behaviour if needed, while defaulting to the Boom one.

Graf Zahl said:

The mere fact that two of the more popular ports already have a hardware renderer which is technically incapable of supporting such palette-based features (and ZDoom only having superficial support of TRANMAP) means that there's already some significant discouragement going on,

It goes both ways. Developers can be "pressured" to implement features and special effects, or acceptable approximations thereof. :) See like how ZDoom has that superficial, for now, support for TRANMAP.

TBH, I didn't even know ZDoom still supports TRANMAP. If it does, it probably requires some additional voodoo, because it doesn't work in my wad.

Da Werecat said:

TBH, I didn't even know ZDoom still supports TRANMAP. If it does, it probably requires some additional voodoo, because it doesn't work in my wad.

ZDoom doesn't truly support it. The TRANMAP is analyzed to determine whether it can be emulated with a translucency value from 0% to 100%, or with a 100% additive blend. Any other effects aren't going to work as intended.

Well, 100% additive blending is exactly what I did in my TRANMAP, so I can only assume that the algorithm is flawed.

Da Werecat said:

because it doesn't work in my wad.

In that case I'd suggest reporting that problem with a test map. The algorithm is quite rough and hasn't been tested extensively due to lack if material.

It's this one. TRANMAP was made as an image in Photoshop using "Screen" blending. I just tried it on 2.8.0 and it doesn't seem to work.

Graf Zahl said:

Such a map will already not look correct in any existing hardware accelerated port.

I wouldn't disable those feature in a paletted software renderer - but one has to be realistic here: The mere fact that two of the more popular ports already have a hardware renderer which is technically incapable of supporting such palette-based features (and ZDoom only having superficial support of TRANMAP) means that there's already some significant discouragement going on, IOW, using this stuff would inevitably restrict the audience quite drastically.

I let history be the judge here.
How have these features fared in the past?
How many mods are there with custom TRANMAP lumps?
And how many of those do anything beyond a simple translucency mapping?
And how many mods are there which use a custom colormap outside the handful of precreated one made for Boom?

Not many, that's for sure.

Personally, if I could add support for (G)Z* ports by adding something that did the same job as TRANMAP, in a way which was not incompatible / didn't break other ports, and could include a TRANMAP lump for those other ports, I would do so. In fact I might be looking at this soon, I've recently been doing some COLORMAP stuff with WadC, and I wrote some vanilla compat code (define dummy textures matching the custom COLORMAP lumps), so I would like to add support for other engines/methods/ways of achieving those things. But they have to work in concert with each other.

Depends on what the TRANMAP does. If it's a simple translucency map ZDoom's map loader will try to extract the alpha from it, or if specific conditions are true, enable additive blending.

Anything beyond that won't work - for the simple reason that ZDoom doesn't implement this kind of palette to palette mapping and has no true alpha channel.

In GZDoom I could theoretically extract an alpha map by looking what it does with pure white and pure black per input color but any effect that does specific color alterations to a subset of colors is definitely out.

As for alternative features, that entirely depends on what the intent is. A generic replacement does not exist.

What about other fancy filters, such as hue, saturation, luminosity? Or wavelength function filters. Maybe instead of TRANMAP, high-colour ports may implement filters? :) TRANMAP is basically a filter that's been precalculated into a LUT.

In a paletted software renderer none of this makes sense.

And in a hardware renderer the final blending stage is still not accessible for custom programming, so I haven't spend much thought about this.

TRANMAP is one of those features that occasionally come up, some people show some cool effects, but after that all it will get used for is to reduce the translucency of certain textures from 50% to 25% or so.

Ultimately this is the perfect backward-thinking feature, i.e. it utterly depends on some 20 year old limitations to work - and that will forever hamper its usability.

printz said:

What about other fancy filters, such as hue, saturation, luminosity?

If that's what you want, you either have to deal with severe color degradation through repalettization, or you just apply it directly to the color palette.