[Added] Wall portals

[Tormentor667]

I am out of Doom for a while now but seeing this heats up my creativity

[mallo]

Alright, thanks for the replies. Looking forward to see this progress! Good job!

Oh BTW I can't run the latest EXE:

Execution could not continue.

Script error, "zdoom.pk3:compatibility.txt" line 390:
Expected '}', got 'DisablePushWindowCheck'.

After updating few minutes ago I get this error too I've downloaded it about 2 hours ago on another computer and it worked fine.

Interesting is the fact that when loading ZDoom's 2.7.1's PK3 the game loads. (Well, except portals not working with it...) (I think you've put in wrong zdoom.pk3 in or something)

[ZZYZX]

Hurrrr. I've put in wrong zdoom.exe...

[mallo]

Noticed two more graphical glitches. The last one is from a custom map I've quickly made so I think I just built it wrong.

[ZZYZX]

Noticed two more graphical glitches. The last one is from a custom map I've quickly made so I think I just built it wrong.

If you have walls behind your portal and they get drawn, put a vertex on the same line as portal (or a bit behind it). It will work like this until I find a way to clip things properly (i.e. something like frustum culling). For improper sprite clipping, I'll try to fix that later.

Update: I really hate the fact that geometry and sprites are being drawn in two completely separate passes. I'm now trying to clip only things of same portal depth, seems to fix the issue. Binary/repo updated.

[GFD]

An observation that broke immersion was that the powered-up Skull Rod didn't spawn rain on the other side of the portal as one might logically expect.

http://i.imgur.com/MHA3sog.png

I guess I could've been more clear. Shooting the projectile through a portal works fine; impacting it just in front of a portal won't spawn rain on the other side of the portal, though, which is what one might logically expect. As in, instead of the rain spawning through the portal, they just spawn on the other side of the portal linedef. Man, this is confusing to explain. Does that make sense?
This issue might not be avoidable anyway, due to the nature of the weapon.

[Nash]

^ seems like the rain drops aren't being teleported through

On a similar note, would it be worth it/possible to create a flag that would purposely exclude an actor from portal teleporting? I'm sure modders woudl have a use for it.

[Blzut3]

I've implemented portals on 2-sided linedefs, but xlat is still impossible due to buffer floor/ceiling leaking into portal from the other side in ZDoom (apparently this won't happen in Eternity).

Hmm, I wonder if this is at all related to the reason Eternity requires that the "buffer sector" be a different lightlevel/texture. Forces the software renderer to stop flood filling and fixes mid texture bleeding?

In any case, the xlat doesn't need to be limitation-for-limitation compatible, but rather semantically compatible. It's up to the map author to account for implementation differences, and perhaps the limitations will be lifted in the future.

[ZZYZX]

^ seems like the rain drops aren't being teleported through

I'm not sure if they need to teleport through...

On a similar note, would it be worth it/possible to create a flag that would purposely exclude an actor from portal teleporting?

Not yet. After it's done.

Hmm, I wonder if this is at all related to the reason Eternity requires that the "buffer sector" be a different lightlevel/texture. Forces the software renderer to stop flood filling and fixes mid texture bleeding?

I fixed that leaking already. It was caused by not marking floor/ceiling while drawing 2-sided portal linedefs and the reason for different buffer light level in Eternity has nothing to do with it.

Code: Select all • Expand view

      else if (P_FindPortalEndPoint(line->linedef)
         
         // [ZZ] added portal check above everything because typical portal line will cause all these checks to be done... (although not in translated Eternity maps, they have lightlevel changed)
         || backsector->lightlevel != frontsector->lightlevel
         || backsector->GetTexture(sector_t::floor) != frontsector->GetTexture(sector_t::floor)
         || backsector->GetTexture(sector_t::ceiling) != frontsector->GetTexture(sector_t::ceiling)
         || curline->sidedef->GetTexture(side_t::mid).isValid()


This is the beginning of the code that checks whether a line should be drawn (portal part added by me, obviously). Eternity author apparently doesn't do this, and because of it he needs another check to pass in order for portal line to be drawn... And obviously they recommend us to use lightlevel since it's the first check.

Anyway, updated. Walls drawn inside portals/mirrors now get clipped by this shape:


Seems to fix the issue with walls on the back side of the portal suddenly being drawn over everything.

[TheMightyHeracross]

Works on polyobjects? Holy cow.

[Gez]

Just a comment: in a few places I've seen you've hardcoded portal recursions to 5 (e.g. here). You should make it a CVAR, like r_mirror_recursions, or a #define constants, just so that it's guaranteed to stay the same value in all places.


Bugs (from the Oct 25 test binary): in the polyobject test, activating the door from the outside is hard. I only manage to do it at an angle. Moving partly "inside" the doorway but still technically outside the portal area (centerpoint it out) then waiting for the door to close, the door closes over you. Opening or closing the door and moving away from the portal room makes the missing sound transfer quite blatant. Finally, some HOMs:

[ZZYZX]

Just a comment: in a few places I've seen you've hardcoded portal recursions to 5 (e.g. here). You should make it a CVAR, like r_mirror_recursions, or a #define constants, just so that it's guaranteed to stay the same value in all places.

I'll make it a CVAR, even three probably — r_mirror_recursions, r_portal_recursions and sv_portal_recursions. The last one will control how many recursions are handled by physics part.
Also current hardcoded number of recursions is 4 (inherited from rendering code). The number 5 is there because zero pass (actual position without teleporting) is counted as well (although it should be 6 probably, because first portalCount-- is already 4).

in the polyobject test, activating the door from the outside is hard. I only manage to do it at an angle.

Yep... I know about this and going to fix it in near future.

Finally, some HOMs

I have no idea why that happens or how to fix that. At least right now.

[Major Cooke]

Hate to derail, but since we're on the topic of recursion limiting... would it be possible for you to make floor and ceiling portal recursion limits? Since we're talking about limiting it, that's one thing I've always wanted to get, where I tried making a chamber where the floor and ceiling had holes to let the player fall through and pop out from the ceiling, but it just caused a crash when looking through one.

[ZZYZX]

Hate to derail, but since we're on the topic of recursion limiting... would it be possible for you to make floor and ceiling portal recursion limits? Since we're talking about limiting it, that's one thing I've always wanted to get, where I tried making a chamber where the floor and ceiling had holes to let the player fall through and pop out from the ceiling, but it just caused a crash when looking through one.

Not quite sure if this is possible since floor/ceiling portals are skyboxes and are drawn along with all other skyboxes... Noted, though.

[Gez]

Question on feasibility: would it be possible to have vertical offsets for portals? Let's say we use the second parameter of the special for that. Suppose two identical doorways (as far as length and height are concerned) but one has its floor and ceiling both 128 units above the other. The lower linedef would have 156, 1, 128, and the upper linedef would have 156, 1, -128. If it's possible to connect with portals sectors at different heights, very interesting effects could be achieved.