Things about Doom you just found out

[kuchitsu]

Do we know any non-demonstration wads that actually do this tranmap stuff?

[esselfortium]

kuchitsu said:

Do we know any non-demonstration wads that actually do this tranmap stuff?

I'm not sure if there are any released ones that use them for much more than basic translucency, unfortunately!

I had some cool effects set up in a mapset I was helping out with years ago (animated ceiling-fan flats that you can look through and see the duct, floor grates that you could see solid-looking walls beneath, forcefields that turned everything a vivid cool blue or fiery red, among other things) but it's been on the backburner for a while.

[scifista42]

kuchitsu said:

Do we know any non-demonstration wads that actually do this tranmap stuff?

Vela Pax?

[Da Werecat]

I guess the obscurity of the feature contributes to this cranky attitude towards it. It's pretty much only used for things that don't require color tables. Other applications can be dismissed as impractical or gimmicky. Mainly because the most popular source port can't fully support them, yet it supports everything else, which makes it a one stop shop for the majority of players.

And so it goes. And it's no one's fault.

[Graf Zahl]

Da Werecat said:

Mainly because the most popular source port can't fully support them, yet it supports everything else, which makes it a one stop shop for the majority of players.

Here's the consensus that was reached last time this came up for ZDoom:

randi said:

Graf Zahl said:

Even that nonwithstanding I believe that this feature is a nasty trap just waiting to block potential improvements to the renderer. It is so purely and utterly locked to 8 bit graphics that problems are inevitable.

This is exactly why I never supported it. The algorithm is dead simple, but it's not forward-thinking in any way.

In clear English that means that TRANMAP maneuvers the renderer into a dead end. This feature shares a lot with demo compatibility: Its demands on the underlying system are so strict that it becomes impossible to change the fundamentals of the underlying system. (Oh, obviously the ZDoom devs do not like dead ends.)

And here's the link to the thread, for your reading fun:

http://forum.zdoom.org/viewtopic.php?f=18&t=18900&hilit=tranmap

I'd have no problems implementing a TRANMAP analyzer that maps it to sane features, but implementing the lump itself: No chance.


And one word about ZDoom's popularity. If that irks someone, ask yourselves, what ZDoom has done right over the years which other ports did not? Situations like the current one always develop because those who think forward will win, while those held back by sticking to the old will at most move sideways and ultimately be left behind.

ZDoom dared multiple times to break some established rules of how Doom works, even if sometimes it was just behind-the scenes stuff like the new inventory system in 2005 or the recent floating point rewrite whose rewards are yet to come. And then nearly each time capitalized on the possibilities these changes brought.

I find it a bit surprising that no other port has really dared over the years to break the Holy Conventions of True Dooming, they all target the same group of hardcore Doomers, leaving the huge rest of the community to one single (or three, if you count the active child ports) supplier. EDGE would have been the only true contender here, but during the time when ZDoom's popularity was on the rise it was mostly stagnant, so it naturally lost out.

[esselfortium]

Graf Zahl said:

And one word about ZDoom's popularity. If that irks someone, ask yourselves, what ZDoom has done right over the years which other ports did not? Situations like the current one always develop because those who think forward will win, while those held back by sticking to the old will at most move sideways and ultimately be left behind.

ZDoom's popularity doesn't irk me. It's a perfectly fine port. What irks me is when mappers are discouraged from using features that ZDoom chooses not to support, as if there's no reason to target maps to any other port but ZDoom.

[VGamingJunkie]

If they just want effects behind transparent textures like grayscale, additive blending, inverted colors, etc, couldn't that just be implemented individually to a line via OpenGL effects? I'm pretty sure additive blending is already a thing, in fact. I don't see why a TRANMAP would even be necessary in a hardware renderer.

[Da Werecat]

esselfortium said:

ZDoom's popularity doesn't irk me. It's a perfectly fine port. What irks me is when mappers are discouraged from using features that ZDoom chooses not to support, as if there's no reason to target maps to any other port but ZDoom.

