[Added] Wall portals

Moderator: GZDoom Developers

Re: Wall portals

Postby Gez » Tue Mar 08, 2016 8:53 am

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

And Printz for bringing Eternity closer to ZDoom. :P
Gez
 
 
 
Joined: 06 Jul 2007

Re: Wall portals

Postby NeuralStunner » Tue Mar 08, 2016 9:46 am

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!
User avatar
NeuralStunner
Not "Neutral"
 
 
 
Joined: 21 Jul 2009
Location: capital N, capital S, no space
Discord: NeuralStunner#4201
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: Wall portals

Postby Trusty McLegit » Tue Mar 08, 2016 4:39 pm

Graf Zahl wrote: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?
User avatar
Trusty McLegit
 
Joined: 07 Feb 2016

Re: Wall portals

Postby GooberMan » Tue Mar 08, 2016 4:48 pm

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.
You do not have the required permissions to view the files attached to this post.
User avatar
GooberMan
Best taken in small quantities
 
Joined: 08 Aug 2003
Location: Helsinki, Finland

Re: Wall portals

Postby Graf Zahl » Tue Mar 08, 2016 5:09 pm

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.)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby NeuralStunner » Tue Mar 08, 2016 5:25 pm

Man, this is progressing fast. :D

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.
User avatar
NeuralStunner
Not "Neutral"
 
 
 
Joined: 21 Jul 2009
Location: capital N, capital S, no space
Discord: NeuralStunner#4201
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: Wall portals

Postby Graf Zahl » Tue Mar 08, 2016 5:49 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby Major Cooke » Tue Mar 08, 2016 5:56 pm

Graf Zahl wrote:sounds, sight and monster attacks


And quakes. They can cause damage out of sight too, last I checked.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: Wall portals

Postby Graf Zahl » Tue Mar 08, 2016 6:01 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby Major Cooke » Tue Mar 08, 2016 6:16 pm

And speaking of other non-trivial things...
I don't remember, were seeker missiles done already?
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: Wall portals

Postby Graf Zahl » Tue Mar 08, 2016 6:26 pm

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby Major Cooke » Tue Mar 08, 2016 6:37 pm

Yeah the auto-acquiring one is what I was concerned about.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: Wall portals

Postby Graf Zahl » Wed Mar 09, 2016 5:25 am

GooberMan wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby printz » Wed Mar 09, 2016 5:50 am

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...
User avatar
printz
Eternity, Eureka and AutoDoom programmer
 
Joined: 26 Oct 2006
Location: Bucharest, Romania
Github ID: ioan-chera
Operating System: Windows 10/8.1/8/201x 64-bit

Re: Wall portals

Postby Graf Zahl » Wed Mar 09, 2016 6:06 am

printz wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

PreviousNext

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 1 guest