[????-g869864]Polyobj door merging with adjacent sector line

[Edward-san]

Open the testdoor wad, load map01 and press the switch to open the door. You'll see the polyobject sides will disappear behind the wall. This didn't happen in zdoom r1551.

[Kappes Buur]

Ditto for GZDoom.
Works up to and including r865, but not with r888 or later to latest.
I don't have revisions in beteween, so I cannot pinpoint the exact revision when the behaviour changed.

[Edward-san]

in r883 the whole map is broken, in r884 the fix introduces the issue.

[Enjay]

I know that it might be a change but isn't this a "fair enough" kind of situation? I mean, the doors are 128 units long and they move 128 units placing the line that forms the edge of the door exactly on top of the line forming the wall. The engine has to decide which one to draw and, frankly, neither can be guaranteed to be the correct one. I'm actually surprised that GZDoom doesn't result in z-fighting of the textures.

Basically, it looks like bad mapping to me. A mapper shouldn't create a situation where two lines end up in the same place like this. To my mind, if the doors need to be flush with the wall, there should be an alcove for the poly to slide in to so that the door edge can never get hidden by anything because there isn't a textured line there for it to lie on top of. Or, stylistically better IMO, the doors should be set up so that they only move 124 or 120 units leaving a slight lip, making them consistent with other doors in the game.

[edward850]

Indeed. Like the order of script operations, this seems more undefined rather than intentional. Especially with dynamic BSPs, who knows which will come first? If you want to be sure the lines are drawn ahead, actually put them ahead.

[Edward-san]

in zdoom case, the problematic revision doesn't match the gzdoom one. Apparently I can reproduce starting from the automap merge (r2609), which is weird...

[edward850]

Because the GLBSP (which the textured automap uses) is changing the render order.

[Graf Zahl]

It's not just render order but also depth buffering.

This entire situation can be summed up as 'bad design'. If you have two lines occupying the same space there's no guarantee which one will be drawn first. I never understood why some people even ignore the most basic of design guides (keep the polyobject WITHIN valid geometry), and then complain if things don't work as expected. Had this door been done properly it would not glitch.

[Edward-san]

the strange thing is that the testdoor file is in zdoom.org ... who made it?

[edit]found it ... Rick Clark. Still, why's it there?

[Kappes Buur]

..... Still, why's it there?

Because the tutorial had been made many, many moons before the polyobject behaviour broke.
ZDoom at the time was in it's infancy, long before GZDoom came along.

Perhaps somebody could change the test pwad in the tutorial, or place a link to this thread for clarification.
I would do it ordinarily, but I cannot log into the WIKI to edit a page.

[Enjay]

There is one final question that I have which is raised by this map; the poly door fronts run along the line bordering the sector with the coloured light but the doors themselves are not affected by the light colour. If these were regular doors, they would be coloured by the lighting. Should poly doors behave the same way? I don't even know if its possible, but I thought it was worth asking.

Poly Door


Regular Door

[Ichor]

That's because the actual polyobject doors are in a different sector off on its own before it gets moved to this spot. Try coloring the sector where the polyobject anchors are.

[edward850]

Actually, the problem is exactly the same as before: Undefined orders. It's right on the line between two planes, so either sector is correct.

[Enjay]

That's because the actual polyobject doors are in a different sector off on its own before it gets moved to this spot. Try coloring the sector where the polyobject anchors are.

That was my initial thought but I tried it and it didn't work (as edward said it wouldn't). Even if it had worked, then the other side of the door, the one facing the uncoloured sector, would presumably have been coloured and that would be just as bad.

[edward850]

... I thought the youtube video explained the whole situation, Enjay.