I guess you need to educate the masses on how innovative and forward-thinking ZDoom is from time to time, even if no one is arguing with you.

MetroidJunkie said:

If they just want effects behind transparent textures like grayscale, additive blending, inverted colors, etc, couldn't that just be implemented individually to a line via OpenGL effects?

More like combining multiple effects on one surface. For example, a glass texture with solid parts. Which should be possible in OpenGL if you have a PNG texture with certain properties, but then ZDoom won't be able to display it correctly.

And if you want the translucent part to be additive - oops. Guess you'll have to rely on clumsy solutions like two linedefs that are very close to each other.

[dew]

Graf Zahl said:

This feature shares a lot with demo compatibility: Its demands on the underlying system are so strict that it becomes impossible to change the fundamentals of the underlying system. (Oh, obviously the ZDoom devs do not like dead ends.)

"Speedrunning is a dead end." - Graf Zahl, 2016

[baja blast rd.]

Is there a (G)ZDoom compat option that makes the blockmap stuff and movement analogous to prBoom+'s? That would be great.

Even just the mouse sensitivity! In pr/glBoom+, my horizontal mouse sensitivity is 14 and accel is 3, and in Windows, my mouse sensitivity is at the 7th notch with "enable pointer precision" off. It'd be cool if someone could convert this to ZDoom settings, somehow.

[vadrig4r]

rdwpa said:

Is there a (G)ZDoom compat option that makes the blockmap stuff and movement analogous to prBoom+'s? That would be great.

Even just the mouse sensitivity! In pr/glBoom+, my horizontal mouse sensitivity is 14 and accel is 3, and in Windows, my mouse sensitivity is at the 7th notch with "enable pointer precision" off. It'd be cool if someone could convert this to ZDoom settings, somehow.

Why 7th notch? Assuming the notches are labelled 1-11, the 6th notch is 1:1. 7 is a multiplier of 1.5 causing Windows to interpolate your input. Is your mouse really low DPI for you screen resolution? Othewise leaving it 6 and adjusting sensitivity per game can avoid the unnecessary lack of precision it introduces and pixel skipping nonsense with the 'wrong' DPI/sensitivity/screen resolution setup. For PrBoom+ it doesn't matter as your OS mouse sensitivity isn't considered (in the latest version at least) but for other games it might.

[Graf Zahl]

dew said:

"Speedrunning is a dead end." - Graf Zahl, 2016

Speedrunners need all the glitches, so a robust implementation is not suitable for then. So why bother? They are a niche and they prefer other ports.

rdwpa said:

Is there a (G)ZDoom compat option that makes the blockmap stuff and movement analogous to prBoom+'s? That would be great.

There is an option for hitscan attacks ignoring anything that doesn't have the center in the current block.

There's also a wallrunning option but it doesn't work that well and trying to play and ZDoom mod with it that takes the normal behavior for granted you might not enjoy the results.

dew said:

Even just the mouse sensitivity! In pr/glBoom+, my horizontal mouse sensitivity is 14 and accel is 3, and in Windows, my mouse sensitivity is at the 7th notch with "enable pointer precision" off. It'd be cool if someone could convert this to ZDoom settings, somehow.

If I am not mistaken, PrBoom uses the GUI mouse code through SDL, while ZDoom uses DirectInput, i.e. something far less processed. Obviously that's not trivially translateable.

[baja blast rd.]

vadrig4r said:

Why 7th notch? Assuming the notches are labelled 1-11, the 6th notch is 1:1. 7 is a multiplier of 1.5 causing Windows to interpolate your input. Is your mouse really low DPI for you screen resolution? Othewise leaving it 6 and adjusting sensitivity per game can avoid the unnecessary lack of precision it introduces and pixel skipping nonsense with the 'wrong' DPI/sensitivity/screen resolution setup. For PrBoom+ it doesn't matter as your OS mouse sensitivity isn't considered (in the latest version at least) but for other games it might.

6th is really slow for me for general computer usage. My wrist gets fatigued. I don't mind switching back and forth whenever I play things though.

