[Added] Wall portals

Moderator: GZDoom Developers

Re: Wall portals

Postby ZZYZX » Mon Oct 27, 2014 1:50 pm

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

This is theoretically possible, and I'll probably try to do that after current bugs are fixed. Thought about it as well, although what I was going to do is just marking floor/ceiling of the receiving sector to follow (this will enable portals on elevators without dynamically adjusting the gap). Oh, also 2nd argument is reserved for non-UDMF maps (it's line ID).

Update: latest commit/binary fixes using things/lines through the portal and adds CVars for limits (r_mirror_recursions, r_portal_recursions for rendering, synchronized sv_portal_recursions for physics).
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby Gez » Tue Oct 28, 2014 3:26 pm

Looks like this has been undone. I shot at myself through a portal with railgun and chaingun, without effect.
Gez
 
 
 
Joined: 06 Jul 2007

Re: Wall portals

Postby ZZYZX » Wed Oct 29, 2014 3:19 am

Gez wrote:Looks like this has been undone. I shot at myself through a portal with railgun and chaingun, without effect.

Yes, I should probably make this changeable in some way (dmflag or mapinfo?), because hitscan and rail were never hitting the shooting player under any circumstances and this might be not what the player expects.
The other reason for disabling that was the fact that you still couldn't hit yourself with a projectile even through a portal. And if I just erase the "source" pointer of a projectile that goes through a portal, it probably will hit anything in it's way (including the player that fired it), but as well will break any special effects that might be there. So this waits for a more complex/complete solution.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby Kinsie » Wed Oct 29, 2014 7:04 am

A weapon decorate flag for controlling portal self-damage on hitscans might be useful. +WEAPON.STOPHITTINGYOURSELF?
User avatar
Kinsie
Dog Days
 
Joined: 22 Oct 2004
Location: MAP33
Discord: Find Me...
Twitch ID: thekinsie

Re: Wall portals

Postby NeuralStunner » Wed Oct 29, 2014 10:24 am

I don't think hitscans or projectiles should ever be able to hit their firer unless specifically designed that way by the modder.
User avatar
NeuralStunner
Not "Neutral"
 
 
 
Joined: 21 Jul 2009
Location: capital N, capital S, no space
Discord: NeuralStunner#4201
Operating System: Windows Vista/7/2008 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: Wall portals

Postby ZZYZX » Wed Oct 29, 2014 8:57 pm

Implemented portals between sectors with different height. See first post for details on line special changes and zdoomx_test.wad in the latest archive for working example.
Also I was coding this from 12PM to 5AM my time instead of sleeping, so it'd be cool if someone tested these new Z portals (and especially if someone tried playing normal levels with my ZDoom build, just to make sure that I didn't break existing physics).

Also I guess that implementing sight checks just got way harder...
...oh, and that bug with walking on things that stick out of a portal has been fixed.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby Nash » Thu Oct 30, 2014 4:21 am

I'm having so much fun just playing around in the demo map. Good work as always.

It's funny how going back, everyone was like... "ZDoom will never have EE's linked portals EVER" and BOOM this thread appears. Same thing with 3D floors... ZDoom will never have 3D floors in the software renderer... boom software 3D floors happens.

Makes me glad I'm still sticking around modding for ZDoom after all these years. :')

Hopefully I stick around long enough to see someone tackle models for the software renderer... >:)
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 ZZYZX » Thu Oct 30, 2014 6:10 am

Nash wrote:everyone was like... "ZDoom will never have EE's linked portals EVER" and BOOM this thread appears. Same thing with 3D floors... ZDoom will never have 3D floors in the software renderer... boom software 3D floors happens.

This is because it's enough for RH to say "I won't do it right now" to make whole ZDoom community believe that it's impossible (instead of doing it themselves).

Anyway. Does anyone here know why xlat breaks if I put a comment above these lines? ZDoom then just ignores both directives.
Code: Select allExpand view
376 = 0,      Line_SetPortal(tag, 0, 0)
377 = 0,      Line_SetPortal(tag, 0, 0)


Putting this:
Code: Select allExpand view
/****** Eternity linetypes ******/

above Line_SetPortal xlats is enough for ZDoom to start ignoring them already.

Also why is there xlat/eternity.txt file if it's not used directly and not included from anywhere?
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby Blzut3 » Thu Oct 30, 2014 6:43 am

Nash wrote:Hopefully I stick around long enough to see someone tackle models for the software renderer... >:)

All models in the software renderer requires is someone willing to write a triangle rasterizer. This is just not something any of us are interested in since there would be basically no code reuse from any other part of the renderer, so in that sense it's quite hard.

Honestly though, I am a bit surprised that the requirement of void space behind mirrors was able to be lifted. But it goes to show that we're not all knowing either. ;) As far as this thread goes, I know Randi has talked about doing linked portals later, and I know I mentioned that mirrors are a limited form of wall portals in some other thread. So I don't know where the notion of it being impossible came from (as ZZYZX said).
ZZYZX wrote:Also why is there xlat/eternity.txt file if it's not used directly and not included from anywhere?

