hfc2x wrote:Lol, I had already made an article for the special: [wiki]Line_SetPortal[/wiki].
You got the meaning of 'interactive' wrong, but aside from that it's clearly the better one.
Interactive means that if any action reaches through a portal it will happen on the other side, for example spawning a projectile with an offset or stuff like that,
The simple teleporter has less overhead and can be used in places where monsters cannot go, for example.
I just realized - the z-offsetting that's possible here may have to be restricted to visual and teleport-only portals.
There's absolutely no way that the bulk of the playsim code can ever be rewritten to handle that transparently, there's just way, way too much code that handles z as an afterthought, not as an integral part of the actual position.
Here's a small example of the function DoCheckRange that shows rather well what's up here:
// Check distance first, since it's cheaper than checking sight.
fixedvec2 pos = camera->Vec2To(self);
fixed_t dz;
fixed_t eyez = (camera->Top() - (camera->height>>2)); // same eye height as P_CheckSight
if (eyez > self->Top())
{
dz = self->Top() - eyez;
}
else if (eyez < self->Z())
{
dz = self->Z() - eyez;
}
else
{
dz = 0;
}
If that has to reach through an interactive portal with z-offset all bets are off - unfortunately there's so many places in the code where similar stuff is done that refactoring all of them would become a major chore - so I'm definitely putting this off for the time being.
So any of those calls while around an interactive portal will force it to transform into a different type? I'm slightly confused. Or is it whenever between a portal?
Well, I dont understand any of the technicalities being mentioned here. All I know is that this is one wonderful feature, that whenever is ready, I'll love to mess with it, even if nothing productive comes out of it.
(I can only try to imagine what someone like cyriak would do with stuff like this )
Last edited by DBThanatos on Fri Feb 05, 2016 10:42 pm, edited 1 time in total.
What I do is to reduce the portal to 'teleport only'.
The issue is actually quite simple: A lot of code that calculates offsets, my guess would be half of it, does it in a way that just does not work if a portal offset with a z-delta != 0 needs to be added.
As long as z on both sides of the portal is identical this all will work fine.
But keep in mind now, that the original submission never even got close to what I define here as 'interactive'. (and to be honest it remains to be seen how extensive that needs to become.) The code I saw was pretty much 'teleport only', i.e. it handled P_TryMove, P_RadiusAttack and P_RecursiveSound. The real horror lies beyond those (rather trivial) basics.
And that's also why absolutely do not like the idea of passable one-sided-wall portals. They'll never work correct because stuff like sliding would inevitably fall apart around such a portal.
With all respect to ZZYXZ and what he achieved here, conceptually it's really not bad and it certainly worked to the degree this got implemented - but making this robust and failure proof is an entirely different matter and won't be possible without setting some restrictions. If we approach this with 'anything goes, let's just try' the end result will be a mess.
To be frank, I'd be more than satisfied if we got this to a state where:
- Eternity-style linked portals are fully working
- arbitrary portals can transfer all effects directly affecting the portal (i.e. an actor moving in, some explosion moving in and some monster alerting sound moving in)
- any passable portal is required to have some space behind the portal line to ensure no physics breakage (no, it's not possible without that, not universally!)
- interactive portals handle anything a teleporting portal can, plus any action from another actor that reaches through a portal (like a projectile spawn at an offset), provided that there's no z-offsetting.
This will take some time for sure.
Anything beyond that would be icing on the cake but definitely enter non-trivial territories, and should be deferred until after the simple basics have been worked out. Remember: Even those basics are a fantastic feature. But it'd be a shame if that failed because the ambitions were too high and as a result nothing works right because too many edge cases need to be handled.
With sector portals there's the obvious problems that they are EXTREMELY glitchy and volatile in ZDoom's software renderer so implementing them makes very little sense.
In GZDoom things look different - GZDoom's portal renderer can handle Vaprdemo almost error-free (there's one cross portal lift that does not work but I'm going to find what breaks it),so yes, it's definitely on my list. Whether it makes sense to include the code in ZDoom in the hope that these portals eventually get fixed I cannot say. I sure hope someone finds the right voodoo to make them render properly.
)
