Wall portals

[Graf Zahl]

What still needs to be done for the first phase is proper position checking when stepping into a non-static portal with a floor height difference.

... and now it's done. And it only confirmed all my reservations about these arbitrarily linkable portals. They'll never work beyond basic position checking so I think they are done now, except for some stuff like hitscans and explosions.


To summarize the current state:

- players and other actors can pass through any passable portals, both of the line and sector plane type.
- standard position checking functions have all been made to work with static portals plus some special handling for other types in P_TryMove/P_CheckPosition.
- interpolation for the camera is fully working.
- actor movement is only interpolated through static portals - but it remains to be seen if what is there is good enough for the renderer. For other types of portals interpolation is reset, because keeping track of this would involve too much mess. (Because movement tracking is not fine-grained enough. Just have a look at the code for the camera. We'd have to do something similar for all actors which would be complete overkill.)
- offsetted spawns can reach through static and interactive portals. Teleporter portals are deliberately excluded, that was one of the reason they exist in the first place - to reduce costly calculations where they are not deemed necessary.

[printz]

Did you fix or ever have problems with sprites getting cut off at the edge of portals?

I was trying to put angled portals into Eternity but ran into the challenge that just changing position and angle isn't enough: I also need to change the axis.

What about polyobject collision detection when a thing from behind a polyobject portal is partially outside and hits a wall? Will it stop the polyobject or cause the thing to be dragged back until it potentially hits something, anywhere? Or will it just get stuck?

Graf Zahl: I commented in a previous commit; check github. Or do you not have an account there? There's a x/y typo. I'll show it to you when I have time.

[Graf Zahl]

Did you fix or ever have problems with sprites getting cut off at the edge of portals?

So far I haven't done anything on the rendering code. No idea how ZDoom deals with it, but in GZDoom I definitely need to do something about it, but that's for later.

I was trying to put angled portals into Eternity but ran into the challenge that just changing position and angle isn't enough: I also need to change the axis.

What do you mean by 'axis'?
That said, checking these things is horrible. Not only is all convenience from having fixed offsets between positions thrown out of the window, far worse is how this clashes with Doom's rectangular collision boxes for actors. As a result I had to restrict the checks quite severely so that they don't mess up. It seems to work as long as nothing is blocking the portals, but if something does, there is no chance of smooth movement.
I've never checked, but how does Eternity handle line portals that wrap around (i.e. where the general group offset does not apply?) My main concern here is the handling of BlockingMobj which is the least I'd like to get to work, even with such portals.

What about polyobject collision detection when a thing from behind a polyobject portal is partially outside and hits a wall? Will it stop the polyobject or cause the thing to be dragged back until it potentially hits something, anywhere? Or will it just get stuck?

I have neither checked nor changed about that yet. The polyobject/portal code is quite insufficient at the moment. If a polyportal touches an actor it is just pushed instead of being teleported. And the testmap you posted on Doomworld today causes the engine to hang on the portal transition. (Nice map, btw, very good for stress-testing. I already found a few problems with it that need to get addressed.)

Graf Zahl: I commented in a previous commit; check github. Or do you not have an account there? There's a x/y typo. I'll show it to you when I have time.

I saw the comment, but couldn't find the typo you were referring to. Next time better report a bug at the forum and copy the incorrect stuff into a code tag.

[printz]

Did you fix or ever have problems with sprites getting cut off at the edge of portals?

So far I haven't done anything on the rendering code. No idea how ZDoom deals with it, but in GZDoom I definitely need to do something about it, but that's for later.

Eternity just redraws the sprite on the other side, but only for sector portals (I thought that line portals don't have this problem but they kinda do).

I was trying to put angled portals into Eternity but ran into the challenge that just changing position and angle isn't enough: I also need to change the axis.

What do you mean by 'axis'?

When I walk forward, the camera needs to move in another direction. I'll probably use sin and cos to solve this.

I've never checked, but how does Eternity handle line portals that wrap around (i.e. where the general group offset does not apply?)

Currently the function that looks up the blockmap here and beyond portals uses the rigid group ID and link offset (displacements) logic, so it will miss wrap-around portals. I hope I can improve this.

And the testmap you posted on Doomworld today causes the engine to hang on the portal transition.

You mean ZDoom, right?

Graf Zahl: I commented in a previous commit; check github. Or do you not have an account there? There's a x/y typo. I'll show it to you when I have time.

I saw the comment, but couldn't find the typo you were referring to. Next time better report a bug at the forum and copy the incorrect stuff into a code tag.

Posted in Bugs.

[Graf Zahl]

Eternity just redraws the sprite on the other side, but only for sector portals (I thought that line portals don't have this problem but they kinda do).

I haven't done thorough checks with the software renderer yet. In GZDoom a sprite standing in front of such a portal is cut off, one that's standing behind is fully drawn but can be glitchy because only the part visible in the actual portal gets drawn. This will definitely need to be addressed but I've yet to come up with something that's not too slow.
For sector portals it's easier. I've got to change how the stencil is drawn but splitting the sprite here is relatively simple because it's just a height check.

When I walk forward, the camera needs to move in another direction. I'll probably use sin and cos to solve this.

Is this only for the chasecam or also for a regular view? The regular view wasn't a big issue and already working in the submission we got (aside from the interpolation stuff which turned into a story of its own, have fun looking at the code in r_utility.cpp... ) but the chasecam will definitely be tricky when the time comes to adjust it.

Currently the function that looks up the blockmap here and beyond portals uses the rigid group ID and link offset (displacements) logic, so it will miss wrap-around portals. I hope I can improve this.

So we are having the same problem. I thought so...

And the testmap you posted on Doomworld today causes the engine to hang on the portal transition.

You mean ZDoom, right?

I tested with GZDoom, but yes. That particular case (static portals with offset on a polyobject) is not handled so far.

[Major Cooke]

Wait, some of the Sector_SetPortal stuff is development branch only right now, right?

[Graf Zahl]

Yes. But only type 6, i.e. interactive portals.

[Major Cooke]

Speaking of this... I somehow get the feeling that A_CheckProximity is also going to need something similar. Maybe?

[Graf Zahl]

No. A_CheckProximity uses a TThinkerIterator and then uses the portal-aware AActor::AproxDistance method to calculate the distance. It already handles everything that's needed.
Guess why I went through that refactoring binge last month. These functions had a very concrete purpose.

[printz]

That said, checking these things is horrible. Not only is all convenience from having fixed offsets between positions thrown out of the window, far worse is how this clashes with Doom's rectangular collision boxes for actors. As a result I had to restrict the checks quite severely so that they don't mess up.

I intend to use in Eternity a single kind of linked portals, no weaker secondary variants. I'll probably find a way to handle off-position portals and afterwards the rotation portals.

[Graf Zahl]

It's surely doable, but magnitudes more invasive than simple offsetting. I could wrap those offsets in cheap wrapper functions I do not have to spend much thought of.
But this arbitrary stuff is so incredibly screwy it's nearly unmaintainable.

Just right now I am working on P_UseLines, and to handle these arbitrary portals a few functions down the line in P_CheckSwitchRange I had to carry a translated position value through several function levels, so that at the end I can use it to calculate some slope heights. Imagine that kind of thing needed everywhere... (BTW, slopes and portals are a horrible combination, they need double the care to ensure that you don't feed wrong coordinates to the ZatPoint functions that do height calculations...)

[ZZYZX]

And looking at the occasional glitches in the demo map clearly shows that it's all using BSP traversal - if it uses Build's algorithm there wouldn't be phantom walls occasionally showing in the portals. Even in GZDoom I haven't addressed that problem yet.

Wait WHAT PHANTOM WALLS?
I thought the clipping routine fixes most real life cases...

Or it's the Eternity demo map that you mean?

[Graf Zahl]

Gez's demo map is not completely free of them, the one portal right behind the player start is the easiest one to trigger. It also triggers in GZDoom, btw.

I know what happens there but fixing that has to wait until more important things are finished.

[Graf Zahl]

I completely redid the clipping function. Now it works a lot better - and is probably even faster. With that version I was unable to see any phantom walls in the demo map anymore.

[Gez]

Said demo map will probably need to be updated anyway due to "API" changes. (Though if the restriction that portals have to have a sector behind them has been lifted, the update will not need to involve changing the geometry.)