This was supposed to get the same treatment as d_net.cpp, i.e get the old license restored and be released under a duplicate GPL/Doom Source license but it was somehow missed when it got added. Also removed all leftover Doom specific parts.
* the parser read numbers with leading zeros as octal, which is not wanted here
* texture lookup by file name must be forced for root directory entries.
* the parser read numbers with leading zeros as octal, which is not wanted here
* texture lookup by file name must be forced for root directory entries.
* Using the Doom-style dome here because it looks better.
* this necessitated changes to the backend to allow both types of sky domes at the same time
* do not clamp panning fields for cloudy sky with the new renderer because this makes the texture jump.
* Build skies need a different mesh for the dome - the one from GZDoom distorts them too much.
* made adjustment to the positioning math after redoing the mesh
* Exhumed abuses some strange effect of the original sky placement math which means the y-offsetting must be disabled for this game.
* RRRA sky initialization fixed. It must be done after setting up the tiles.
As it turned out, the triangulator only works fine for regular polygons, but creates incomplete meshes for sectors with multiple sections or some degenerate areas, which are quite common with swinging doors.
The node builder is more costly and creates wall splits, of course, but it does not create broken output for degenerate sectors so it's a good fallback.
* Reduce code repetition.
* Clamp incoming horizon when using `settarget()` methods.
* Eliminate double calculation that was occurring in `processhelpers()`.
Since these do not fully get processed sequentially the contents need to be preserved until needed.
This required getting rid of the global tsprite array. Polymost still uses a static vatiable, though, but this is only accessed in polymost-exclusive code.
* Blood's automap was not drawn at all.
* SW's automap always showed all sectors
* SW's player sprite was not rendered.
* Non-automap: Forward gotsector to the game code because there's still a few places in Blood that need it.
* Since f4b27bbd27, `D:/Program Files (x86)/Steam/steamapps/common/Shadow Warrior Classic/gameroot/addons/Sw.grp` was being picked up instead of `D:/Program Files (x86)/Steam/steamapps/common/Shadow Warrior Classic/gameroot/SW.GRP`.
* Fixes#289.
This still depends on Build's tsprite array which is global so its contents are too volatile for delayed geometry generation.
This needs to be refactored later but it can only be done when Polymost is gone.
SO's vertex interpolation does not use the common framework so it got missed by the sector retriangulation checks.
We need to check two wall positions as well to make sure that sector movement is properly detected.
* masked walls were inserted into the sprite render list, causing sorting issues and depth fighting (see Duke's cameras and the 'closed' sign in Route66/Carnival.map)
* vertical and horizontal wall sprites needed their sorting functions swapped.
* plane clipping for wall sprites used bad coordinates.
This was by far the messiest game, there's two reasons for this.
First, the portal links do not need to be in an actual portal sector, so they cannot be used to detect portal sectors.
Second, the game moves portals in place, so all offsets are (0,0,0) so that not even these can be used for detection.
The only working method is the super-complicated original way to look up portals at run time, just being done at map start.
Having static portal links should reduce the render glitches quite significantly because the renderer knows now which sectors belong to a portal and can use this information to ensure proper processing.
Unlike the other games these are so poorly defined that the engine has to rely on the original fudging to pick the proper portal to link to. As a result they are just as limited as they always were.
In addition all the portal search code had to be reinstated.
Note that these portals cannot be rotated, so to preserve bad setups this limitation needs to be replicated.
If we want proper line to line portals for all games they need to be made a different portal type.
* do not check the clipper in the collection pass to reduce number of bunches. Clipping here brings no performance gain.
* fixed the loop reset in FindClosestBunch to actually process the array's first element.
Not tested yet and somewhat stripped down, as the portals this needs to support are a lot less complex - plus some of the issues in Doom do not apply here.
