notransl.deh

[vdgg]

Just a follow-up to an intereting discussion I found. Maybe I am over-interpreting, but one of the prominent speedrunners was considering invalidating a bunch of my demos :) I would never have thought about that, it was IMO really innocent, and even @myk approved that. Anyway the timeline is:

 

April 2010. I record par-lutz demopack. I set translucency off in PrBoom+ (options -> general -> enable translucency: no). The reason: I used to hate translucent powerups such as a soulsphere and fireballs, especially mancubus fireballs. They felt so odd to me, even though I had played Boom-complatible WADs before. But this setting made also translucent walls become solid (cannot see through), so e.g. in E1M3 and E1M5 I was at a big disadvantage.

 

Still April 2010, I got the .deh thanks to this post

 

July 2010. Vrack 1 Max, vr1-1604.lmp , probably my first demo with translucency on in settings, but with the .deh used.

 

June 2014. 1994 tune-up MAP09 UV Max, 9409-901.lmp, my last demo recorded in such a way. My next cl9 demo would be gd MAP28 NM100, and I think by that time I realized these translucent fireballs and powerups did not bother me anymore.

 

This is probably boring to read, but I wanted to make it clear, I was also curious myself for how long I used it.

[4shockblast]

Thanks for the info. I definitely wasn't planning on retroactively invalidating any of your demos. :) It seems to me like this offers no significant advantage, although from what I understood, messing with translucency through Dehacked in general could offer some advantage. From that perspective, it's a tricky situation, since we don't want to necessarily encourage changing translucency because of the potential benefits, but I'm not 100% on the best way to handle it.

 

If it were up to me, I would say any Dehacked that doesn't increase translucency for any elements that Boom already has translucency for is fine, as I can't see how decreasing translucency would provide any advantage whatsoever. In that case, a DEH like this would be acceptable for recording, although probably we would want to standardize which extra files specifically are allowed for recording, so that people don't make their own and possibly mess things up. On the flipside, any DEH that increases translucency should never be allowed IMO, since that would have a large advantage for certain cases.

[GoneAway]

2 hours ago, 4shockblast said:

I can't see how decreasing translucency would provide any advantage whatsoever

Anything that someone would do to change the game DOES provide an advantage in some form, otherwise they wouldn't do it. Let's put the "does it provide advantage" discussion on the shelf because everything provides an advantage in some way, to someone. The rules were different in the past (and / or didn't even exist) so this kind of case is something that I would just as well ignore. If you feel like you did get some relevant advantage that would be unfair to present competitors, we could add a note on some of the demos, but probably it doesn't matter a whole lot. Of course, anything like this shouldn't be used anymore. Like shock said, the idea of having an official list of allowed patches has been thrown around recently, but that's also a separate discussion to have.

[Hitherto]

Personally I consider Boom's translucency of fireballs as very bad design flaw, which should be fixed (i.e. disabled) asap without much side effects if possible. So, thanks for deh.

 

About legitimacy I think this deh provides much much less advantage then, say, "Recorded with pain palette disabled" demos which currently considered as legitimate records at DSDA.

Edited September 18, 2021 by Hitherto

[ChopBlock223]

Could wall translucency be separated from sprite translucency, or are they joined at the hip?

[dew]

2 hours ago, Hitherto said:

About legitimacy I think this deh provides much much less advantage then, say, "Recorded with pain palette disabled" demos which currently considered as legitimate records at DSDA. 

Reducing pain palette should definitely not be used, but there are a couple of instances on the archive that made it through one way or another. They should be marked with an info label and no new ones should be uploaded the same way, however if they're not some superhuman feats they can probably be grandfathered in, similarly to the old cl9 maxes on scythe map26.

[vdgg]

8 hours ago, ChopBlock223 said:

Could wall translucency be separated from sprite translucency, or are they joined at the hip?

 

In the port, no, but we're discussing the dehacked file that disables translucency for powerups and projectiles. Not sure if by 'sprites' you mean something else...

[Shepardus]

Considering how the game allows you to turn translucency on/off and adjust the translucency filter percentage in the settings (dsda-doom's removed the on/off setting, but setting the percentage to 100 is effectively the same as turning it off), I don't think it's right to frame the question of notransl.deh as whether opaque projectiles provide an advantage. Rather, it's more like whether projectile translucency should be tied to environmental (wall) translucency; in a map with no translucent walls, using notransl.deh would be the same as disabling translucency in the settings.

 

I find it strange from a gameplay perspective that projectile and wall translucency are tied together (you can have opaque projectiles if you're okay with translucent walls also rendering opaque, what kind of tradeoff is that?), but even stranger is that this percentage is controlled by the player in the first place, rather than by the mapper. I imagine one could create some nifty effects with translucency and a custom TRANMAP, but it goes out the window when you allow the player to set the translucency percentage to whatever, not to mention the OpenGL renderer which I'm not sure even uses TRANMAP...

 

Speaking of the OpenGL renderer, until recently the OpenGL renderer didn't render translucency on projectiles, so using the OpenGL renderer was another way to get opaque projectiles with translucent walls, and it didn't require loading an additional .deh file.

 

Long story short, translucency is a mess, and I think a big part of the problem is that Boom left it as a player setting so there isn't actually a single "canonical" appearance. Until that's taken care of (enforce the default filter percentage of 66 in dsda-doom's strict mode?), discussing whether something like notransl.deh provides a meaningful advantage is moot.

Edited September 19, 2021 by Shepardus

[Da Werecat]

1 hour ago, Shepardus said:

I find it strange from a gameplay perspective that projectile and wall translucency are tied together (you can have opaque projectiles if you're okay with translucent walls also rendering opaque, what kind of tradeoff is that?), but even stranger is that this percentage is controlled by the player in the first place, rather than by the mapper. I imagine one could create some nifty effects with translucency and a custom TRANMAP, but it goes out the window when you allow the player to set the translucency percentage to whatever, not to mention the OpenGL renderer which I'm not sure even uses TRANMAP...

 

That's just how Doom ports work, unfortunately. You can never fully control something as a mod author. I doubt there's an easy way to fix this after so many years of accumulating features.

Edited September 19, 2021 by Da Werecat

[Hitherto]

 

On 9/18/2021 at 5:03 PM, vdgg said:

Still April 2010, I got the .deh thanks to this post

 

Since this link is out of sync now:

 

https://www.doomworld.com/applications/core/interface/file/attachment.php?id=1761