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.
* Doing this in `renderView()` unconditionally isn't correct as it can lead to a double adjustment if `p->spritebridge == 0 && p->newOwner == nullptr`.
Like for Blood, the Polymost-only code has been moved aside.
Closer examination of the preparations the engine is doing for rendering SE40/150-portals shows that all this was merely done to avoid glitches with a two-phase rendering setup - nothing of this will be needed for doing it properly.
They can just be treated as run-of-the-mill stacked sectors. when using hardware rendering capabilities for clipping.
* Primary issue was call to `renderSetAspect()` within `setdrugmode()` wasn't mulscaling with `viewingrange`.
* Changed `setdrugmode()` to `getdrugmode()` to return `p->drug_aspect`. This is so `renderSetAspect()` needs to only be called from one place only.
Storing this in the player_struct is pointless and a relic from having to use real hardware palette switches.
With this now just being a translation index being passed to the backend it can be cheaply retrieved right when used and nowhere else.
Also making some changes to how RRRA's psychedelic cactus handles the projection. This fixes issues with occasionally passing a bad matrix.
* 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.
* Blood had this right. It makes sense that the horizon be based around as it's easier to work with.
* Removed all associated game math to deduct default horizon of 100 when doing weapon zvel etc, meaning actual horizon can just be used.
* Re-did return to center function to work on the already converted pitch. Return speed should be 1:1 with previous code.
A nearly typical problem of this code. Not all relevant properties of the camera target were changed at once - there was a two frame discrepancy in which the camera pointed in some undefined direction after the change.
Fixes#15