[Added] Wall portals

[Gez]

Good work, ZZYZX and Graf Zahl! Thank you for bringing ZDoom closer to Eternity...

And Printz for bringing Eternity closer to ZDoom.

[NeuralStunner]

Right. Kudos to everyone working together to make this feature work consistently between ports. (Instead of engaging in petty competition. Though I suppose a tiny bit of competition isn't unhealthy.) This is really good news for projects like Hacx 2.0!

[Trusty McLegit]

I think that aside from polyportals the feature is complete now. I don't expect it to be completely free of bugs but all the changes to the engine are done now.

So are does that mean that linked portals are going to be in an official build soon? And will there be documentation or are we just going to have to figure if out ourselves?

[GooberMan]

There's a bug in this WAD. Portal type 1 (visual + simple teleporter), 180 degrees difference between entrance and exit. Run full pelt at the portal from the start position. You'll get stuck at the transition. Other speeds are just fine.

I was trying to set it as interactive, but every time it complains about z-offsetting and reverts its behavior to visual + simple. No idea why.

[Graf Zahl]

The inteactive features - which have nothing to do with player movement do not work with z-offsetting due to the strange way Doom treats z.
I'll have a closer look tomorrow why the player gets stuck (and why for one frame the player sprite can be visible.)

[NeuralStunner]

Man, this is progressing fast.

Even with wall portals, I'm really looking forward to the fully interactive floor/ceiling portals. It'll be nice to be able to cleanly split a map into floors. (It'll look especially nice on the automap.)

I forget whether this was mentioned already: Will sounds be handled across portals? If so, what happens if you're close enough to hear a sound both through normal space and through a portal? The "stupid simple" answer seems to be "play from whichever point is closer", but this could get weird once things start to move around.

[Graf Zahl]

I haven't done anything with sounds yet but the basics are already in place, but only for linked portals because sounds are one of the things that depend on fixed offsets.

It's an absolutely non-trivial task to make sounds, sight and monster attacks propagate through other portals and I'm going to leave that to somebody else.

Sector portals are already working in the playsim. The main roadblock here is the software renderer - in GL they already work.

[Major Cooke]

sounds, sight and monster attacks

And quakes. They can cause damage out of sight too, last I checked.

[Graf Zahl]

Those, too. I wouldn't say it's entirely impossible, but doing offset calculations through some arbitrary portal is a very expensive operation.
The big advantage of the linked portals is that no matter where in the map two objects are, the world distance can be trivially calculated.

[Major Cooke]

And speaking of other non-trivial things...
I don't remember, were seeker missiles done already?

[Graf Zahl]

I took care of most coordinate related things in January already when I refactored the access to an actor's position through a set of functions. That, of course includes seeker missiles.

But again: They also require a fixed offset. If you look closely you'll find that if the player fires a seeker missile at a target behind a non-linked portal, the tracer is not even set because otherwise it'd just fly randomly off into the wild.

One other limitation: There's no way P_BlockmapSearch is going to work through portals. This either has to be replaced or completely redesigned, so self-acquiring seeker missiles cannot acquire new targets behind ANY portal.

[Major Cooke]

Yeah the auto-acquiring one is what I was concerned about.

[Graf Zahl]

There's a bug in this WAD. Portal type 1 (visual + simple teleporter), 180 degrees difference between entrance and exit. Run full pelt at the portal from the start position. You'll get stuck at the transition. Other speeds are just fine.

I was trying to set it as interactive, but every time it complains about z-offsetting and reverts its behavior to visual + simple. No idea why.

It's the same as this one:

viewtopic.php?f=2&t=40301

When being teleported in a multi-P_Trymove movement, if the first one alters the position, this gets adjusted for the second move - but the actual movement vector does not.

In retrospect I even remember some old Boom map that suffered from this problem but I never found out why.

[printz]

I suppose ZDoom is already protected by the P_TryMove overstepping problem? That is, velocities greater than the bounding box size are checked against and fragmented into smaller pieces to prevent passing through walls. Naturally this isn't allowed in Eternity, which means I have a potentially huge trouble with line portals where anything moving faster than its size (most monster projectiles on -fast) has a great chance to miss line portals entirely and "disappear". I temporarily prevented this by checking that the thing must enter the sector behind the wall portal to teleport, but this would prevent me from using 1-sided lines as portals (such as polyobject portals; internally they're changed on the fly to 2-sided pointing backwards to the same sector as in front), so I had to revert to the P_TryMove and spechit model while also making it more sensitive than usual spechits (in fact it was already more sensitive already, I just fixed other errors).

I have a function that traces a line and detects any line portals along the way, but I'm reluctant to call such a tracer for every single thing movement. But it may solve this problem...

[Graf Zahl]

I suppose ZDoom is already protected by the P_TryMove overstepping problem? That is, velocities greater than the bounding box size are checked against and fragmented into smaller pieces to prevent passing through walls. Naturally this isn't allowed in Eternity, which means I have a potentially huge trouble with line portals where anything moving faster than its size (most monster projectiles on -fast) has a great chance to miss line portals entirely and "disappear". I

Yes, ZDoom splits up the move into as many steps as necessary and this is something I heavily depended on when adding the checks to P_TryMove (because as you said yourself, otherwise it'd be a lot more complicated.) But why is this out of the question for Eternity? At worst you have to duplicate P_XYMovement and call the old version if compatibility is needed, but even then you should be able to refactor large parts of it into subfunctions.

Of course you have to be careful with wallrunning then because it depends on the original move-splitting code to be buggy.

I have a function that traces a line and detects any line portals along the way, but I'm reluctant to call such a tracer for every single thing movement. But it may solve this problem...

Understandable. Which is why I added a separate line-portal-only blockmap which I use when calculating offsets through portals. Since all the regular lines are excluded and a few flags are being used that allow some early outs, this is a lot faster. But I didn't use it in P_TryMove because it's not necessary in ZDoom.