Wall portals

[Edward-san]

I'd say any portal beyond the recursion limit should simply be filled with the fog color.

I was thinking about filling with black, but indeed the fog color could help (if fog is present), maybe a little bit darker..

[Graf Zahl]

Why darker? The fog color is clearly the best option to hide this stuff. Best would probably be to use black with colormap applied.

[ZZYZX]

For what it's worth, I wouldn't have an issue with a more limited feature set (E.G no polyobject portals) if it means they work better (E.G. faster).

Polyobject portals implement MOVABLE 3D FLOORS and TRAINS. This side feature is even better than portals as-is, if not more expected.
And it doesn't conflict with having empty space behind portals anyway, and neither conflicts with the requirement of same line angle (well, at least not always, if train does not rotate). So I don't see why this should be removed.

[Graf Zahl]

You know, I trust people like Quasar and SoM a lot more on those technicalities regarding the Doom source. Like me, they have been working with it for 15 years and more and know it inside out.
If you accuse them of being lazy I have to question your standpoint on this matter.

Yes, I know the stuff with the tracer - the question is how much of this shit are you willing to implement before you got something that works? I choose to set priorities - and those are clearly focussed on the cases that I know can be done in a reliable fashion. Once that part is done, let's talk again.
I have had my experiences with those super-mega-über-features in various projects that could do nearly anything but were ultimately brought down by the problems that weren't easily solvable. This won't happen here. So there will be pure teleport portals first (least coding and needed for all types), linked portals second (second-least coding and relatively little invasive stuff) and the rest a distant, distant third. If the first two are working it would satisfy 90% of the mappers' needs. But those remaining 10% that need that ultra-cool interactive rotating polyportal or whatever edge case will probably cost twice as much work as the rest combined.
I'd rather invest that time in making sector portals in GZDoom passable.

[Major Cooke]

Sorry for the impatience but when can this be considered to be added to the latest GZDoom svn?

If I were you, I'd make your mapsets using 3D floors in the mean time wherever you planned static portals because if it doesn't work to how you hope/want them to (and I have to ask, are you reading on how much Graf is dumbing down on the portals? Chances are they might not, you never know), it's not too big of a loss. But that's just my suggestion.

[Gez]

Personally I don't mind if polyportals are limited to basically what's available in ZZYZX's old test build (actors and hitscans can move through, even if monster AI ignores it) because it's largely enough to be very useful already. The idea of having two levels of portals -- "shallow" portals with limited interactions but great flexibility, and "deep" portals with rigid limitations but fully integrated in the game world -- is okay. We'll still get polyportals this way.

Right now I worry more about the loss of dynamically redefined portals. They seem to be the best way to make a convincing elevator (close the doors, change the portal, open the doors) and they also have a lot of potential such as, for example, turning a portal on or off. Think about a Stargate-like UAC machinery, or about these ethereal travel triangles from Hexen that raise from the ground in a few levels. Think of all the plots where the mission is to shut down a portal between the evil monster dimension and Our Hero's lands.

[Graf Zahl]

It's already back. The old way to set them was just shit because it prevented any means of building a data table on level start and used a method for data storage that just didn't cut it.

[NeuralStunner]

I'd say any portal beyond the recursion limit should simply be filled with the fog color.

Something I recall from the Portal dev commentary: Using low-res texture renders. Imagine treating the portal destination as a camera and the source plane as a camera texture. Probably not as simple as that sounds, but it's my best idea short of agreeing with fog color.

Personally I don't mind if polyportals are limited to basically what's available in ZZYZX's old test build (actors and hitscans can move through, even if monster AI ignores it) because it's largely enough to be very useful already. The idea of having two levels of portals -- "shallow" portals with limited interactions but great flexibility, and "deep" portals with rigid limitations but fully integrated in the game world -- is okay. We'll still get polyportals this way.

I was just thinking about this as well. Assuming it's easy enough to split functionality this way, simple is better than none.

Think about a Stargate-like UAC machinery, or about these ethereal travel triangles from Hexen that raise from the ground in a few levels.

One of my first thoughts was "exterior cell loading". One could conceal it with fog, or swap for a Line_Horizon at the outer edges of view. I guess you'd still have to scale down actors &c. quite a bit to make enough room on the map to do all this, but you could potentially fix render distance problems, assuming the portal itself is fast enough to draw.

[Graf Zahl]

One question:

Would it bother anyone if I say "No slopes around line portals?"

The problem with them is actually quite simple: To get an actual floor height from them a call to the ZatPoint function is needed - and not surprisingly that will dismally fail if it gets called with a coordinate in another part of the map. I have no idea how many places there are where this can become an issue - it will have to be carefully reviewed. Although I don't think that outside P_ZMovement there is anything critical, that particular function gives me the creeps.

Another issue is portal with a height offset where floor and ceiling don't match. Here I'd have to store some values that don't match the actual sector and I have no idea if that may cause problems somewhere. And this pretty much confirms my 'no one sided crossable portals' rule. To avoid getting a headache from these edge cases (which, if dealt with would result in massive code explosion) let's define the following rule:

