Wall portals

[ZZYZX]

Well... subj.
Disclaimer: this isn't really a feature/pull request, since the code is incomplete. This is still a WIP though so it might later actually become a feature request. The whole approach is pretty hacky and coding is done in the style "if it works, then yay!"

Basically this is a combination of (slightly fixed) mirrors and Teleport_Line.

---

Features:

• Doesn't require empty space behind portals (same applies to render part of mirrors now, btw);
• Works with arbitrary line angles
• Works with arbitrary floor/ceiling heights on both sides of the portal
• Works with polyobjects
• Works with 2-sided lines
• Can be turned on and off dynamically (SetLineSpecial works)
• Actors teleport
• Hitscan teleports
• Railgun teleports
• Autoaim teleports
• Radius damage teleports into all nearby portals
• Things should be spawned through the portal
• Collisions work
• Using lines/things through portals works
• Handling of movement across Teleport_Line has been fixed (for details see my comment in P_XYMovement in p_mobj.cpp)
• Makes ZDoom support wall part of EE linked portals through xlat (to the extent specified above)

Bugs/unimplemented features ordered by importance:

• The game randomly crashes on actor going through. The crash seems to happen inside P_ActivateLineSpecial.
• Monsters are unable to walk through the portal
• If a thing stands in two portals at once, it will be linked into the blockmap behind only one of them.
• For the reason unknown yet, the walls IN FRONT of a mirror inside a portal aren't clipped by the walls that are also in front of that mirror, but closer to the viewer. (that green transporter box)*
• A moving polyobject won't "swallow" actors in it's path. It should.
• Chasecam will get blocked by portal lines
• View interpolation should use P_TeleportPoint in order to have smooth transition through the portal instead of just resetting PrevX/Y
• Didn't even touch monster AI (and have no idea [yet?] how to touch it, advices welcome)
• BFG tracers won't be spawned in the right direction if the ball explodes inside a portal (partially related to the AI issue, requires sight tracer to go into portals as well)
• Shooting at visible top/bottom parts of two-sided line portal won't work as expected

* — fixed in /portals2

How to use:
This adds two specials, 155:Line_SetVisualPortal and 156:Line_SetPortal.
Both take three arguments, target line ID, current line ID (for Hexen maps, ignored in UDMF format), and linked plane.
If linked plane is 1, then the portal is moved vertically in such a way that floor planes of the current sector and receiving sector match. If linked plane is 2, then the same thing is done but with the ceiling.
Both can be set dynamically via SetLineSpecial.
Line_SetVisualPortal can point to any valid line ID, while Line_SetPortal requires destination ID to also have this special (although they shouldn't necessarily match each other).
Two lines can share common ID and have it set on both lines as destination, it will work.

Source: https://github.com/jewalky/zdoom/tree/portals
Binary with example map, if anyone is interested in testing this: http://www.mediafire.com/download/h7q7a ... zdoomx.zip
Separate demo map made by Gez: http://www.mediafire.com/download/dms9e ... _test0.zip (it's cooler than Eternity linked portal demo )

Notes:
r_portal_recursions 64, 1920x1080, pretty old 1.8ghz dual core CPU.
FPS drops from 60 to ~32 on Gez's test map compared to 4 recursions (infinite hallway, not pacman. pacman drops fps to 8 without changing r_portal_recursions :V)
This means that r_portal_recursions set to 16/32 is relatively reasonable (to avoid noticeable glitches with effects like that infinite hallway).

Current status:
6 critical bugs are to be fixed. Slowly. A serious refactoring for less code duplication is required.
New branch exists: https://github.com/jewalky/zdoom/tree/portals2
No build here until the refactoring branch has the same feature list as the old one. Same with updating the description above.

---

• Merged portal and mirror code. A mirror is now a passive (visual) portal that points into itself with "I'm a mirror" flag.
• Portals are rendered black once depth limit is reached, instead of causing a HOM effect.
• Portal and mirror recursions are the same value.
• Fixed null dereference somewhere... I forgot where exactly, but there definitely was one.
• Portal source and destination lines aren't queried each time they are needed anymore (as well as portal flags). They are set on the linedef more or less statically during map load or after SetLineSpecial is called on a line.
• The "mirror inside a portal" glitch that haunted the original version has been fixed.
• r_highlight_portals CVar can be used to outline portal/mirror drawsegs in red, making it easier to spot portal-related visual bugs.
• Physics are a major unworking mess, tbd

[Gez]

That seems very promising.

Bugs/unimplemented features:

• Mirrors aren't friends with portals (I guess there's some logical bug in R_EnterMirror...)
• Didn't even touch monster AI (and have no idea [yet?] how to touch it, advices welcome)
• Autoaim doesn't teleport
• Sound doesn't teleport either
• No idea how this should work with Hexen format... AFAIK it won't support specials above 255.
• A moving polyobject won't "swallow" actors in it's path. It should.

