[Added] Wall portals

Moderator: GZDoom Developers

Re: Wall portals

Postby Graf Zahl » Sat Feb 27, 2016 4:46 pm

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

Re: Wall portals

Postby printz » Sun Feb 28, 2016 3:27 am

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.
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 » Sun Feb 28, 2016 3:54 am

printz wrote: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.

printz wrote: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.


printz wrote: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.)

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

Re: Wall portals

Postby printz » Sun Feb 28, 2016 5:22 am

Graf Zahl wrote:
printz wrote: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).

Graf Zahl wrote:
printz wrote: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.

Graf Zahl wrote: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.

Graf Zahl wrote:And the testmap you posted on Doomworld today causes the engine to hang on the portal transition.
You mean ZDoom, right?

Graf Zahl wrote:
printz wrote: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.
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 » Sun Feb 28, 2016 5:54 am

printz wrote: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.


printz wrote: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... :mrgreen:) but the chasecam will definitely be tricky when the time comes to adjust it.

printz wrote: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...

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

Re: Wall portals

Postby Major Cooke » Sun Feb 28, 2016 12:58 pm

Wait, some of the Sector_SetPortal stuff is development branch only right now, right?
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: Wall portals

Postby Graf Zahl » Sun Feb 28, 2016 1:37 pm

Yes. But only type 6, i.e. interactive portals.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby Major Cooke » Sun Feb 28, 2016 4:25 pm

Speaking of this... I somehow get the feeling that A_CheckProximity is also going to need something similar. Maybe?
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: Wall portals

Postby Graf Zahl » Sun Feb 28, 2016 5:52 pm

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

Re: Wall portals

Postby printz » Mon Feb 29, 2016 5:10 pm

Graf Zahl wrote: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.
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 » Mon Feb 29, 2016 5:34 pm

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

Re: Wall portals

Postby ZZYZX » Wed Mar 02, 2016 7:37 am

Graf Zahl wrote: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?
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby Graf Zahl » Wed Mar 02, 2016 8:19 am

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

Re: Wall portals

Postby Graf Zahl » Thu Mar 03, 2016 6:28 am

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

Re: Wall portals

Postby Gez » Thu Mar 03, 2016 6:47 am

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.)
Gez
 
 
 
Joined: 06 Jul 2007

PreviousNext

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests