* 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).
Since this not only crashes but also has totally unfitting lighting, which is unlikely to be fixed it really makes no sense offering this to the users.
Vulkan may also have to be disabled for release builds because it's not working yet but that needs to be fixed later and should eventually be supported.
This is for consistency, otherwise sprites with a palette translation would stand out. Also use shade dependent fog density instead of a single global value.
Currently this only has an effect in true color rendering mode.
* 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.
* Pre-requisite to make it possible to stop using Q16.16 for horizon input.
* Perform look up/down and aim up/down using true pitch without the need for a helper.
* Adapt SW's return to center function to work based on true pitch (Duke's is a bit too fast for my liking).
* Duke's aim up/down and look up/down is 6 & 12 respectively, SW's is 8 & 16 respectively. Let's go half-way at 7 & 14.
* Need SW's input helpers available for Blood but therefore also need an angle delta function that does not seem to exist in Blood.
* Realise that gamecontrol.h/cpp might not be the most appropriate place, but it's a shared location and these will go into binaryangle.h when its utilisation can be more realised.
* Because SW's logic was reversed, in that param #1 was the new angle and param #2 was the current, all calls have been reversed.
* By happenstance, also fixes an issue with multiple 180° turns in quick succession.
* 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.
Brightness is now correct - I have no idea why this factor of 1/0.85 is needed - something must reduce the brightness of the entire scene but I have no idea what.
This fell victim to some fudging code that was needed to avoid crashes with the original game loop.
All that fudging could easily be removed now because nothing of it is needed anymore.
They created different code depending on the passed index, this was changed to always emit the optional parameter, even when not needed, so that the interpreter does not need to second-guess.
Not everything will do something, though. This was some incredibly careless code operating without a safety net allowing uncontrolled write access to the map structure.
Most of the critical fields have been made read-only, which has been the only mode of access in the mods I checked.
Note that this does not enable scripting of the weapon sprite drawer, only the gameplay related features were done.
Another piece of Build licensed code gone, yay!
This will also allow gradual conversion of the DEF parser to our own code, unencumbered by the Build license. :)
Since the added values are not scaled, doing this per frame has the potential risk of achieving too high total velocity when combined with other means of input.
The change here was kept as simple as possible.
* Stops overshooting keymove when playing with `cl_syncinput 0`.
* Keymove is never as high as MAXFVEL/MAXSVEL, which is used as a thrash point for controller input.
* Fixes#390.
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 is mainly a preparation for merging the parser into sc_man, because sc_man does not keep token texts in a static variable.
This commit also fixes a handful of places that were flagged by the stricter conversion rules of FString.
* the palette shader was not bound.
* the palette textures were not bound.
* palette mode still used regular lighting on top of the palette emulation
This works a lot better than before but is still not complete.
There were two errors:
1. The postprocessor was not run on the generated scene so that the target framebuffer never got set.
2. The generated PNG was not finalized and failed the integrity check of the savegame menu.
Fixes#48
This allowed significant simplification of code data and many of the error checks could also be simplified because this player doesn't really need it all.
Also use nanoseconds to count frame delays, not milliseconds, as milliseconds can cause timing anomalies with common frame rates very easily.
This reverts commit 28a3ef131f.
I mostly added this to visualise an attempt at how I've attempted to make the vehicles work with unsynchronised input. I don't wish for this to be committed to the main branch as it's a net negative.
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...? ;) )
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
