[Added] Wall portals

Moderator: GZDoom Developers

Wall portals

Postby ZZYZX » Tue Oct 21, 2014 1:53 am

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.

Spoiler: Video


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 :wink: )

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.
Spoiler: Differences to the old version
Last edited by ZZYZX on Sun Feb 01, 2015 2:18 pm, edited 110 times in total.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: Wall portals

Postby Gez » Tue Oct 21, 2014 2:54 am

That seems very promising. :D

ZZYZX wrote: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 allExpand view
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.
Last edited by Gez on Tue Oct 21, 2014 3:00 am, edited 1 time in total.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Wall portals

Postby Nash » Tue Oct 21, 2014 2:55 am

Image

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?
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: Wall portals

Postby Graf Zahl » Tue Oct 21, 2014 3:19 am

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

Re: Wall portals

Postby ZZYZX » Tue Oct 21, 2014 3:27 am

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

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

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

Graf Zahl wrote: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.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: Wall portals

Postby Tormentor667 » Tue Oct 21, 2014 5:16 am

Omg... could this really happen?! O_o
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

Re: Wall portals

Postby Graf Zahl » Tue Oct 21, 2014 5:38 am

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

Re: Wall portals

Postby edward850 » Tue Oct 21, 2014 6:53 am

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.
Last edited by edward850 on Tue Oct 21, 2014 7:19 am, edited 1 time in total.
User avatar
edward850
[netcode intensifies]
 
Joined: 19 Jul 2005
Location: New Zealand

Re: Wall portals

Postby Graf Zahl » Tue Oct 21, 2014 7:10 am

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

Re: Wall portals

Postby Monsterovich » Tue Oct 21, 2014 7:34 am

Actors teleport
Hitscan teleports
Railgun teleports


Sweeeeeet. :)
Monsterovich
 
Joined: 12 Apr 2014

Re: Wall portals

Postby Gez » Tue Oct 21, 2014 7:46 am

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

Re: Wall portals

Postby ZZYZX » Tue Oct 21, 2014 7:51 am

edward850 wrote: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.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Re: Wall portals

Postby NeuralStunner » Tue Oct 21, 2014 11:28 am

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.
User avatar
NeuralStunner
An Exercise in Self-Indulgence
 
 
 
Joined: 21 Jul 2009
Location: Indiana, USA
Discord: NeuralStunner#1293
Operating System: Windows Vista/7 64-bit

Re: Wall portals

Postby Nash » Tue Oct 21, 2014 3:42 pm

Graf Zahl wrote:@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?
User avatar
Nash
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Github ID: nashmuhandes

Re: Wall portals

Postby ZZYZX » Tue Oct 21, 2014 10:02 pm

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

Nash wrote: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.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine

Next

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 2 guests