[SoftPoly] Map is being drawn behind closed door

Moderator: Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

[SoftPoly] Map is being drawn behind closed door

Postby Paar » Mon Oct 22, 2018 2:11 pm

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.
Paar
 
Joined: 18 Apr 2008

Re: [SoftPoly] Map is being drawn behind closed door

Postby Enjay » Mon Oct 22, 2018 2:22 pm

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?
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: [SoftPoly] Map is being drawn behind closed door

Postby Paar » Mon Oct 22, 2018 3:07 pm

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.
Paar
 
Joined: 18 Apr 2008

Re: [SoftPoly] Map is being drawn behind closed door

Postby Enjay » Mon Oct 22, 2018 3:25 pm

Oh! I thought you meant in the game world. :oops:

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.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: [SoftPoly] Map is being drawn behind closed door

Postby dpJudas » Tue Oct 23, 2018 12:44 am

Committed a fix for this. Hopefully it won't cull things it isn't meant to cull. :)
dpJudas
 
 
 
Joined: 28 May 2016

Re: [SoftPoly] Map is being drawn behind closed door

Postby Graf Zahl » Tue Oct 23, 2018 2:21 am

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.
User avatar
Graf Zahl
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [SoftPoly] Map is being drawn behind closed door

Postby dpJudas » Tue Oct 23, 2018 3:51 am

Graf Zahl wrote:So why is this "suspicious"?

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

Code: Select allExpand 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.
dpJudas
 
 
 
Joined: 28 May 2016


Return to Software Renderer Bugs

Who is online

Users browsing this forum: No registered users and 1 guest