[Added] Wall portals

[Gez]

Here's a modified test file. It features pretty much all the test files in one, plus more fun. Weapons are provided to test them a bit through the portals. This includes altfires for the rocket launcher (grenades), plasma rifle (railgun) and BFG 9000 (press release plasma spam).

Navigating through the level is easy yet possibly confusing.

[ZZYZX]

Your mirror in the tram shows me that it's actually broken, not the lines around it TY, now I know what to look for and where to test it.
Also in the zombie hallway there's a portal that I couldn't pass through (and rockets don't pass through, either, but hitscan passes through). Is that a bug or intended? (don't have DB here right now)

update: seems to be a bug, things passing through the portal get obstructed by lines BEHIND the RECEIVING portal plane... will fix
update #2: fixed/broke collision behind portals again, zombie hall works correctly (but I might have killed something useful somewhere), mirror is still buggy and I don't know what's up with it
update #3: in your map, the portal that switches on/off... it's exit point in the hallway is broken (after I turn the portal off and on again, it links with WRONG portal and the original endpoint remains turned off).

[Gez]

Yeah, the switches were broken because I waffled a bit about how to renumber the lines and the script may have been partially reverted at some point.

I have fixed it and made the level a little bit more confusing.

I figure the polyobject rave floor can be useful for testing being swallowed by polyportals. In the meanwhile, it's a good way to get dizzy.

Edit: updated file with some 3D floors because why not. There's some funkiness going on with the sides of 3D floors. Looks like when a portal has a height difference, the 3D floor isn't shifted appropriately. And/or maybe a 3D floor gets drawn only once?

[mallo]

I just tried out Gez's demo and it crashed after nth going through a portal :/ Also, when a cacodemon and zombieman tried to go trough a portal at the same time, they started flickering stupidly and were stuck in place.

[Gez]

For some reason, it's the shotgunner's portal that crashes the most often for me. At one point it happened everytime I went though it after having cleared the Pac-Man stage, though lately it hasn't been as regular an occurrence.

[ZZYZX]

Edit: updated file with some 3D floors because why not. There's some funkiness going on with the sides of 3D floors. Looks like when a portal has a height difference, the 3D floor isn't shifted appropriately. And/or maybe a 3D floor gets drawn only once?

There's some funkiness going on with the planes of 3D floors as well... It's pretty surprising that kgsws stored player's view height somewhere else aside from global viewz variable (which I change when rendering portals). holy shit, this seems to be caused by the fact that 3D floors are drawn within R_DrawMasked that happens AFTER everything else (including viewz changes).
Also the crashes, I've been getting them as well yet too rarely to debug in any way. Of course going to find the cause and fix, just not sure when.
Oh, and Ive also noticed that sprites inside portals are mysteriously disappearing on this new test map.

[Gez]

I tried and failed to create an infinite stairway effect with portals -- you go and go but stay in roughly the same place and you can still get out of the loop by going back. Instead, I've mostly managed to create infinite stairways that went the other way I wanted, shortened stairways, and HOMs. Looks like this trick will remain a silent teleport exclusive.

Question: would it be feasible for portals to be translucent? Give them a flag and then one of the parameters work as alpha value for the portal scene, with the "real" geometry behind blending in (possibly including the linedef itself, if it has a texture).

[Graf Zahl]

There's some funkiness going on with the planes of 3D floors as well... It's pretty surprising that kgsws stored player's view height somewhere else aside from global viewz variable (which I change when rendering portals). holy shit, this seems to be caused by the fact that 3D floors are drawn within R_DrawMasked that happens AFTER everything else (including viewz changes).
Also the crashes, I've been getting them as well yet too rarely to debug in any way. Of course going to find the cause and fix, just not sure when.
Oh, and Ive also noticed that sprites inside portals are mysteriously disappearing on this new test map.

Welcome to the fun that is ZDoom's software renderer. I have long given up to try to understand this mess...

[ZZYZX]

I tried and failed to create an infinite stairway effect with portals -- you go and go but stay in roughly the same place and you can still get out of the loop by going back. Instead, I've mostly managed to create infinite stairways that went the other way I wanted, shortened stairways, and HOMs. Looks like this trick will remain a silent teleport exclusive.

I will just remove the check for Line_SetPortal destination being a Line_SetPortal. It doesn't make much sense anyway, should be replaced with a proper check for actor not being blocked by the receiving line.

Question: would it be feasible for portals to be translucent? Give them a flag and then one of the parameters work as alpha value for the portal scene, with the "real" geometry behind blending in (possibly including the linedef itself, if it has a texture).

I believe it's relatively easy to make portals translucent.
Basically, this is how I see it:
1) skip translucent portals in normal portal cycle
2) draw them in R_DrawMasked instead (since I'm already working on moving R_DrawMasked call into R_EnterPortal/R_EnterMirror, this shouldn't be a problem)
3) for each translucent portal, we have left/right x coordinates and top/bottom y clipping lines. These lines can be used to save the corresponding shape of already rendered map behind the portal, then display the portal, then restore the shape and render the portal on top of it via translucency table.

The only problem here is performance loss. No, PERFORMANCE LOSS. Basically we will be copying the shape about 5 times (original -> buffer1, portal -> screen, screen -> buffer2, buffer1 -> screen, buffer2 -> screen (+translucency))
This will be much faster if I just render to offscreen surface, but I haven't ever tried to do that (and not doing it anytime soon until the more important rendering glitches aren't fixed).

Welcome to the fun that is ZDoom's software renderer. I have long given up to try to understand this mess...