Monster AI is kind of primitive. There's two parts: attacking through the portal, and moving through it deliberately in pursuit of the target. The former mostly requires that line of sight checks do teleport, which means you have to add LOS checks to nearby portal surfaces. That is to say, if you have a set up like this:

Code: Select all

P M W T P

Where P is the portal, M the monster, T its target, and W a wall, normal line of sight will be checked between M and T, and find out the wall in between. So in addition the monster should make a LOS check with its side of P, and if it sees the portal you have to transfer the target's coordinates relative to the portal, aim at that, and teleport the trace to see if it ends up finding the real target on the other side of the portal. Moving through the portal deliberately is even trickier and shares the existing issue that monsters don't actively use teleports to reach their target. In the example, the monster would normally move towards the target and get blocked by the wall. In both cases it can add quite a bit of overhead (especially if there are nested portals) so if it happened it should probably be made conditional to a MAPINFO flag.

For sound I have no clear idea because I don't really know the sound code. It's probably possible to determine a sound's attenuated volume at the middle point of a portal, and create a similar sound with these values at the middle point of the other side of the portal.

For the Hexen issue, there are still free specials available in the 1-255 range: 105-108, 122-124, 126, 141-144, 146-151, 155-156, 162-167. So you can use e.g. 156 instead of 256.


Having tested your exe and map, the BFG's tracers don't seem to teleport right either. Shooting the BFG through the portal only killed one sergeant.

[Nash]

Would it eventually be possible to use wall portals on 2-sided lines? Upper and lower textures?

And is the teleport code easy to port to floor portals too?

[Graf Zahl]

Definitely interesting, but here's a few thoughts:

- please update your repo to the latest ZDoom. There have been some changes - in p_map they are so severe that I wasn't able to really compare the files anymore
- why did you use an action special larger than 255? There's still enough free ones available below.

Some of the limitations may pose a problem, though, at least the spawning, collision checks and autoaim should work. Sound and monster AI are probably not fixable, though. And better not think about polyobjects at all, portals on polyobjects would cause some major headaches anyway.

BTW, how did you get around the issue with mirrors that requires empty space behind them? Your portals clearly don't need that.


@Nash: Don't get carried away. This isn't even in a releasable state yet and you already ask for some far more complex stuff.

[ZZYZX]

please update your repo to the latest ZDoom. There have been some changes - in p_map they are so severe that I wasn't able to really compare the files anymore

I'll try... although it'd be way better if I used git initially instead of just downloading latest stable source.

why did you use an action special larger than 255? There's still enough free ones available below.

Because I had no idea of what specials are free. I'll change it to something in ranges that Gez posted.

Some of the limitations may pose a problem, though, at least the spawning, collision checks and autoaim should work. Sound and monster AI are probably not fixable, though. And better not think about polyobjects at all, portals on polyobjects would cause some major headaches anyway.

Polyobjects already work. I just don't have reverse collision detection for lines that bump into actors, not actors that bump into lines, so a moving portal will just push anything in front of it with it's portal line... And portals on polyobjects won't cause major headaches. They work naturally (i.e. I didn't write a single line of code yet to make portals work with polys specifically) and enable us to make whole vehicles with walkable interior — think of subway trains in Duke Nukem 3D.
For sound and monster AI, I'm pretty sure that I'll be able to do it (Eternity Engine did it, after all).

BTW, how did you get around the issue with mirrors that requires empty space behind them? Your portals clearly don't need that.

