Wall portals

[Gez]

It's currently not possible, but you can work around that. Look at the polyobjects in the demo map for an example of a trick you can pull.

What you cannot do at the moment, though, is have a setup where you have two different portals over each others.

[Tormentor667]

It's currently not possible, but you can work around that. Look at the polyobjects in the demo map for an example of a trick you can pull.

I took a look at it but it didn't help me unfortunately.

What I have in mind is the following situation: Creating some kind of a house of 3d floors and sectors but only the exterior and with a portal (through the door) you can enter the house. This way mapping could be made so much easier in many situations.

This is a building I have in mind.

[Gez]

Basically the way it is now, you'd have to have the top of the building part of what's behind the portal...

[Graf Zahl]

This setup will indeed be a bit of a problem because portals are either the entire wall or (at least in GZDoom) the middle part, but not the lower part and certainly not part of a wall defined with 3D floors.

In this case you'd probably have to do the roof as a stacked sector, so that the door can be the middle part of the linedef.

[Tormentor667]

(at least in GZDoom) the middle part, but not the lower part

Can you explain this a bit closer? In the screenshot, the door could also be defined as 2-sided middle texture. Can this be a portal with a specific start and a specific end in vertical dimensions?

@Gez - This wouldn't make a benefit for the mapping process, that's the problem in this case.

[ZZYZX]

Can you explain this a bit closer? In the screenshot, the door could also be defined as 2-sided middle texture. Can this be a portal with a specific start and a specific end in vertical dimensions?

No. At least not right now. Would require significant rewrite of both current mirror code and the physics part.

By the way, speaking of mirror clipping in GZDoom, Graf do you know that it doesn't clip away planes from back of the mirror, only walls? Like here: http://i.imgur.com/qaDEv6D.png
In software this is handled natively because of how floor rendering works (no walls drawn = no flat drawn), but not in GZ.

Just for comparison, screenshot with my portals2-visual build and screenshot with generic ZDoom 2.7.1 software renderer.

[Graf Zahl]

So far this was never an issue because of ZDoom's limitations here. Adding a PointOnSide check for subsectors shouldn't be too hard.

Do you have the map for testing?

[ZZYZX]

Same map that I sent you for steep slopes bug. Coordinates 4602, -4445.

[Graf Zahl]

Thanks. I added some checking code.

[Major Cooke]

Well, the visual side of the portals was added.

Key word here, people, VISUAL.

[edward850]

I assume portals also replace the existing mirror drawing? Because there seems to be an issue with it:

Example
It works head on perfectly fine, but it seems to have an issue drawing at that angle.

[Graf Zahl]

Just a few notes:

While the basics here are ok, I see a major efficency problem coming, if this ultra-flexible approach is kept. To quickly check for portals in the vincinity of a given position in a map it is absolutely necessary that the map knows where portals can be.

So, to make this easier I'm going to introduce one important change:

Any line that CAN be a portal needs to be declared as such in the map itself. Enabling, disabling and changing destinations can be done with another ChangePortal special.

That also means we need to be aware of the polyobject problem. Should it be possible to have actual teleporting portals on a polyobject? I'm not convinced yet if it makes sense to allow it. This is one of the cases which on the surface says 'nice to have' but gets really, really ugly if more and more maintenance code needs to be added to properly support them. For example, they immediately throw any efficiency out of the window because it's no longer possible to precalculate such important information as distance of a portal to a given position etc., since their position constantly changes - and it's unpredictable where they can end up.

And please don't say "The existing code can already do this!" Yes, the existing code seems to be able to handle any odd angle at any odd position - but this can get really costly if the entire engine needs to be made portal aware, e.g. when spawning something at an offset from a given location. To handle such stuff there's only one option. Fire a trace from the base location to the offset spot. And if a portal lies in between, offset the position accordingly. But this is something the engine constantly does, and if each and every such calculation needs to run this trace without any chance of shortcutting, it's going to have some impact for sure. But if polyobjects are taken out of this equation we can generate a portal blockmap upon map start, and for each block only store the known portal lines, and if none are there, some distance values in each direction to the nearest portal. That'd allow very quick and efficient detection of the common case where no portal checks is needed. A constantly moving polyobject portal would put some enormous drag on these checks.

So, as I see it, we may need a few levels of portal interactivity:

1. works as a teleporter, but nothing more - it may also let P_RadiusAttack pass, but that's it. These two cases pose no real problem, because it's only two places in the entire code where this is a concern. All one-directional portals would automatically fall into this category. And with some thinking these may even work on polyobjects, because checking the portal blockmap in those two spots is not too bad.

2. interactive dynamic two-direction portals. These can connect at any angle, but must provide a two-way connection. Aside from costly stuff like monster AI (which simply cannot check them in an efficient manner) these should let every object pass through and handle any spawn at an offset. They'd still suffer from some problems because due to lack of a fixed displacement they'd make it very hard to be considered by monster AI and the sound code.

3. statically linked portals like in Eternity. These cannot change their destination, they need to connect with another portal with the same orientation and if there's two paths from one section of a map to another, they all need to have the same offset. Such portals would be fully traversable by monster AI because offset calculations would just mean a simple addition of a precalculated value, they also could overlap on the automap and handle sound placement realistically.

Last but not least: The old implementation allowed teleporting portals on one-sided walls. I'm still not sold on this, as it may cause some really bad problems with predictability of how the system behaves and what actually can block movement through such a line.


Bottom line: We need some decisions here how to proceed. My main concern is clearly NOT to have something that allows crazy portals to connect from anywhere to everywhere but something that handles the most desirable cases best - and the most important case for me is still to replicate what Eternity has, followed by restricting two-directional interactive portals to the point that they remain manageable. That inevitably means to block some features for them.

That means:

The first steps would be to make P_TryMove and P_RadiusAttack work, and these need to be solved in a universal fashion anyway.
But after that, focus on the statically linked portals, and just handle the other portal types if it's easy to add to the needed code. I think it will sort itself out eventually if we approach it like that. If some functionality is easy to implement for the other types, it'll be done, but we'd find out immediately where the limits are, so we wouldn't lose anything.

[Graf Zahl]

I assume portals also replace the existing mirror drawing? Because there seems to be an issue with it:

Example
It works head on perfectly fine, but it seems to have an issue drawing at that angle.

I even had to add a check for this case to GZDoom because it also failed, but I fully know that it's very easy to still break the whole setup. I guess you have to accept that it's not possible to find ALL cases where a line needs to be discarded.

[Graf Zahl]

I just want to note that I disabled the toggling of portals via SetLineSpecial. I consider this method very poor, since portal activation is a lot more involved than changing a line's special.
So this will first need some refactoring of how the data is stored - then some thought about what portals should be able to do and how to define it - and THEN, once the basics are working - it's the right time to implement this - WITHOUT piggybacking on a common function.

I also removed the Line_SetVisualPortal type, because that will ultimately not be needed. Portal types should be settable with flags, not consume valuable slots in the special table.

So while this will initially put in some restrictions, the current feature set is guaranteed to remain.

[hfc2x]

Holy crap, this is awesome!

By the way, I wanted to add the info to the wiki, but I don't understand the 3rd parameter. What does PlaneAnchor do?