* 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.
Whoever designed that map format with its idiotic encryption should burn in Hell >)
It's a needless complication and open invitation for errors.
To avoid follow up problems it now uses its own local struct for loading in the sprites and the global spritetype no longer depends on any map format and can be changed as the need arises.
Fixes#101
This time there were 3 additional texts and the notify display, though, except for multiplayer content that wasn't touched yet.
The result is the same: No need to extend the tiny font with international characters
This is needed to extend a few fields that are too narrow - e.g. the texture offset fields have no room for interpolating scrolling textures.
Blood not done yet, will also need to be changed to get rid of the limits.
* Duke/RR: Fix `SB_CENTERVIEW` not clearing while `cl_syncinput 1`.
* Duke/RR: Remove superfluous call to `apply_seasick()`.
* RR: Change two calls from `playerSetAngle()` to `playerAddAngle()` Updated version of `playerSetAngle()` doesn't stop setting angle until target is reached, a bit too strict for this and compromised vehicle turning.
* `applylook()`: Remove dead flag. Was only used with Duke, no other game called the function when dead anyway. Since the input helpers are processed outside of `applylook()` now this is not needed.
* `applylook()`: Extend function with a bit of commentary.
* For Blood/SW, exposes `SB_LOOK_LEFT`/`SB_LOOK_RIGHT` to games, hooking up `q16look_ang` and `q16rotscrnang` within.
* For SW, use Duke & Blood's return to center function and remove `PF_TURN_180` bit.
* For RR, replace a few misused bits with some bools inside of `player_struct`.
* Since bulk of functionality is sourced from Duke (30Hz), apply proper scaling so SW speed matches (40Hz).
* For Duke/SW, we continually apply `SB_CENTERVIEW` only if it was previously a toggled action, similar to Blood.
* For SW, we remove two SW-specific bits (`PF_LOCK_HORIZ` and `PF_LOOKING`) that are no longer needed.
* For Duke, we remove `return_to_center` and just use the `SB_CENTERVIEW` action bit as required.
* For `sethorizon()`, feature set and adjustment speeds are an averaged out accumulation across Duke/SW:
** GameTicRate is factored in for adjustment decisions to provide consistency for SW being the faster game.
** Adjustment amounts are half way between Duke/SW.
* Doesn't matter for Blood, but will matter for SW in a unified approach. Might as well get it right here.
* Appreciate the literal doubles in lieu of the enums isn't great, but this function will go into the backend in due course.
* Horizon now standardised on 100 like the other games.
* Need to determine where/why/how the player's horizon is starting out at 0 and get it to init at 100 like the other games.
* Split input bits and movement into separate functions.
* Reordered movement to be more like Duke/SW for ease of comparison.
* Removed a global.
* Removed a few includes.
* Looking up/down is a bit rough at first as q16look is disproportionate to where the player is currently looking.
* Won't be an issue with a unified horizon algorithm in the backend.
* Changed config so `cl_interpolate` bool doesn't apply to player's overall movement. While it might be handy for debugging moving sector objects, I see no valid reason why there'd be a need to ever un-interpolate the player's position.
This unexpectedly turned out a complete rewrite so now it is under my own license.
Also moved the remaining parts of map hack loading into the engine.
Overall I have to say that the feature is not what I expected, it's merely used to fudge the positioning of model sprites and for adding Polymer lights.
This isn't active, though, because load times are so short these days that all this results in is an irritating screen flash before the level starts.
It may be activated later when hires assets are in use.
Fixes#10 (or not...? ;) )
Also optimized the base64 encoder to avoid creating endless memory copies, thanks to using std::string which is a really poor container for this kind of stuff when workig with larger blocks of data.
* Provide read-only/const results from `CONTROL_GetInput()` so games can't change received input.
* Change non-descript `info` to `hidInput` (Human Interface Device).
* Remove a few unused prototypes.
* use static_assert directly. Raze is C++17, no need for that macro shit.
* removed CONSTEXPR - I seriously fail to see the use here, many of the functions marked as CONSTEXPR cannot possibly even be constant evaluated so the declaration makes no sense. Removed most of these and replaced the valid ones with the official constexpr keyword.
* got rid of EDUKE_PREDICT_FALSE - this makes zero sense in script parsing code, at best it will save a few microseconds. Clean code wins.
* replaced Blrintf with xs_CRoundToInt. Shitty name is shitty name, even if derived from POSIX.
* replaced Bstr*casecmp with str*icmp. As these get defined in the CMake project based on actual compiler checks they are preferable here.
* removed lots of other stuff that is not needed with a minimum compiler requirement of C++17.
The remaining excpetions are the "give" CCMD and any level change action.
Unfortunately the implementation of most cheats is not multiplayer safe so right now it'd only be useful for demo recording (assuming that worked to begin with... ;))
They need to be reset when level data gets set because the current value is used as base.
It was most easily observed at the start of the first level where the grave only would open after a lengthy delay - which was the play time of the last level being played.
