Wall portals

[Graf Zahl]

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.)

[printz]

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?...

[Graf Zahl]

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.

[ZZYZX]

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)

[Graf Zahl]

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.

[Graf Zahl]

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.

[Edward-san]

Does the code also handle firing hitscans or railguns through recursive portals?

[Tormentor667]

Awesome

[Graf Zahl]

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.

[printz]

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.

[Tormentor667]

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 I already abuse the feature and I love it

[Graf Zahl]

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.

[Tormentor667]

@Graf Zahl - One thing I noticed when playing around with the wall portals:

Code: Select all

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.

[printz]

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.

[Graf Zahl]

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.