Eternity has some conflicting line specials compared to ZDoom Doom format. The Eternity xlat is included for compatibility and can be loaded by the command line or explicitly by a mod (Eternity+ZDoom compat is sort of becoming a thing).

I don't know what's up with the comments breaking the script though.
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 edward850 » Thu Oct 30, 2014 6:53 am

Nash wrote:It's funny how going back, everyone was like... "ZDoom will never have EE's linked portals EVER" and BOOM this thread appears.

You'll be hard pressed to find a developer here who actually explicitly said "never". There is a big difference between the words "can't" and "never" in the context of software development. ;)
"Can't" implies that the current methods prevent a sane implementation of something, either because of the length of time it would take or otherwise. Usually, it would take someone completely different who can dedicate their time to it.
"Never" implies that it won't be willing done due to development practices required or it being completely out of scope for the project in question.

There's essentially 3 different languages being spoken on the forums, which comes with the conditions of having 3 different types of groups: Programmers, the actual user base, and modders. The meaning behind various words tend to get confused because of this. It's actually rather fascinating in a development perspective (although it sure can get annoying sometimes).
User avatar
edward850
[netcode intensifies]
 
Joined: 19 Jul 2005
Location: New Zealand

Re: Wall portals

Postby Graf Zahl » Thu Oct 30, 2014 7:39 am

Blzut3 wrote:Honestly though, I am a bit surprised that the requirement of void space behind mirrors was able to be lifted. But it goes to show that we're not all knowing either. ;)




To be honest, I am not. It was a rather arbitrary restriction coming from limitations in the clipping code that shouldn't be hard to remove.
The same is true for obstructing geometry between the camera and a stacked sector portal. I'm fairly certain that the approach I implemented in GZDoom is functional for the software renderer as well - you just have to find someone who is willing to work with that mucked up code.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby Blzut3 » Thu Oct 30, 2014 7:47 am

Graf Zahl wrote:The same is true for obstructing geometry between the camera and a stacked sector portal. I'm fairly certain that the approach I implemented in GZDoom is functional for the software renderer as well - you just have to find someone who is willing to work with that mucked up code.

I'm not sure what technique you're using in GL, but I'm thinking the same technique used for mirrors/wall portals can be extended to floor/ceiling portals as well since there's no real pitch. The trick is finding the nearest drawseg to the portal and clipping everything between the it and the player. But I can't say I'm particularly knowledgeable on the subject, so I should probably defer to ZZYZX.
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 30, 2014 7:59 am

Blzut3 wrote:All models in the software renderer requires is someone willing to write a triangle rasterizer. This is just not something any of us are interested in since there would be basically no code reuse from any other part of the renderer, so in that sense it's quite hard.

I've seen that some other guy proposed converting models into voxels at runtime, and obviously people told him that it'd be too slow. But the point that everyone missed there, is that models can be converted into voxels during loading and thus produce somewhat usable result (definitely better than totally no models visible). Although it won't probably be usable for HUD weapons, at least not as-is.

Blzut3 wrote:The trick is finding the nearest drawseg to the portal and clipping everything between the it and the player.

Actually, no, it wouldn't work correctly (because we need to make sure that our clipping line clips things behind the portal, not behind the drawseg, and the drawseg can be oriented in any way even if it's really the nearest).
Now, the portal back side clipping isn't done using drawsegs, it's done using lines (as in, arbitrary lines in world coordinates). That is, you can calculate some line that resides on the nearest VERTEX of the visible portal and faces away from the player, and clip everything that's behind this imaginary line.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Wall portals

Postby Graf Zahl » Thu Oct 30, 2014 8:54 am

Blzut3 wrote:
Graf Zahl wrote:The same is true for obstructing geometry between the camera and a stacked sector portal. I'm fairly certain that the approach I implemented in GZDoom is functional for the software renderer as well - you just have to find someone who is willing to work with that mucked up code.

I'm not sure what technique you're using in GL, but I'm thinking the same technique used for mirrors/wall portals can be extended to floor/ceiling portals as well since there's no real pitch. The trick is finding the nearest drawseg to the portal and clipping everything between the it and the player. But I can't say I'm particularly knowledgeable on the subject, so I should probably defer to ZZYZX.



Of course I don't use drawsegs because no such thing exists in the hardware renderer.

What I do is to use all front-facing lines of the portal border to discard everything between the portal and the camera. That doesn't assume anything renderer specific so it should be portable
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Wall portals

Postby ZZYZX » Thu Oct 30, 2014 9:14 am

Basically this is what I'm doing to the wall portals. Looks pretty close to what Graf described.
First argument is the line that will get clipped, second argument is the current portal line (i.e. endpoint of the portal that we're drawing into), and x/y are coordinates of the viewer (because this clipper is also used in sight obstruction checks, so explosions from within the portal don't get blocked by "real" lines behind the portal).
Last edited by ZZYZX on Thu Oct 30, 2014 2:52 pm, edited 1 time in total.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

PreviousNext

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 0 guests