[4af8590] Problems with portals

[_mental_]

I made a very simple test with two boxes to check portals. After floating pointer merge I encountered several issues on this map:

• From starting point a portal is visible in ZDoom. However in GZDoom it's just black (like no texture was assigned to a line). From other room however it's visible but another wall isn't rendered. ZDoom renders portals correctly in any case.
• It's possible to move out of the rooms if player moves straight into a wall near a portal line.
• Sometimes player is stuck on portal line instead of moving through. It seems this happens when moving closer to a wall.
• There is something like teleport flash sprite (for 1 tick?) when moving through portals using software renderer.

[Graf Zahl]

[*]There is something like teleport flash sprite (for 1 tick?) when moving through portals using software renderer.[/list]

That's the player sprite. The logic for disabling that on portal transitions is not working properly yet.

[Graf Zahl]

[*]Sometimes player is stuck on portal line instead of moving through. It seems this happens when moving closer to a wall.

Sigh...

I don't know how often I said that you should *NOT* put portals on one sided walls because the phyics code cannot cope with it. This is a classic symptom of that.
And yet, EVERY SINGLE portal test map is doing that.
Why???

Had you done it properly it would work.

[Graf Zahl]

So congratulations, you made me reevaluate my decision to allow portals on one-sided lines outside portals because Eternity does. These are no longer possible.
Your third point, i.e. getting teleported into the void is also caused by this.

[Graf Zahl]

The GZDoom issue is fixed. The rest ist either [Can't fix] or [Duplicate].

[_mental_]

Good to know OK then, physics "bugs" are out of question.
Interestingly, when I made portals back sides 32 units "deep", player can pass in one direction but cannot go back. 64 units works fine anyway.
Honestly I made this bug report mostly because of rendering problems.

[Graf Zahl]

That's all not really surprising with the physics. You need at least as much space behind the portal as the actor can travel at most. For a player that's approx. 40 map units. The biggest problem is the sliding code which just cannot work with portals and is responsible for both glitches you experienced.

The player sprite glitch is another of those things that are more complicated than they look. It's really not easy to decide whether the player is crossing the portal or just looking at himself from somewhere else. The first case must hide the sprite, the second one must show it.

And the camera interpolation code for portals is messy enough already, but it has to track even more info that it already does.

[Graf Zahl]

The player sprite issue should be fixed now, too, but this will require some testing if it has side effects.

[Edward-san]

Regarding the required space behind the portal, it should be around half the portal's line length, because, uh, mods could define an actor as big (in x/y coords) as the portal line, right?

[Graf Zahl]

The general rule should be that there should be enough space behind a portal for the largest actor that might possibly cross it to fit through. You also have to consider movement speed.
Not every map has a Spider Mastermind so even for wide portals it may not need to be considered.

[NeuralStunner]

The general rule should be that there should be enough space behind a portal for the largest actor that might possibly cross it to fit through. You also have to consider movement speed.

Is movement substepping factored into this?

[Graf Zahl]

It's part of the value you ultimately need. That's one of the reasons why some generic advice like 'half the diameter of xyz' isn't sufficient.

[NeuralStunner]

It's a little more limiting that way, but on the plus side, it's going to be much harder to make a thousand "teehee mindfcuk" maps.