Wall portals

[ZZYZX]

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).

[Gez]

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

[ZZYZX]

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.

[Kinsie]

A weapon decorate flag for controlling portal self-damage on hitscans might be useful. +WEAPON.STOPHITTINGYOURSELF?

[NeuralStunner]

I don't think hitscans or projectiles should ever be able to hit their firer unless specifically designed that way by the modder.

[ZZYZX]

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.

[Nash]

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

[ZZYZX]

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 all

376 = 0,		Line_SetPortal(tag, 0, 0)
377 = 0,		Line_SetPortal(tag, 0, 0)

Putting this:

Code: Select all

/****** 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?

[Blzut3]

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).

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.

[edward850]

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).

[Graf Zahl]

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.

[Blzut3]

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.

[ZZYZX]

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.

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.

[Graf Zahl]

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

[ZZYZX]

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).