Wall portals

[Jaxxoon R]

Whoooa, does this mean it will actually come to be? I need some brain-melting geometries in my life, man.

[Graf Zahl]

The visual parts of it definitely, and with 90% probability, crossable portals where both lines of a portal must be parallel to each other. The weird cases are on a 'we may see...' basis. But these will never be fully interactive. Some things may work but the engine is far too complex to handle arbitrary portals transparently.

[ZZYZX]

Graf, you realize I already have good (relatively) code (even supporting interpolation to some degree) in portals/portals2 branches (not portals2-visual)?
And it supports randomly aligned portals, not just parallel. See portal.cpp and usages of it in other branches.

My old shittily written code (portals branch) also had some good portal transparency in it, involving hitscan traversal, autoaim traversal, radius damage traversal, thing spawning traversal (for things explicitly spawned with offsets, like rocketlauncher shot). Only needs to be rewritten/structurized.

Well, in fact, even my portals2 branch already has crossable arbitrary portals, it should be fixed up/tested for a bit and then it should be ready for inclusion as well. I could make pull request.

[Graf Zahl]

How does it handle sound? That's probably the biggest gotcha that gets into play here.
And how does it handle monster AI?

As for interpolation. I just have done some important work on that to also track a movement vector, which hopefully should help solve the problems here. Last week I added some cheap handling for Eternity-style portals to GZDoom and the interpolation glitches were quite bad, with no decent way to handle them.

How long do you think you need to rewrite this stuff?
For me it essentially means, that as long as this isn't done there's really no point continuing my work on GZDoom to support linked sector portals, as these features will inevitably get in the way of each other unless they are coordinated.

[ZZYZX]

How long do you think you need to rewrite this stuff?

Not sure, the hard thing here is NOT allowing the new physical portal code to become as messy as it was, while keeping the functionality.
The old code (as of the video in the OP post) was written in a month or so.

For sound and AI, currently it doesn't handle these at all, but I was going to implement this by checking nearby portals and sending sound to all of them (and playing back on player's side if they are on the front side of the portal, possibly with additional attenuation based on actual player position).

As for AI, I didn't even try to make any working algorithms for that. The simplest would be keeping few alternate walking paths (or more specifically, walking directions, as Doom doesn't really have any paths) based on portals directly visible to the monster, and taking the closest computed path.

[Major Cooke]

For sound and AI, currently it doesn't handle these at all, but I was going to implement this by checking nearby portals and sending sound to all of them (and playing back on player's side if they are on the front side of the portal, possibly with additional attenuation based on actual player position).

Bear in mind the $singular and the $limit flags though. $limit will only stop other playbacks of itself if the maximum is reached within player hearing distance, but $singular will prevent the sound from playing if its limit is reached unconditionally, heard or not.

[Graf Zahl]

My idea for this would be to have an official branch and best get ZZXZX access to it, so that he and I can both work on this to get the needed features in and streamline the overall handling. If Randi doesn't want to give access I'd be happy to do this on the GZDoom repo.

I don't think it's a good idea to develop all of this in private and then make a submission at the end. The better idea would be to do this in a publc repo function by function, adding handling for one item at a time, make sure that this works and then do the next. With some collaboration this should be doable rather quickly. I had a look at the old submission and it doesn't look so bad. What's more needed than cleaner code is a cleaner p_map.cpp. That file has grown too much and contains too many different functions so it might be a good idea to split off the separate utilities in there and extend them in separate source files.

[ibm5155]

Those portals could make a great use in elevators áreas, since you can change the portal destination by acs (no more elevators where you enter from one side and goes out by the other

EDIT: Great work on the testing map Gez, I beat we did more than Eternity could do

And, what if a portal destination is the same line that the player is crossing? It'll act as a reflection wall that can be crossed?

I'll not lie, if sound and ai doesn't work for now but only player can cross the portals, then I'm fine with it

[Nash]

Will we be able to re-create - for example - Urban Brawl's bus interior/exterior like on the bridge map, in a less hacky way? Like as in, the exterior of the bus would just be a raised floor and you could jump on top of it physically, yet you could still see the insides of the bus at the lower sides...

[Graf Zahl]

For that 3D floors would still be the better option.
Do do some fake 3D stuff, sector above sector portals are probably more important than line-to line portals.
Unfortunately those are extremely glitchy and performance-critical in ZDoom.

In comparison to Eternity, these portals may be more versatile but at the same time allow less transparency to the playsim. In Eternity a linked portal specifies a fixed 2-dimensional displacement value that will never change (and z has to be identical on both sides to work.) which makes cross-portal calculations like actor distance relatively simple - all you need is factor in this displacement if you calculate the distance between two points - there isn't even any need that a direct line of sight exists.

Both types have their specific advantages and disadvantages, so I think both should be implemented if doable. The code that directly interacts with the portal would be identical anyway.

[ZZYZX]

Speaking of test map and traversible portals btw.
The original messy code was nevertheless capable of doing this: https://www.youtube.com/watch?v=oYI9LFP0K6U&t=2m
So you should understand why I was like "wtf" when I read about parallel only.

Will we be able to re-create - for example - Urban Brawl's bus interior/exterior like on the bridge map, in a less hacky way? Like as in, the exterior of the bus would just be a raised floor and you could jump on top of it physically, yet you could still see the insides of the bus at the lower sides...

Probably not. Urban Brawl's bus should be 3D floor driven and it would be if ZDoom at the time supported 3D floors.

EDIT: Great work on the testing map Gez, I beat we did more than Eternity could do

yes

And, what if a portal destination is the same line that the player is crossing? It'll act as a reflection wall that can be crossed?

It won't work at all, AFAIK. Because self reference is treated differently. You'll have to put two separate lines with different tags next to each other, like Gez did in his "broken mirror".

In comparison to Eternity, these portals may be more versatile but at the same time allow less transparency to the playsim. In Eternity a linked portal specifies a fixed 2-dimensional displacement value that will never change (and z has to be identical on both sides to work.) which makes cross-portal calculations like actor distance relatively simple - all you need is factor in this displacement if you calculate the distance between two points - there isn't even any need that a direct line of sight exists.

I think there's already a generalized function to both translate a point x1,y1 to x2,y2 (portal-aware version) and generalized function to translate point from one portal side to another (the function that's used in R_EnterPortal to get new viewx/viewy/viewz). Everything else should be relatively easy given we remember the portals that thing has gone into, and do the translations incrementally for each of these.

