Possible modifications to the Boom transfer colormap behaviour

[printz]

The Boom transfer heights special (242 in classic format) allows setting colormaps for any of the three subspaces. Whenever you would enter one, the entire view color would change. But Fraggle changed this in SMMU to be more similar to the ZDoom coloured sectors. Unfortunately, based on some reports, this seems to break some released maps (I have no on-hand proof, but it's plausible). So I'm thinking of restoring the Boom behaviour when using transfer_heights.

 

Eternity also lets you set colormaps when using UDMF or ExtraData. In that case however, keep the new behaviour introduced by SMMU, as it's generally more useful for new maps (and the only reason to modify transfer_heights now is the already released Boom maps).

 

Eternity currently has a console variable to switch between the SMMU behaviour and the Boom behaviour globally, so users who know of this console variable can fix the Boom maps. But this is not obvious or automatic.

 

And for map authors who want to force either the Boom or the SMMU behaviour globally, applied both for transfer_heights and UDMF/ExtraData, provide an EMAPINFO field for convenience.

 

Internally, I have an idea how to do this, without significant overhead. Will update this thread if I encounter bad news.

[esselfortium]

I agree that Boom maps ought to use the Boom behavior. As silly as that behavior may be, it's what's expected for compatibility.

 

For UDMF and ExtraData sectors, the per-sector method makes sense and should be kept.

 

(And ideally I'd like to see this augmented with something like ZDoom's sector tints as well, where the colormaps are generated automagically based on RGB values, but that's another can of worms)

[Graf Zahl]

I think it might be better to completely separate Boom colormaps from colored sector lights. These are essentially two different features and creating different semantics based on map format or stuff is not good. ZDoom also has made that mistake a few times and most of these have caused problems later.

 

 

[Altazimuth]

4 hours ago, printz said:

this seems to break some released maps (I have no on-hand proof, but it's plausible)

I know for a fact this caused an issue in one of the maps from Dimensions of The Boomed (but I sent Urthar a fix so that it looks the same in EE as it does in PRBoom+, which has been implemented).

 

I'd be OK with an EMAPINFO option (that defaults to BOOM behaviour), though other approaches seem reasonable. Whatever is clean and fast.

[Jon]

I'm in favour of this fix. It caught me out recently 

[printz]

Resolved: now sector colourmap setting acts as described in the original post, and I've added a sector-colormaps EMAPINFO property if you want to globally override. More details here (search for "sector-colormaps").

 

The r_boomcolormaps console variable still exists, and running MBF (or lower) demos also has the same effect as setting sector-colormaps to Boom.

[Gez]

Wouldn't it make more sense to have the Boom special work like Boom, and introduce a new special for the SMMU behavior? With UDMF, you have access to parameterized specials such as Sector_SetColor.

[printz]

When I add Sector_SetColor, it will act like ZDoom. There's far too much spoken and unspoken demand for this feature. It doesn't contradict anything made so far. The sector-colormaps EMAPINFO feature is useful only for "legacy" works-in-progress which depended on either old behaviour.

 

@Graf Zahl: eh, I'll see how this turns out. I know you take a dim view of colormaps but I'll keep them in, and I'm considering adding support for arbitrary color filter and fog effects per sector to Eternity finally, which should work in addition to the colormap feature.