Since there is no plan to keep them in case MP gets implemented there's no need to maintain them.
These should later be replaced by a generic screen using a better font and a layout that takes higher resolutions into account.
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.
* 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.
* Struct made up of binangle class units.
* Create signed clone of binangle for use with look_ang and rotscrnang.
* Append currently outgoing function names with `2` at the end to avoid conflict.
* Started with the most complicated game first.
* Struct made up of fixedhoriz class units.
* Append currently outgoing function names with `2` at the end to avoid conflict.
* Determined maximum horizon able to be handed by engine in Q16.16 format is 280039127.
* Re-did pitch math to work on this known maximum and standardised pitch around -90/90 degrees as it should be.
* Because pitch is now -90/90 and not ~-188/188, m_sensitivity_y probably requires re-scaling.