Both types have their specific advantages and disadvantages, so I think both should be implemented if doable. The code that directly interacts with the portal would be identical anyway.

I again don't see what exactly should be "implemented" additionally for Eternity as their portals are much simplier. Eternity portal will be just xlat-translated to ZDoom portal, everything else should be naturally compatible.
Or you want a compatibility mode that doesn't let bullets through for example?

[Gez]

EDIT: Great work on the testing map Gez, I beat we did more than Eternity could do

Yes the testing map is totally bonkers. I think the disco room with the rotating polyportal is the biggest WTF moment in it.

That said, there are advantages to Eternity's more restrained portal features. It allows to make neat stuff with the automap:



If the same thing was successfully attempted on ZDoom, the automap view for the test map would completely spaz out. I think losing portal overlay on the automap is a good tradeoff for instead getting to do non-parallel polyportals.

Or you want a compatibility mode that doesn't let bullets through for example?

It wouldn't be justified.

[Graf Zahl]

I think there's already a generalized function to both translate a point x1,y1 to x2,y2 (portal-aware version) and generalized function to translate point from one portal side to another. Everything else should be relatively easy.

That was one major part of my recent refactoring to get all those distance calculations into a small set of AActor member functions. Yes, changing it should be relatively simple, even with arbitrary portals.
Where issues come in is with performance. If you can link portals from anywhere to everywhere you cannot make many assumptions and actually have to do each calculation that MAY traverse a portal instead of taking shortcuts.

With Eternity's setup each sector gets a group ID and a table is set up that contains the displacement offsets, so distance calculation between two actors is never more than doing 'postarget' - 'possource' - 'displacement from dest sector to src sector' instead of actually traversing the portals and adding up the displacements.

I again don't see what exactly should be "implemented" additionally for Eternity as their portals are much simplier. Eternity portal will be just xlat-translated to ZDoom portal, everything else should be relatively compatible.
Or you want a compatibility mode that doesn't let bullets through for example?

It really depends on how the portals should behave. I guess the fine details become more important if sector portals also were available because if they do not work well together with one unified set of logic some strange edge cases can be constructed. where e.g. Monsters do not act as one would expect.
There's also one other interesting aspect in Eternity: It can actuall overlap the various sector groups on the automap and only highlight the one the player is currently in. This by necessity requires a fixed offset and orientation between both ends of the portal.

Regardless, currently the only real-life portal map for Eternity is the Vaporware demo and that was constructed with known severe limitations on the portal workings and as a result all the transition points were placed so that they never interfered with the actual action, so for now the discussion would be academic anyway. I guess we'll have to see how long it takes until some more Eternity maps show up. Now that they finally found someone to fix the portals it may actually happen...

@Gez: I'd say there's no reason not to allow both: Have one portal type be dynamic and flexible and the other static and with the same limitations as Eternity so that the offset needed for the overlay automap can be retrieved. For a first step that's more than enough. If some further changes for gameplay are needed, I think my coordinate refactoring already took good care of isolating all the places that may need treatment.

Now someone just needs to find the magic ingredient to make sector portals not glitch as badly as they do...

[ZZYZX]

Now someone just needs to find the magic ingredient to make sector portals not glitch as badly as they do...

I have absolutely no idea how plane portals work, mirror-based ones are so much simplier.

With Eternity's setup each sector gets a group ID and a table is set up that contains the displacement offsets, so distance calculation between two actors is never more than doing 'postarget' - 'possource' - 'displacement from dest sector to src sector' instead of actually traversing the portals and adding up the displacements.

Well, we can detect if portal angle doesn't change and not perform like half of the calculations if it is so. Will help somewhat.

[Graf Zahl]

Yes, if the portal transition is noticed as such, that will work. But that still doesn't do anything about sectors where it cannot be trivially decided that a portal transition takes place at all.
But the part that's most appealing to me is the automap, and that requires a fixed, unchanging and unambiguous offset.

In the end it'd just be another parameter that blocks the portal from getting changed and ensures the same conditions that are required in Eternity. Whatever comes after that remains to be seen but is far, far less important than getting these portals in in the first place.