For teleporter portals the map geometry of the backside of the portal will never be checked, only the actors that may block. If there's obstacles they should be replicated in the back sector of the portal line so that it all remains manageable. (Oh, and sorry if that makes teleporting polyportals too limited. To be blunt: I'd throw those out in an instant if I find out that they complicate things too much! They are already proving a conceptual nightmare because everything I do has to take these shitty things into account.)

For the other types it's no big deal, since height offsets and use on polyobjects are not allowed, removing the mess of z-checking entirely. Since both sides are at the same height there's no convoluted displacement calculations and other nonsense which would have to be checked everywhere where some geometry checks are done - and that's far from only in P_CheckPosition!

Regardless, actor checking through a portal that changes orientation is going to be fun, too. The 'slide against actors' code is going to like that...

[ZZYZX]

Would it bother anyone if I say "No slopes around line portals?"

No, at least not me. Although do you mean directly adjacent or no slopes at approximately player radius from the portal?

For teleporter portals the map geometry of the backside of the portal will never be checked, only the actors that may block. If there's obstacles they should be replicated in the back sector of the portal line so that it all remains manageable. (Oh, and sorry if that makes teleporting polyportals too limited. To be blunt: I'd throw those out in an instant if I find out that they complicate things too much! They are already proving a conceptual nightmare because everything I do has to take these shitty things into account.)

Seriously? Show people working movable sectors after 23 years of Doom and throw them out instantly? I understand this complicates things a lot, but isn't it worth that?

...which would have to be checked everywhere where some geometry checks are done - and that's far from only in P_CheckPosition!

I started suspecting that when my first branch had bugs exiting and entering polyobject portals (even parallel lines!); it looked like something was setting velocity to 0 for some reason.

[Major Cooke]

Seriously? Show people working movable sectors after 23 years of Doom and throw them out instantly? I understand this complicates things a lot, but isn't it worth that?

I don't think he has. Yet.

[Graf Zahl]

No, at least not me. Although do you mean directly adjacent or no slopes at approximately player radius from the portal?

I mean close enough that such a slope can become the floorsector or ceilingsector of the actor passing through.

Seriously? Show people working movable sectors after 23 years of Doom and throw them out instantly? I understand this complicates things a lot, but isn't it worth that?

'It complicates things a lot' is the operating term here. I still can't wrap my head around how these things can ever be made to work in a robust fashion.
Maybe later when I have a better overview over the whole thing.

Let's be clear here: If you present a large problem, the only way to solve it is to break it down into smaller problems that are easier to solve. That is, get the basics to work first, do the necessary stuff next and the cool stuff last. Currently I need to think about far more fundamental concerns, i.e. getting something to work I can test and extend.

...which would have to be checked everywhere where some geometry checks are done - and that's far from only in P_CheckPosition!

I started suspecting that when my first branch had bugs exiting and entering polyobject portals (even parallel lines!); it looked like something was setting velocity to 0 for some reason.[/quote]

One particularly nasty example here is if you bump into an actor on the other side of the portal and there is an angular displacement to consider. THAT is going to be a horror story of its own to deal with. The problem is that actors are square and the bounding box on both sides of the portal is not identical, so how to properly calculate the slide here is not going to be easy. And unfortunately that probably means that many interactive features will have problems with those.

Rendering such portals is the easy part. Making it all work in a well defined fashion with something as messy as Doom's collision detection - that will take a lot of time. Which is why I'd really prefer to make Eternity style portals work first. With them all the nastiness gets reduced to a simple offset that's being stored as part of the map, so I can focus on the important stuff, like extending the parts that need to reach through portals. And that's why my roadmap has not changed. Having to think all the time about such crazy stuff like polyportals will only bog down my progress on the thing as a whole.

Doing a simple P_CheckPosition is not an issue, but dealing with the results can be - and that's the point of the 'teleporter' portals because they explicitly state that this part is not being done (i.e. it is the mapper's responsibility to keep the vincinity of the portal clean of problematic obstructions.)

I think, once Eternity-style portals are working as good as they can, then is the right time that I know what I'm up against to think about what can be done with the rest.

[Graf Zahl]

Just a little note:

No, there hasn't been any progress. I'm still trying torefactor this stuff so that it later won't interfere with a sane linked portal implementation. Remember: GZDoom's renderer is stable enough to allow for linked stacked sector portals, and everything that goes wrong here will later come back to haunt me.

I think I'll go the other route: First implement sector linking and once that works, make the other portal types work, even if that means implementing some parts of linked stacked sectors in ZDoom, too - but the worst thing would ultimately be that these two things don't mix well, that'd be to nobody's advantage. Otherwise I'd have to do half the work on ZDoom and the other half only on GZDoom - that's not going to work out.)

The actual danger I see is that these arbitrary portals - if implemented first, may eventually block some essential features. Once I know what needs to be changed about stuff like P_TryMove and P_CheckPosition to handle linked portals, the rest should be a lot easier to do, because then it cannot get in the way anymore.

[Major Cooke]

Need any help bug testing this? Any demonstration maps I should use if you do?

[Graf Zahl]

Maybe later. This is going to take a few weeks until something testable emerges. Until then Vaporware will do as test material.