Also the software renderer isn't really that much of a mess once I try to read and understand it (or at least read and understand how to reuse it).

ALSO I suddenly got a crash inside P_ActivateLineSpecial on either thing->Activate(trigger); or thing->Deactivate(trigger);

---

And this is rather strange because in the disassembly/decompiled variant, it looks like the optimizer merged two parts of the if statement and instead of

Code: Select all • Expand view

      // Can it be activated?
      if (thing->activationtype & THINGSPEC_Activate)
      {
         thing->activationtype &= ~THINGSPEC_Activate; // Clear flag
         if (thing->activationtype & THINGSPEC_Switch) // Set other flag if switching
            thing->activationtype |= THINGSPEC_Deactivate;
         thing->Activate(trigger);
         res = true;
      }
      // If not, can it be deactivated?
      else if (thing->activationtype & THINGSPEC_Deactivate)
      {
         thing->activationtype &= ~THINGSPEC_Deactivate; // Clear flag
         if (thing->activationtype & THINGSPEC_Switch)   // Set other flag if switching
            thing->activationtype |= THINGSPEC_Activate;
         thing->Deactivate(trigger);
         res = true;
      }

does this:

Code: Select all • Expand view

      if ( result & 0x100 )
      {
        v8 = result & 0xFFFFFEFF;
        v6->activationtype = v8;
        if ( v8 & 0x400 )
          v6->activationtype = v8 | 0x200;
        v9 = v6->baseclass_0.baseclass_0.vfptr[2].StaticType;
      }
      else
      {
        if ( !(result & 0x200) )
          goto LABEL_19;
        v10 = result & 0xFFFFFDFF;
        v6->activationtype = v10;
        if ( v10 & 0x400 )
          v6->activationtype = v10 | 0x100;
        v9 = v6->baseclass_0.baseclass_0.vfptr[2].__vecDelDtor;
      }
      result = ((int (__thiscall *)(_DWORD, _DWORD))v9)(v6, v5); // <--- BOOM, crashes with null pointer read on "call ..." opcode
      v4 = 1;

No idea how a method from AActor's vtable could be NULL without breaking any other place prior to this call where it references thing's fields.

[Gez]

I will just remove the check for Line_SetPortal destination being a Line_SetPortal. It doesn't make much sense anyway, should be replaced with a proper check for actor not being blocked by the receiving line.

Good that'll allow cool tricks like linking a real portal with a visual portal, or having monsters crawling out of the walls.

I believe it's relatively easy to make portals translucent. <snip> The only problem here is performance loss.

Okay, not something to use like I did on the polyobject disco floor (at least not until optimizations are done). Still it'll be extremely cool to see.

Speaking about bugs and glitches, I often get freezes here:

To reproduce, go to that room, look at the "broken mirror" portal (it's broken because it doesn't reflect like the line mirror effects besides it, get it :V) and strafe left and right a bit.

---

The slime trail appears a bit earlier than the freeze, but it's always present when it freezes. It actually very slowly grows during the freeze, after a few minutes it looks like this:

---

Then eventually the program aborts, if you haven't stopped it first:

Code: Select all • Expand view

Execution could not continue.

Could not realloc 268435456 bytes

So it looks like there's potential for an infinite loop somewhere?


Hey, couldn't portal planes beyond the recursion limit be filled by a solid color (probably black)? It'd avoid HOMs in infinite hallways with low portal recursion.

[ZZYZX]

Update (and also a commit).

Separated R_DrawMasked among portals (well, actually, the global vissprite and drawseg list is still there, it's just that I'm calling R_DrawMasked multiple times and pretend that vissprites/drawsegs don't exist if they aren't from the current portal).
This fixed multiple issues, including sprite clipping in Z portals (i.e. sprite clipping against normal, 2D height differences), middle texture rendering in Z portals and 3D floor rendering in Z portals.

The P_ActivateLineSpecial crash is still there, as well as Gez's slime trail.
By the way, Gez, could you test it on your PC with this new binary? Because for me it doesn't lag for minutes, it just displays the trail and then crashes within a second. Not sure if this is caused by the new code or by my RAM amount :/

[Gez]

I got a crash in the first room as I was turning to choose my direction. "Code: C0000005 (Access Violation - tried to read address 0000000C) Address: 005439DF"

Didn't happen the second time. I got to move around a bit, see that there's still massive problems with 3D floors, and then I went to the "broken mirror". Caught a glimpse of the slime trail for a short fraction of a second, then nothing, then crash. "Code: C0000005 (Access Violation - tried to read address 03223024) Address: 005439DD" No freeze anymore, it crashes.

Oh yeah, I said the 3D floors still had problems: sometimes their side textures are drawn as a solid wall. (I should put some translucent 3D floors and see what happens.)

---

Note that most of those are 3D floors seen directly, not through a portal. Third pic caught an error in the rendering of a 3D floor through a portal.

It also happens through portals, though:

---

The view flickers back and forth between these two incorrect renderings.

[ZZYZX]

Fixed 3D floor rendering. I think that translucent 3D floors shouldn't be a problem now as well. With the previous binary some floors were drawn multiple times.

[Gez]

Got a crash when approaching the portal on the south-east of the start room leading to the polyobject disco room. ("tried to read address 0000000C") Pretty frequent crash in the disco room itself.

3D floor rendering seem to work fine now though.

[StrikerMan780]

I have to say this is very, very cool and impressive. Good work. I can only imagine the mapping possibilities with this being fully implemented.