[Added] Wall portals

Moderator: GZDoom Developers

Re: Wall portals

Postby Graf Zahl » Thu Mar 03, 2016 7:34 am

Of course, but the rendering part is ok - and as it looks now - free of phantom walls. I spotted one other problem, though. If you look from the start over the nukage pit into the portal linking to the rotating polyportal, there's some sprites glitching around. I can't say why I didn't notice this before, I just hope it wasn't caused by fixing the performance problem (because undoing that is not an option.)
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby printz » Thu Mar 03, 2016 3:01 pm

How do polyobjects move in ZDoom? Are they affected by the inaccurate fixed-point trigonometry of Doom? Because if so, you're going to see HOM when being inside polyobject-portals and moving them next to walls, because you culled the parasitic (phantom) segs from the front of portals and the segs are either colinear (!) or appear slightly in front of the portals (because of inaccurate polyobject direction). I have this problem in Eternity, but I'm not sure I want to fix it, because vehicles aren't supposed to touch walls while moving anyway, except maybe for wall rails...

Did you also cull the sector portal parasitic segs? I didn't. Would using BSP splits as reference work?...
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 » Thu Mar 03, 2016 3:13 pm

printz wrote:How do polyobjects move in ZDoom? Are they affected by the inaccurate fixed-point trigonometry of Doom? Because if so, you're going to see HOM when being inside polyobject-portals and moving them next to walls, because you culled the parasitic (phantom) segs from the front of portals and the segs are either colinear (!) or appear slightly in front of the portals (because of inaccurate polyobject direction).


Right. I didn't think of that, but changing it would just mean to return 'false' instead of 'true' if the lines are colinear. If the line ends up on the wrong side, I guess there's not much that can be done anymore, because with ZDoom's mini-BSP attached to the polyobject those lines would be truly behind the portal plane.

Did you also cull the sector portal parasitic segs? I didn't. Would using BSP splits as reference work?...


The software renderer is barely capable of handling sector portals so this is hardly grounds for consideration at the moment.
In GZDoom I reject everything that's in front of the portal and may get in the way of the clipper - but if you know what to do you can actually make it glitch. But using a stencil buffer efficiently discards nearly everything that's not supposed to be seen, so most of the stray stuff that might be there never gets rendered.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby ZZYZX » Fri Mar 04, 2016 11:55 am

Graf Zahl wrote:The software renderer is barely capable of handling sector portals so this is hardly grounds for consideration at the moment.
In GZDoom I reject everything that's in front of the portal and may get in the way of the clipper - but if you know what to do you can actually make it glitch. But using a stencil buffer efficiently discards nearly everything that's not supposed to be seen, so most of the stray stuff that might be there never gets rendered.

If by "barely capable" you mean random HOM in the portal, then I believe the reason for this is that some solid walls might obstruct the visible portal area, so the more distant subsectors aren't drawn at all.
As such, removing parasite segs can and will help with that.
My old idea (unimplemented sadly) was to put a fake line that faces the player and goes through closest plane portal point, and clip away everything that's closer than this line (after translated to the other side obviously).

Minimal example of broken plane portal geometry: http://www.mediafire.com/download/y8pkr ... portal.wad
(works fine in OpenGL)
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 » Fri Mar 04, 2016 12:35 pm

It's not just that. Another problem is that inside the portal it has some problems with upper/lower textures and that it mixes up visplanes from portals with adjoining sectors having the same texture. And last but not least, this can really become slow to the point of unplayability.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby Graf Zahl » Sun Mar 06, 2016 6:10 pm

Another update:

Hitscans work with all types of portals and explosions with linked portals. Making explosions work with other portals is going to be a bit of a problem because of how the sight checks work. This will be a bit messy and I'm not sure yet if I'll do that for the first phase.

Aside from that there's 3 things left

- P_CheckSight
- linking actors into the blockmap through linked line portals.
- Making P_DrawRailTrail work with portals.

The first two should be done in the next few days, I'm not sure yet what is possible with the rail trail - the function will probably require a nearly complete rewrite so that it can handle portals.

After that I'll try to make the Eternity Polyportal map work - but that's something which only has some use in GZDoom - in ZDoom the display is just too broken.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby Edward-san » Sun Mar 06, 2016 6:46 pm

Does the code also handle firing hitscans or railguns through recursive portals?
Edward-san
Mathematics is the language with which God has written the universe. (Galilei)
 
Joined: 17 Oct 2009

Re: Wall portals

Postby Tormentor667 » Mon Mar 07, 2016 12:35 am

Awesome :)
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

Re: Wall portals

Postby Graf Zahl » Mon Mar 07, 2016 3:01 am

Edward-san wrote:Does the code also handle firing hitscans or railguns through recursive portals?



Since traces have a finite length I didn't bother checking that case. Even if it happens, it'll run out eventually.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby printz » Mon Mar 07, 2016 4:34 am

What if through some mapping bug, the looping portals are next to each other, so no movement happens between any teleportation? It will then teleport forever without increasing the distance.
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 Tormentor667 » Mon Mar 07, 2016 5:11 am

I started working with the portals another time and it's an amazing way to detail areas without too much effort. I have a building in Blade of Agony with numerous windows which are only there for depth-purpose. I created one room interior and linked it to several portals from several sides to make the building look like it has countless rooms - where this is only one :D I already abuse the feature and I love it ;)
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

Re: Wall portals

Postby Graf Zahl » Mon Mar 07, 2016 5:32 am

printz wrote:What if through some mapping bug, the looping portals are next to each other, so no movement happens between any teleportation? It will then teleport forever without increasing the distance.


Cannot happen. When I handle a portal I offset the trace by one mapunit. So if there's overlapping lines the second one will be skipped. This was done quite deliberately to avoid such situations.
Of course, if you are dead set on doing it, you can construct a map that runs into a stack overflow, but that'd require some deliberately inane setup to begin with.

I'll deal with such things later, first I want to make P_CheckSight work, after that I'll start checking some edge cases.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby Tormentor667 » Mon Mar 07, 2016 5:59 am

@Graf Zahl - One thing I noticed when playing around with the wall portals:
Code: Select allExpand view
Line 14858 (type 156:Line_SetPortal), arg 4 is 1 (should be 0)

Considering that argument 4 is defining the vertical alignment of the portal (floor or ceiling), this message is somehow irritating.
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

Re: Wall portals

Postby printz » Mon Mar 07, 2016 6:13 am

Graf Zahl wrote:Of course, if you are dead set on doing it, you can construct a map that runs into a stack overflow,

That would crash GZDoom without warning.
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 Mar 07, 2016 6:46 am

I know, but with such things there's two choices: Add countless checks which slow down the code or let bad mappers suffer from their ineptitude. Stuff like this will never reach the end user because it won't ever work.
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