Vissprites are now only clipped against their respective portal's geometry obtained from their BSP run.
Additionally, if a portal is provided, they're clipped to the portal's clip boundaries.
The work on this branch should conclude after a pair of remaining glitches are fixed.
The drawnodes are now fully grouped in separate lists, and then sorted individually. This fixes sorting problems caused by portals belonging to differently perceived scales (skyboxes for example).
Drawsegs and vissprite/drawnode sorting require the viewz, so the viewz is stored for each portal/view, and then restored when needed; without this, the rendering process erroneously sorts the elements, and draws some at wrong positions.
Each shall eventually have its specific vissprites/drawsegs; currently only drawsegs are stored in their correct list, vissprites are stored in the first list as a placeholder.
The idea is to sort each list individually, and then render their masked elements, starting from the last drawnode list.
This retains a non-recursive function calling method while still rendering things in order.
It seems to screw up the portal rendering in odd ways if it's in the wrong position. I apologize for not even knowing what it's meant to do nor how it works.
The skybox rendering process has been replaced with portals instead. Those are generated after the first BSP tree pass by looking for existing sky visplanes at the time, and their windows are used to define new portals.
The skybox portals are still incomplete and cause visual glitches when masked elements are involved.
Split portal-related code to its own source files.
Most of the 2-line-specific setup has been moved to the function which adds a 2-line case. The portals should render as they used to so far, anyway.
This makes it follow the sprites a bit better on slopes. Also split into a sub-function so that Banana doesn't need the duplicated code anymore.
The accuracy can be further improved on by doing the calculation 3 extra times for every surface, for each corner of the hitbox -- it wouldn't be THAT much more expensive, but it would only make subtle differences on sector boundaries that we usually zoom past anyway, so I figured it wasn't worth it. (It'll be easy enough to do so if we decide that we want the uber-accuracy)
