[Added] Wall portals

Moderator: GZDoom Developers

Re: Wall portals

Postby Tormentor667 » Thu Oct 23, 2014 2:21 am

I am out of Doom for a while now but seeing this heats up my creativity :)
User avatar
Tormentor667
needs more detail
 
Joined: 16 Jul 2003
Location: Germany

Re: Wall portals

Postby mallo » Thu Oct 23, 2014 8:59 am

Nash wrote: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)
User avatar
mallo
GO TO NEXT SECTOR.
 
Joined: 22 May 2010
Location: Once upon a land in a far off time

Re: Wall portals

Postby ZZYZX » Thu Oct 23, 2014 9:11 am

Hurrrr. I've put in wrong zdoom.exe...
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby mallo » Thu Oct 23, 2014 9:37 am

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.
User avatar
mallo
GO TO NEXT SECTOR.
 
Joined: 22 May 2010
Location: Once upon a land in a far off time

Re: Wall portals

Postby ZZYZX » Thu Oct 23, 2014 10:08 am

mallo wrote: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.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby GFD » Thu Oct 23, 2014 2:12 pm

ZZYZX wrote:
gamefreakdude wrote: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.
User avatar
GFD
My brain's probably worth a lot of money!
 
Joined: 31 May 2010
Location: Canada

Re: Wall portals

Postby Nash » Thu Oct 23, 2014 5:57 pm

^ 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.
User avatar
Nash
Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: Wall portals

Postby Blzut3 » Thu Oct 23, 2014 11:02 pm

ZZYZX wrote: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.
Blzut3
Pronounced: B-l-zut
 
 
 
Joined: 24 Nov 2004
Github ID: Blzut3
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit
Graphics Processor: ATI/AMD with Vulkan Support

Re: Wall portals

Postby ZZYZX » Thu Oct 23, 2014 11:50 pm

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

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

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

Blzut3 wrote: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 allExpand 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:
Image

Seems to fix the issue with walls on the back side of the portal suddenly being drawn over everything.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby TheMightyHeracross » Fri Oct 24, 2014 5:47 am

Works on polyobjects? Holy cow. :o
User avatar
TheMightyHeracross
...and remember: his silence is golden.
 
Joined: 18 Aug 2013
Location: Philadelphia, PA
Discord: TheMightyHeracross#1716
Operating System: Debian-like Linux (Debian, Ubuntu, Mint, etc) 64-bit

Re: Wall portals

Postby Gez » Sun Oct 26, 2014 6:48 am

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

Re: Wall portals

Postby ZZYZX » Sun Oct 26, 2014 8:38 am

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

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

Gez wrote:Finally, some HOMs

I have no idea why that happens or how to fix that. At least right now.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby Major Cooke » Mon Oct 27, 2014 9:54 am

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.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: Wall portals

Postby ZZYZX » Mon Oct 27, 2014 11:16 am

Major Cooke wrote: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.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby Gez » Mon Oct 27, 2014 11:22 am

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

PreviousNext

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests