This is by no means a permanent solution but having it buys some time to find something more universal that won't affect performance too badly and investigate the need for a more robust solution.
The idea here is to define pairs of walls where when the first element of the pair is seen, it will treat the second one as view blocking.
This is used as the two offending windows (sectors 151 and 152) to cope with the lack of a height sensitive clipper.
While in GZDoom this uses the IWAD name, the same approach is a lot more problematic here because of name duplications with far more incompatible content.
So this allows targeting a group of base games instead of one specific version.
To allow cumulative loading without interfering with other ports, Raze will now look for files called xxxx-raze.def, where xxxx is the default .def name (e.g. duke3d-raze.def for Duke3D.) and if that is found, cumulatively load all same-named files - it will fall back on the default name if no such thing is found.
-def still overrides both and will not cumulatively load.
* moving polymost_voxdraw into polymost.cpp.
* consolidated all remaining voxel code in hw_voxels.cpp. All original Build voxel code is completely gone now, except for polymost_voxdraw, so this got moved out of the build/ folder.
* integrate Blood's voxel init code into the main function.
* some further cleanup was allowed as a result of this, so engineInit is gone now because these parts can now be done outside the games' app_init functions.
This is to have consistent ordering, independent of where the files are found.
Game order is: Duke, Blood, Shadow Warrior, Redneck Rampage, Nam, WW2GI, Exhumed, all the official mission packs are grouped below the game they belong to.
The algorithm was a bit too complicated and missed the smallest defined game resource.
GrpInfo was renamed because there were two of them which created a debugger conflict.
* When interpolating on the initial setup, when binangle reached an overflow point when going lower than zero, the engine was spinning the player around clockwise to the new angle (2047, for instance).
* Interpolating after casting as uint64_t with a workflow similar to the original games, the issue went away.
* Cleaned up other interpolation functions to be of a consistent workflow.
* Scale keyboard input turning down to degree speeds.
* Uplift some remaining Q16.16 code in `applylook()` to full BAM precision.
* Move static calculations of aim and look speeds for `sethorizon()` back into function since GameTicRate isn't set right before calculation is done.
* Simplify the angle target setup back to a basic value like before.
* Repair SW interpolation issues of weapon sprite drawer when rotating left/right.
* Fix SW death horizon constant values following change of horizon center to 0.
