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.
[SoftPoly] Map is being drawn behind closed door
Moderator: GZDoom Developers
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.
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.
Re: [SoftPoly] Map is being drawn behind closed door
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.
Re: [SoftPoly] Map is being drawn behind closed door
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.
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.
Re: [SoftPoly] Map is being drawn behind closed door
Committed a fix for this. Hopefully it won't cull things it isn't meant to cull.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [SoftPoly] Map is being drawn behind closed door
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.
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.
Re: [SoftPoly] Map is being drawn behind closed door
The suspicious part is the full logic in the software renderer, which looks like this:Graf Zahl wrote:So why is this "suspicious"?
Code: Select all
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;
...
}
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.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.