Technically, the problem with the software renderer portal implementation is that it abused the plane list for storing the silhouette for sector portals. When it renders plane portals it does this:
Code: Select all
Thread->OpaquePass->RenderScene();
Thread->Clip3D->ResetClip(); // reset clips (floor/ceiling)
planes->Render();
That is then followed by an additional step where it draws the sprites:
Code: Select all
Thread->TranslucentPass->Render();
visplaneStack.Pop(pl);
if (pl->Alpha > 0 && pl->picnum != skyflatnum)
pl->Render(Thread, pl->Alpha, pl->Additive, true);
The line portals, on the other hand does this:
Code: Select all
Thread->OpaquePass->RenderScene();
Thread->Clip3D->ResetClip(); // reset clips (floor/ceiling)
Thread->PlaneList->Render();
RenderPlanePortals();
unsigned int portalsAtEnd = WallPortals.Size();
for (; portalsAtStart < portalsAtEnd; portalsAtStart++)
{
RenderLinePortal(WallPortals[portalsAtStart], depth + 1);
}
Thread->TranslucentPass->Render(); // this is required since with portals there often will be cases when more than
What is worth pointing about this code it that:
1) Sector recursion does not render portal lines, while line recursion does render the portal sectors.
2) Copy and paste of the Doom scene rendering steps (draw walls, draw planes, draw portals, draw translucent). Three code variants of this exists in the code now (original, line and sector).
3) All portal handling is done by pushing objects at the end of already existing lists, making it super important to know which range of objects belong to each portal. The tracking of this is, naturally, spaghetti'ed over the rest of the renderer.
You will not see me even attempt at touching this code unless I have a fully functioning softpoly portal implementation. This is because the only way I can fix the above issues is by merging #2 listed above into one draw scene function again, and that requires a 110% complete understanding of what it takes to draw the portals.
Reporting further which special cases actually works in the current software renderer will unfortunately not help getting it fixed. Thanks for the feedback, though.
Technically, the problem with the software renderer portal implementation is that it abused the plane list for storing the silhouette for sector portals. When it renders plane portals it does this:
[code]
Thread->OpaquePass->RenderScene();
Thread->Clip3D->ResetClip(); // reset clips (floor/ceiling)
planes->Render();
[/code]
That is then followed by an additional step where it draws the sprites:
[code]
Thread->TranslucentPass->Render();
visplaneStack.Pop(pl);
if (pl->Alpha > 0 && pl->picnum != skyflatnum)
pl->Render(Thread, pl->Alpha, pl->Additive, true);
[/code]
The line portals, on the other hand does this:
[code]
Thread->OpaquePass->RenderScene();
Thread->Clip3D->ResetClip(); // reset clips (floor/ceiling)
Thread->PlaneList->Render();
RenderPlanePortals();
unsigned int portalsAtEnd = WallPortals.Size();
for (; portalsAtStart < portalsAtEnd; portalsAtStart++)
{
RenderLinePortal(WallPortals[portalsAtStart], depth + 1);
}
Thread->TranslucentPass->Render(); // this is required since with portals there often will be cases when more than
[/code]
What is worth pointing about this code it that:
1) Sector recursion does not render portal lines, while line recursion does render the portal sectors.
2) Copy and paste of the Doom scene rendering steps (draw walls, draw planes, draw portals, draw translucent). Three code variants of this exists in the code now (original, line and sector).
3) All portal handling is done by pushing objects at the end of already existing lists, making it super important to know which range of objects belong to each portal. The tracking of this is, naturally, spaghetti'ed over the rest of the renderer.
You will not see me even attempt at touching this code unless I have a fully functioning softpoly portal implementation. This is because the only way I can fix the above issues is by merging #2 listed above into one draw scene function again, and that requires a 110% complete understanding of what it takes to draw the portals.
Reporting further which special cases actually works in the current software renderer will unfortunately not help getting it fixed. Thanks for the feedback, though.