[SoftPoly] Map is being drawn behind closed door

[Paar]

When using softpoly render the map renders geometry behind a closed door. It doesn't happen with any other renderer. You can try it with any door in any map (i.e. map01 in Doom 2).

Tested with GZDoom 3.6.0.

[Enjay]

It's not happening for me in either of the two softpoly modes in either 3.6.0 or a more recent Git build.





What's your graphics card and are your drivers up to date?

[Paar]

I mean a geometry on the automap. I will be drawn as if you have opened the door even though it is still closed. I will post screenshots later.

[Enjay]

Oh! I thought you meant in the game world.

Yup, I can walk up to the door in map01 in OpenGL mode and check the automap (nothing shown past the door), then enable softpoly and re-check the automap and now the area behind the door has been mapped.

[dpJudas]

Committed a fix for this. Hopefully it won't cull things it isn't meant to cull.

[Graf Zahl]

So why is this "suspicious"? The GL renderer needs to do mostly the same checks to yield identical results.

Regarding softpoly in general, since I've been working on abstracting the hardware renderer from the actual backing implementation, wouldn't it make sense to make softpoly just another backend to that instead of completely reinventing the wheel top to bottom? I think it could actually be cut down to the rasterization stuff if that was feasible and on the upside inherit all the render hack handling that is already there.

I'll be honest here: While i appreciate the idea of a software-based polygon renderer, having this as a completely separate piece of code with its own rules, limitations and quirks is probably not something that's going to work out.

[dpJudas]

So why is this "suspicious"?

The suspicious part is the full logic in the software renderer, which looks like this:

Code: Select all • Expand view

bool SWRenderLine::IsSolid() const
{
   // One sided
   if (mBackSector == nullptr) return true;

   // Portal
   if (mLineSegment->linedef->isVisualPortal() && mLineSegment->sidedef == mLineSegment->linedef->sidedef[0]) return true;

   // Closed door
   if (mBackCeilingZ1 <= mFrontFloorZ1 && mBackCeilingZ2 <= mFrontFloorZ2) return true;
   if (mBackFloorZ1 >= mFrontCeilingZ1 && mBackFloorZ2 >= mFrontCeilingZ2) return true;
   if (IsDoorClosed()) return true;

   return false;
}

bool SWRenderLine::IsDoorClosed() const
{
   if (!mBackSector) return false;

   // Portal
   if (mLineSegment->linedef->isVisualPortal() && mLineSegment->sidedef == mLineSegment->linedef->sidedef[0]) return false;

   // Closed door.
   if (mBackCeilingZ1 <= mFrontFloorZ1 && mBackCeilingZ2 <= mFrontFloorZ2) return false;
   if (mBackFloorZ1 >= mFrontCeilingZ1 && mBackFloorZ2 >= mFrontCeilingZ2) return false;

   ...
}


Notice that the checks are inverted in IsDoorClosed vs the checks in IsSolid. Now, the checks in IsSolid wins because they are made first, but this strongly indicates something is rotten in the IsDoorClosed version. I don't dare fully change/fix IsDoorClosed though because other parts of the software renderer calls that one directly and I'm not sure what I might break (or fix) by making this change.

Regarding softpoly in general, since I've been working on abstracting the hardware renderer from the actual backing implementation, wouldn't it make sense to make softpoly just another backend to that instead of completely reinventing the wheel top to bottom? I think it could actually be cut down to the rasterization stuff if that was feasible and on the upside inherit all the render hack handling that is already there.

Sure, that would work and is probably a good idea long in the long run. The main catch is mostly that the hardware renderer is able to brute force itself through some of the rendering where softpoly may need a little help. Mostly that overdraw is far more expensive for softpoly as its drawers are pretty slow when compared to a GPU.