I do seem to have quite a bit more control in ZDoom with the 6th, however. I still have to work out how to translate 'overall sensitivity' and 'turning speed' into something that feels good, however.

[vadrig4r]

rdwpa said:

6th is really slow for me for general computer usage. My wrist gets fatigued. I don't mind switching back and forth whenever I play things though.

I do seem to have quite a bit more control in ZDoom with the 6th, however. I still have to work out how to translate 'overall sensitivity' and 'turning speed' into something that feels good, however.

Yeah, that makes sense then. There's a great website for translating sensitivities between games here, but unfortunately no Doom source ports yet. If you weren't using accel then the straightforward way would be to measure how far you have to move the mouse for a 360° turn in your preferred port then replicate that measurement in another. Accel is a bit more involved and will probably take a mix of finding out the curves/equations each port uses and calculating a compromise.

You could get quite close by disabling accel and measuring distance/360° in port A, replicating that in port B then adding accel into the mix and tweaking to suit.

[Da Werecat]

One thing I'm not sure I understand is why ZDoom isn't a true color engine yet. Its philosophy is very palette-unfriendly. And not just because obsolete blah blah sticking to the old ways blah blah blah, but because the benefits of easily mixing different types of fog with translucent surfaces on top of colored lighting are only really visible when you don't have to shoehorn the result into 256 colors.

The answer is probably in the fact that GZDoom exists. Still, ZDoom is being maintained as a separate, deeply conflicted engine. One leg in the future, one leg in the past.

[Arctangent]

HUD elements can be truecolor, actually.

I imagine the reason why it isn't fully true color is because palette translations are a concern. And, well, there's no real need to go out of the way and put effort into doing more for it, since GZDoom is a thing, yes.

[Graf Zahl]

Why isn't ZDoom true color?

I'd say the main reason is that there's only one person willing to work on the rendering code. Blame all the Build code in there which to the uninitiated is virtually incomprehensible.

ZDoom is being maintained as a separate, deeply conflicted engine. One leg in the future, one leg in the past.

I'd agree with that. Which is the reason GZDoom exists. As for why they are still separate: This way I keep control over it, that's really all.

[Maes]

There have been several attempts at making truecolor software renderers, and there are several approaches (e.g. extended colormaps, multiple palettes, YUV colorspaces etc.) but response has been lukewarm, mostly because the ports implementing them were niche and idiosyncratic, and because none of them allowed using hicolor or truecolor resources, as well.

[Da Werecat]

At least now it's clear that this "palette tricks shaming" doesn't come from an overwhelming love for the whole concept of using a palette.

[Graf Zahl]

Maes said:

There have been several attempts at making truecolor software renderers, and there are several approaches (e.g. extended colormaps, multiple palettes, YUV colorspaces etc.) but response has been lukewarm, mostly because the ports implementing them were niche and idiosyncratic, and because none of them allowed using hicolor or truecolor resources, as well.

In the end I think the main reason why there isn't much going on in that field is just that a truecolor software renderer would not offer much of a benefit.

It got many of the disadvantages of software rendering in general, some, like performance even amplified, it also shares some of the disadvantages of hardware renderers (like loss of palette-based features) and with current high resolution screens it'll just lose in terms of performance to both hardware rendering and paletted software rendering.

On 1920x1080 any well implemented hardware renderer will run circles around a software renderer performance wise.

[Maes]