The obvious way: I'm clipping every line and sprite drawn [inside the portal/mirror] with portal/mirror plane and discard everything behind it. I'm also clipping every drawn sprite column [outside the portal/mirror] against portal drawsegs to avoid sprites behind the portal leaking through.

[Tormentor667]

Omg... could this really happen?! O_o

[Graf Zahl]

Since the render side of this feature already works surprisingly well, I don't see why not.
Just one caveat for GZDoom: Due to the way sprite clipping is done it may become a bit tricky to handle transitioning objects in the GL renderer as they need to be split up before drawing them. It won't be impossible but it sure adds a bit of overhead

[edward850]

I assume the logic side of it will be finished first beforehand? I would hate to see this merged into ZDoom with none of the logic properly sorted out. Namely tracers, AI and sound seem to be the important ones.
Collision tests need to be done between hopping through portals. It's all too easy to get stuck in something on the other side.

[Graf Zahl]

As it is this is a great demo feature, but due to the issues it's a bit too rough right now, it still needs some work.

[Monsterovich]

Actors teleport
Hitscan teleports
Railgun teleports

Sweeeeeet.

[Gez]

Even just as a renderer-only feature for now, it'd be useful. I once made a Hexen map where the hub teleport (you know, the triangle structures) were prettified a bit by having a translucent camera texture displayed upon them, showing a different area. Using camera textures was an approximation of the effect I wanted to have, though, a real portal would have been better but obviously it didn't exist in the engine. It wasn't meant to be a seamless teleport effect at all, but an improved look for a teleport cabin. And since it can be turned on and off, I can also see the effect used for atmospheric purposes. Say you have a stormy map and when lightning strikes, the windows briefly display a different world outside.

All that to say I wouldn't mind if it were implemented first as a renderer-only effect, and later once the issues are worked out the teleport effect is added through a parameter.

[ZZYZX]

I assume the logic side of it will be finished first beforehand? I would hate to see this merged into ZDoom with none of the logic properly sorted out. Namely tracers, AI and sound seem to be the important ones.
Collision tests need to be done between hopping through portals. It's all too easy to get stuck in something on the other side.

This is why collision is listed under 'todo'. I personally wouldn't even think about merging this with anything until at least collision and tracers (thinking of autoaim right now) work.

[NeuralStunner]

I'm hoping any success with transfers (collision etc. ) through the portal could be duplicated with stacked sectors as well. It might end up being simpler in some cases, IIRC sound only traverses sectors horizontally.

[Nash]

@Nash: Don't get carried away. This isn't even in a releasable state yet and you already ask for some far more complex stuff.

I'm not asking for them, it was just an enquiry to the developer. :D

So ZZYZX, care to comment on my questions? Would they ever be possible or 0% chance of ever happening? And by no means is this a demand, they're just questions because I am curious. I know things are still pretty early right now but it's awesome enough already even if it's just render-only. But since in your OP you said there are features more than just rendering... I am curious.

Would it eventually be possible to use wall portals on 2-sided lines? Upper and lower textures?

And is the teleport code easy to port to floor portals too?

[ZZYZX]

Would it eventually be possible to use wall portals on 2-sided lines? Upper and lower textures?

The rendering part will probably be easy, since visually a portal is just two top/bottom clip lines (which can be located at bottom/upper side only, I believe). The physics part will be harder because collisions... (right now due to how Doom works you can't move inside a two-sided ledge even with noclip — you will just end up being on top of it, thus you won't be able to simply walk into the portal that's not spanning the whole sector height).

Making this work on 2-sided lines is probably just few hacks to make a portal drawseg from 2-sided line, currently there aren't any checks for portals in the code that renders 2-sided lines.

And is the teleport code easy to port to floor portals too?

Instant stuff (tracers, hitscan, rail) will probably be just copy+paste. Collisions would be easier probably since we would always know that since we're in a portal sector, then we can only collide with things that are also in the portal sector from the other side (or rather, in the area of the blockmap that corresponds to the other side).

tl;dr: 2-sided line is easy. Top/bottom textures are hard. Stacked sectors are somewhere in between, but probably closer to 'hard' as well.

Update: implemented collision between portals & updated binary.