Wall portals

[Major Cooke]

I think Graf's leaving that to Randi though. At least, I would imagine that might be the case here.

[Graf Zahl]

Precisely. I won't sign off such a massive change to a piece of code I'm not familiar with.

[Blzut3]

Left a bunch of comments on the pull request. The code looks pretty good to me (the diff looks more invasive than it actually is). However crashing with Urban Brawl is a blocker.

[FireSeraphim]

It would be a real crying shame if this isn't accepted. I was looking forward to seeing this implemented in (G)ZDoom.
@ZZYZX: If you're still here can you please fix the urban brawl problem Blzut3 mentioned so that this can be implemented?

[Major Cooke]

First off, patience.
Second, just because Blzut3 can merge it doesn't mean he will.
Third, the only thing you'll be seeing is the visual code, NOT actual portals.

[Blzut3]

For those who aren't following the GitHub ticket. The crashes were fixed. The issue now is that some maps with mirrors (like one of the Urban Brawl maps) are suffering major performance regressions to the point where smoothly playable maps are unplayable by anyone's definition.

[Jaxxoon R]

Damn, I'd been looking forward to this. It'd make things like trams/airships/windows/buildings a hell of a lot easier to pull off.

[Major Cooke]

Even with the visual portion, the only thing you could achieve is just looking through it, not things like shooting through it with monsters shooting back.

[Jaxxoon R]

Third, the only thing you'll be seeing is the visual code, NOT actual portals.

I know that. It's not 5 posts away.

[boris]

Seeing that this feature uses line specials. Wouldn't it make sense to also have it as a native UDMF implementation?

[Gez]

Mirrors and horizons are also line specials with nobody bothering to make them UDMF properties, so I don't see a problem here.

[hfc2x]

Even with the visual portion, the only thing you could achieve is just looking through it, not things like shooting through it with monsters shooting back.

I believe just being able to see through them would be enough to many users (and I'm one of those).

[Graf Zahl]

I just had a look at this stuff. Generally ok, but there's one problem: On portal lines, upper and lower textures are ignored, the portal always spans the entire sector height, no matter what else is there.

In contrast, Eternity's linked line portals actually DO draw their upper and lower textures, so something should be done here. It'd be a pity if this couldn't be developed into a common feature because of such an issue.

I'm going to do some more tests to see what precisely Eternity is doing with line portals but for compatibility reasons this should be identical.

Also: Why waste two line specials here? One should be enough with the third parameter specifying what type of portal is being used. If we really go as far as supporting Eternity's semantics as well, that'd introduce a third type here.

[ZZYZX]

Drawing upper and lower textures comes from earlier mirror handling... I'll try to fix that later, but not sure how much later.
Also I did experiment with supporting Eternity maps, simple xlat worked. I don't quite understand about third type.
The reason why I'm using single special is primarily historical, as before I didn't use separate portal substructure in linedefs and instead compared special to Line_SetPortal and Line_SetVisualPortal.
Although I don't see any problem with keeping them separate, I could probably merge these in one special and make pass flags which would define what passes through (but it'd make it really hard to define portals without proper article in the wiki or without GZDB config).

[ibm5155]

The legend is back !!!