Well, palette effects can be largely preserved (and even enhanced) with the use of a "paletted truecolor" renderer with extended and precolored colormaps, such as the one I implemented in Mocha Doom, without the need to do framebuffer/colorspace processing (which was, OTOH, the approach used by _bruce_'s Chocolate Doom-based truecolor port). But as I said, the problem is that all resources remain 8-bit. You can assign different palettes/colormaps to different e.g. sprites or walls, but that's really as far as it will go.

Supporting true color resources would need breaking away from that system, and then yeah, the amount of framebuffer post-processing to perform would be a performance killer. That'd be something much better suited to do with a hardware renderer.

The only appeal "supercolor" software renderers have, is a nostalgia/"super-cool but removed feature" one: Doom at least initially was designed to have a 32K color mode, as suggested by the elusive COLORS15 and COLORS12 lumps in some alphas, and the mysterious "R" mode in the v0.4 Alpha. Now, that's really something I'd like to ask Romero about.

[esselfortium]

esselfortium said:

I'm not sure if there are any released ones that use them for much more than basic translucency, unfortunately!

I had some cool effects set up in a mapset I was helping out with years ago (animated ceiling-fan flats that you can look through and see the duct, floor grates that you could see solid-looking walls beneath, forcefields that turned everything a vivid cool blue or fiery red, among other things) but it's been on the backburner for a while.

Got some screenshots of these tricks last night:

Spoiler

(Screenshots all taken in Eternity, but they work in PrBoom+ in 8-bit software mode as well.)

[Graf Zahl]

... nothing of which can't also be achieved with portals - which would automatically give you a far wider audience for the maps. (In other words: By using them you trade the entire ZDoom user base for the much smaller one that uses PrBoom (which would essentially be the only port to gain from it.) - and then only that part of its user base that chooses software rendering over OpenGL.

Anyway, could you send me those TRANMAPS and some textures to use them on?
They are definitely good material to write a TRANMAP analyzer which can transform them into true alpha maps.

[esselfortium]

The forcefields can't be done with portals or other preexisting advanced port effects, but yes, the other depicted stuff generally can. I'll have to dig up the wads for these and see if I can get a simple demo put together or something.

[Graf Zahl]

esselfortium said:

The forcefields can't be done with portals or other preexisting advanced port effects,

Right, but if I can deconstruct the tranmaps a generic solution should be possible.

[Da Werecat]

Graf Zahl said:

... nothing of which can't also be achieved with portals - which would automatically give you a far wider audience for the maps.

It works both ways. Use portals, and the speedrunning crowd is excluded. Which audience is more important is debatable.

I'd also say that it should be easier for the "non-vocal majority" to start trying source ports other than GZDoom than for speedrunners to abandon their recording standarts, but Brutal Doom is probably a deal breaker here.

This is a problem I won't shut up about. When you're using features beyond the most mainstream set, you're breaking compatibility with something. The only solution I can think of is to have multiple versions of the same map in the wad, each fine-tuned for a specific port. Maintaining such a wad can't be easy, but at least it should work, as long as most target ports have mapinfo-like functionality.

[Graf Zahl]

Da Werecat said:

It works both ways. Use portals, and the speedrunning crowd is excluded. Which audience is more important is debatable.

I think with a mod that puts visuals front and center these features should be geared towards the ports that have a larger target audience which may appreciate the visuals

I have nothing against speedrunning, but considering how these people play, some visual eye candy is the least they might deem important, as long as playing the map is still possible. And that's definitely doable, even with portals, provided they are visual only. PrBoom would simply ignore them, not abort.

[VGamingJunkie]

I don't understand speed runners that have to abuse glitches, anyway, isn't that basically the same as cheating? Seriously, I could use IDCLIP and just make a beeline for the exit, that's not that much different in my opinion since glitches weren't intended by the developer. If you want to speed run, do so legitimately. See how fast you are when you can't exploit bugs.

[kb1]

@esselfortium: Nice shots!

Graf Zahl said:

... (In other words: By using them you trade the entire ZDoom user base for the much smaller one that uses PrBoom (which would essentially be the only port to gain from it.)

Got any numbers to back up those statements?

[Graf Zahl]

All I can compare is the GZDoom download numbers with PrBoom's. GZDoom had > 100000 downloads in the last 12 months, and that's not even counting Linux users who compile the code themselves and users of the devbuilds.

Now you got to add ZDoom users and Zandronum users who use that port for single play, too.

Last time I checked, PrBoom+ had 300 downloads weekly. GZDoom's official builds had 7000 downloads in the last 10 days.