Need to get rid of all those unmanaged allocations and present game data in an easily serializable form.
This adds a managed TPointer class that replicates the useful parts of std::unique_pointer but steers clear of its properties that often render it useless.
* Remove unused `getincanglef()`.
* Remove unused `getincangleq16()`.
* In `PlayerHorizon` struct, clamp value when setting target in `__settarget()`, not each public `settarget()` overload.
* Rename `PlayerAngle` method `applylook()` to `applyinput()`.
* Rename `PlayerHorizon` method `sethorizon()` to `applyinput()`.
* In `PlayerHorizon::applylook()`, slightly clean return to centre code so it doesn't do math if already at 0.
* In `PlayerAngle::applylook()`, slightly clean rotscrnang/look_ang code so it doesn't do math if already at 0 and reposition where mouse input is applied so that if input is applied, the player never enters a spin.
* In `Duke3d::player_struct::apply_seasick()`, use `buildfang()` method instead of scaling float to BAM within function.
This was causing issues with the master switch sprites in Duke that have to be kept for sound purposes.
Unfortunately, both hitscan and neartag are far too dumb to analyze sprites they may hit in any way and needed some help skipping such sprites.
The current screen job implementation does not coexist well with UI elements.
More like a hotfix, the screen job framework needs to be redone for properly handling input.
* Requested by users, really don't know why...
* Interpolation values are guarded by the CVAR.
* For Blood, integer truncation is employed just like original game.
* For all games where more precise sine/cosine math has been utilised, no changes have been made.
* Initial implementation from d32dcd5f8e was not working properly and already had some workarounds for when the player was underwater, etc.
* Re-read implementation in GDX and rebased off of it.
* Fixes#303.
Parts of the sound system treat entry 0 as "no sound" so nothing placed there would play.
This made the one custom sound in "The Way of Ira" not play because as the last sound being defined it ended up in the first, invalid slot.
0 means 'default', -1 means 'silent'. This caused playback issues for useSoundGen. All other places were passing proper volume values along, this is the only one to read the volume from map data.
Blood needs this for its PlayerSound controller, which is run right on map load - so without this it wouldn't start the sound when a map is initiated from the console.
Aside from not having been functional, this is ultimately more harmful than useful as it forces loading of a large number of textures at the same time during gameplay instead of spreading them out.
* made it palette aware
* use backend facilities to track precached data.
* fixes bug in animation precaching loops - they only precached the base index over and over again.
* Added in fca846272e to deal with signed adjustments but its just not needed.
* Made better use of `binangle`/`fixedhoriz` class getters and setters than before as well.
This was incomplete and just ignored Duke's special music, and the levelnum generation used an outdated formula so that it never managed to assign any music to the maps.
This works as long as the loaded mods have one single .ini file in them - in that case it is assumed that it is supposed to replace blood.ini, which will allow dragging & dropping such archives without further user intervention.
* 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.
Fix undefined behavior/potential OOB access in ST_21_FLOOR_DOOR. g_AnimateGoal does not take a sector number, it takes an animation index, and caps at 1024, not 4096.
* 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.
The sound system may play sounds on them after their deletion - this resulted in undefined behavior. To ensure properly defined behavior the sprite needs to be retained at least as long as the sound controller may still need it - which cannot be reliably determined so it has to be kept around forever. This would be easier if the sound controller code had proper start and stop events instead of inferring what to do from secondary information.
Fixes#288.
After discovering yet another misbehaving place in the game I think it can be safely concluded that this is better left off unconditionally.
The only remaining place where this still gets checked is in nnexts, but I wouldn't expect this to work either.
Fixes#292
* 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.
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.
* Doing this in `renderView()` unconditionally isn't correct as it can lead to a double adjustment if `p->spritebridge == 0 && p->newOwner == nullptr`.
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.
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.
