- Define new boolean 'on_vehicle' in PLAYERp struct for use with interpolating while on vehicle and other checks.
- Move horizon code back into separate DoPlayerHorizon() function. Adjusting horizon while in vehicle must come at the end of the DoPlayerOperate*() function.
- Make DoPlayerHorizon() accessible in game.cpp.
- Change code in DoPlayerHorizon() to process according how 'pp->on_vehicle' is set.
- Make scaleAdjustmentToInterval available outside of getinput().
- Don't process input at frame-rate while on a vehicle. Vehicle code is too difficult to process outside of the game's clock.
Partially based on NY00123's upstream implementation of tying player input to frame-rate.
What 43ec16eb55 intends to do was already done via 2d73466425, however I applied the if statement in the opposite order so when it was cherry-picked again, the pathway was actually reversed - interpolating when alive and not when dead.
Rather than re-apply the opposite order, I've made the if statement match upstream for more consistency and to avoid further conflicts.
Better location for it since it never needs to be sent across the wire in a multiplayer situation. It's now also located where the other properties to do with input being tied to frame-rate are located.
Better location for it since it never needs to be sent across the wire in a multiplayer situation. It's now also located where the other properties to do with input being tied to frame-rate are located.
Had to move lastInputTicks to the DukePlayer_t struct. When first running P_GetInput(), the initial value of elapsedInputTicks is the actual value of timerGetHiTicks(), which is into the thousands. This high initial value was affecting how scaleAdjustmentToInterval() scales as it was taking an initial q16look_ang value of 512 and overflowing the fix16_t type, making it -32,768.
Had to move lastInputTicks to the DukePlayer_t struct. When first running P_GetInput(), the initial value of elapsedInputTicks is the actual value of timerGetHiTicks(), which is into the thousands. This high initial value was affecting how scaleAdjustmentToInterval() scales as it was taking an initial q16look_ang value of 512 and overflowing the fix16_t type, making it -32,768.
- Lock player horizon while returning to centre.
- Precisely scale player's horizon in time with rate at which 'pPlayer->return_to_center' decrements.
- Check player's horizon is between 99 and 101 degrees, not 99.9 and 100.1. The extra 0.9 degrees of precision is not noticeable and is dramatically slower.
- Reset 'pPlayer->return_to_center' to '0' when player's horizon is at 100.
- Match q16horizoff precision to precision of q16horiz.
- Lock player horizon while returning to centre.
- Precisely scale player's horizon in time with rate at which 'pPlayer->return_to_center' decrements.
- Check player's horizon is between 99 and 101 degrees, not 99.9 and 100.1. The extra 0.9 degrees of precision is not noticeable and is dramatically slower.
- Reset 'pPlayer->return_to_center' to '0' when player's horizon is at 100.
- Match q16horizoff precision to precision of q16horiz.
- Accidentally left in while merging changes from upstream.
- Change restores accuracy to game play in that a hard landing now returns the player's view to center.
* - fix Linux builds following reset of master branch.
* - fix Linux Clang CI failure.
* - change '#ifdef __linux__' to '#ifndef _WIN32' as requested/required.
* - initialise batchrun in proper spot.
In the RedNukem frontend this was causing view interpolation glitches, this probably should be disabled a bit more targeted but right now I do not know yet which call causes the problem
Let's see if this is breaking anything.
# Conflicts:
# source/sw/src/draw.cpp
# source/sw/src/game.cpp
# source/sw/src/game.h
# source/sw/src/interp.cpp
# source/sw/src/track.cpp
draw.cpp: Fix the lack of interpolation while walking on a sector
object, like the bus roof or the floor of the train in Seppuku Station.
track.cpp: Make sure the player's location and angle aren't mistakenly
interpolated while standing on a moving sector object as a consequence.
# Conflicts:
# source/sw/src/track.cpp
A double is already used in CalcSmoothRatio. Further to this, displays that use TV standard frequencies do not use perfect 60Hz frequencies, but frequencies such as 59.94Hz, 23.976Hz (precisely, 24*(1000/1001) = 23.9760239760239760...) etc.
Reference: 'https://www.ghacks.net/2010/04/28/59-hertz-refresh-rate/', 'http://www.paradiso-design.net/videostandards_en.html'.
# Conflicts:
# source/build/include/baselayer.h
# source/platform/posix/cocoa/i_main.mm
- Inline function returns a double, therefore we should use it and not potentially truncate the mantissa.
- Use divisors to get true numbers of some floats (3.333 -> 10/3, etc).
- Remove a few brackets/parentheses where possible from what are already exceedingly bracketed lines.
Since the same word gets used in text messages and local variables in the game code it is easier this way to search for it and facilitate its transition to the translation table management in PaletteContainer.
