[4af8590] Problems with portals

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: [4af8590] Problems with portals

Re: [4af8590] Problems with portals

by NeuralStunner » Fri Apr 08, 2016 8:58 pm

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

Re: [4af8590] Problems with portals

by Graf Zahl » Fri Apr 08, 2016 1:26 pm

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.

Re: [4af8590] Problems with portals

by NeuralStunner » Fri Apr 08, 2016 12:58 pm

Graf Zahl wrote: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?

Re: [4af8590] Problems with portals

by Graf Zahl » Fri Apr 08, 2016 9:42 am

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.

Re: [4af8590] Problems with portals

by Edward-san » Fri Apr 08, 2016 9:37 am

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?

Re: [4af8590] Problems with portals

by Graf Zahl » Thu Apr 07, 2016 11:35 am

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

Re: [4af8590] Problems with portals

by Graf Zahl » Thu Apr 07, 2016 10:11 am

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.

Re: [4af8590] Problems with portals

by _mental_ » Thu Apr 07, 2016 9:50 am

Good to know :roll: 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.

Re: [4af8590] Problems with portals

by Graf Zahl » Thu Apr 07, 2016 9:41 am

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

Re: [4af8590] Problems with portals

by Graf Zahl » Thu Apr 07, 2016 9:15 am

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.

Re: [4af8590] Problems with portals

by Graf Zahl » Thu Apr 07, 2016 9:04 am

_mental_ wrote:[*]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.

Re: [4af8590] Problems with portals

by Graf Zahl » Thu Apr 07, 2016 8:57 am

_mental_ wrote: [*]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.

[4af8590] Problems with portals

by _mental_ » Thu Apr 07, 2016 8:37 am

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.
Attachments
portaltest.wad
(2.28 KiB) Downloaded 35 times

Top