(e.g., beginning to jump, or landing on ground);
Reproduced with the input being tied to framerate
while SO interpolation is toggled on.
This involves the following modifications:
- PF2_INPUT_CAN_TURN and PF2_INPUT_CAN_AIM are now additionally set
from various DoPlayerBegin* functions, allowing the player to continue
turning/aiming as usual (right before the next call to domovethings),
even in specific instances of player action changes.
- If PF2_INPUT_CAN_TURN/PF2_INPUT_CAN_AIM was set before and
after calling pp->DoPlayerAction from domovethings altogether,
ensure that the player's oq16ang/oq16horiz is updated by
making an appropriate call to DoPlayerTurn/DoPlayerHorizon. This
is done in case a call to DoPlayerTurn/DoPlayerHorizon is missed.
This change is not applied for a dead player, though.
in 1a3c9e3a15ba788607dfd96ebcc75a2198be6d69 was a mistake.
The interpolation should still apply, albeit not while
the viewing angle is changed via the player's own input.
We should also continue interpolating in coop view.
interpolation of player turning/aiming/movement, while being carried
by a sector object, without SO interpolation. This is a continuation of
73a0aa394e906a65633d61f3c749c9b9b7e66aaa and bf31bc2987a3eccd31d343622327bd4ee0f9c5a1,
aiming to fix a jitter in case the player is continuously
getting pushed by a wall (e.g., on the boat in level 5).
Basically, this moves the relevant assignments from track.cpp:MovePlayer
and MovePoints to player.cpp:DoPlayerMove. Unless a call to one of these
functions has been missed, pushwall and clipmove can be called from
player.cpp in the following instances, which should be covered:
- Via DoPlayerMove, which is the function getting the fix now.
- Via DoPlayerSlide, which is called in the beginning of DoPlayerMove.
- Via DoPlayerCurrent when called from DoPlayerCrawl/DoPlayerWade,
followed by DoPlayerMove.
- Via DoPlayerCurrent when called from DoPlayerDive,
followed by DoPlayerMove if the player doesn't stop diving.
# Conflicts:
# source/sw/src/track.cpp
The main reason here is that the scene specific part contains a projection dependent component which would be a problem when transitioning to GZDoom's code. The global viewpoint data already has a field for such a factor so now that gets used.
This also means a significant simplification of the visibility code in Polymost and the removal of several global variables.
Technically, an overflow is still possible, but with unsigned integers
it is highly unlikely to satisfy (sum_squares < 290*290) in practice.
# Conflicts:
# source/duke3d/src/player.cpp
This is so I can tell the difference between actor .t_data[] values that are actually set to something defined in CON versus bullshit arbitrary internal usage of the same variable, which I need for a future commit.
I don't expect anyone to make an EDuke32-compatible WT mod where other enemies shoot FLAMETHROWERFLAME, but if they do the behavior will at least be consistent across enemy types.
This results in far fewer calls to getwalldist(), inside(), and cansee(), which should significantly lessen the performance hit from a large number of A_RadiusDamage() calls in areas with many small detail sectors.
# Conflicts:
# source/duke3d/src/actors.cpp
Models are inoperable right now anyway so this would never get called, but it does a few things that would cause problems with refactoring the backend code.
- M_Active or GUICapture properly pause game using game's pause mechanisms.
- Pausing game with Pause key now works again.
- Pausing game with Pause key now properly stops all sounds as per upstream.
- M_Active or GUICapture properly pause game using game's pause mechanisms.
- Pausing game with Pause key now works again.
- Pausing game with Pause key now properly stops all sounds as per upstream.
Improves the messages printed to console when bailing out of sector effect processing due to nextsectorneighborz() returning -1. This also adds such a check to ST_21_FLOOR_DOOR, which was missing it entirely. (!!)
# Conflicts:
# source/duke3d/src/sector.cpp
(with SO interpolation turned on). It would be nicer to have something
better structured than the given hack, but this currently seems to work,
while not breaking the sprites on the boat in the beginning of level 5.
Most of what got added is still unused.
# Conflicts:
# source/build/src/palette.cpp
# Conflicts:
# source/build/src/palette.cpp
# Conflicts:
# source/common/engine/i_interface.h
Also added support for creating indexed textures directly into CreateTexBuffer, where this functionality can be shared.
As an added plus, brightmaps are working again, this time with less hackery.
They depend on a deleted texture not writing to the depth buffer, but other parts in the engine like ROR surfaces depend on them writing a proper depth buffer value, so for now there is a global variable that allows to exclude a single tile from ever getting rendered.
The base palette can be set via .def files so that the engine has no access to it until the entire game state is set up.
This means that font translations and PNG palette remap tables cannot be built when the owning objects are created.
For PNGs this has the added advantage that they only get done when really required and not unconditionally - most of the time the remap table isn't even needed here.
Thid fixes the slider graphics in the option menus.
# Conflicts:
# source/core/gamecontrol.cpp
# Conflicts:
# source/core/gamecontrol.cpp
In order to finish this I need the switchover, but brightmaps need an update of the texture code which requires merging a few more WIP changes before the code can be fixed.
This pulls in a lot of Doom specific font setup, this can be sorted out later as it won't get into the way.
# Conflicts:
# source/CMakeLists.txt
# Conflicts:
# source/glbackend/hw_draw2d.cpp
# Conflicts:
# source/CMakeLists.txt
# Conflicts:
# source/glbackend/gl_texture.cpp
# Conflicts:
# source/CMakeLists.txt
# Conflicts:
# source/build/src/palette.cpp
# source/core/gamecontrol.cpp
Game compiles and runs but transparency doesn't work yet.
# Conflicts:
# source/CMakeLists.txt
# source/core/menu/menu.cpp
# source/core/textures/buildtiles.cpp
source/common/objects/dobject.h:276:21: error: use of undeclared identifier 'malloc_size'
source/common/utility/m_alloc.h:45:22: error: ‘malloc_usable_size’ was not declared in this scope
source/common/engine/m_random.h:40:10: fatal error: SFMT/SFMTObj.h: No such file or directory
source/common/objects/__autostart.cpp:94:10: fatal error: 'doomtype.h' file not found
source/common/objects/zzautozend.cpp:58:10: fatal error: 'doomtype.h' file not found
I have no idea why this needs to be different than in EDuke32, but without always clearing the depth buffer before rendering a scene viewpoint the game will glitch like crazy.
of change that camq16ang/camq16horiz gets. Such an update is possible
after making sure that UpdateInputs (faketimerhandler) is
never called from domovethings.
# Conflicts:
# source/sw/src/game.cpp
and ready2send and the call to timerUpdateClock, which are now done
before calling UpdateInputs itself from RunLevel.
# Conflicts:
# source/sw/src/network.cpp
from EDuke32-OldMP. Main difference from EDuke32-OldMP is that this is
done even while staying in the menu; Behaviors will otherwise break.
We should also call timerUpdateClock() before the loop, especially
after removing the call to this function from faketimerhandler soon.
of the secret rotating pillar in level 1 with SO interpolation.
The drill in level 2 is also covered. So far, SetVatorActive seems
to be the only place where interpolation of ceiling/floorz
may be set, outside of the SO interpolation code.
- Change damage scale and min firedist for Custom Dude.
- Remove unnecessary checks in callback of tracking condition.
- Fix picWidth() function.
- Better initialization of modern stuff.
- kModernSeqSpawner: disable all other spawners with same TX ID when enabling current.
- Fix: sceneQav was not playing if resurrected with COUSTEAU cheat.
- kModernPictureChanger: remove kModernFlag01 feature (deprecated).
- kModernSectorFXChanger: add flags to control where exactly light effect should appear.
- kModernCondition:
- add delay before sending command if condition is true.
- take in account state, so kCmdState and kCmdNotState is useful.
- fix wrong comparison result in some conditions.
- add new various conditions.
- kModernPlayerControl:
- fix start / stop playing qav scene when triggered with event command converted to sprite command.
- add a way to resurrect / heal player.
- add event commands to toggle inventory item status via trigger.
- fix that Remote and Proximity detonators cannot be given.
- add clear all screen effects option.
- proper percents for changing movement / jumping.
- kModernRandomTX, kModernSequentialTX: change event redirection mode activation from kModernTypeFlag02 to kCmdLink.
- kModernSpriteDamager: treat damage value as percents by default, take in account god mode.
- kModernEffectGen: fix wrong cstat for effects.
- kModernPropertiesChanger: proper underwater status for sectors and players or enemies in it.
- Players: assign or update current player's sprite index for all conditions.
# Conflicts:
# source/blood/src/nnexts.cpp
- Fix for custom health when respawning enemy
- Fix for custom dude when respawning it
- Conditions: added way to refresh sprite index in tracking conditions
# Conflicts:
# source/blood/src/actor.cpp
# source/blood/src/aiunicult.cpp
# source/blood/src/aiunicult.h
# source/blood/src/dude.cpp
# source/blood/src/dude.h
It now picks the minimum of the current formula and the one from before June 2017 - the current one was causing problems with sprites in the distance so now the old one is used as an upper bound.
of sector objects as whole groups of points and sprite angles.
The following goals are intended to be achieved with this code:
- Make it easy to let the user toggle sector object interpolation.
- Interpolate the angles of sprites carried by sector objects.
- Use the right amount of samples for interpolating a sector object,
depending on the players' locations, as done in the checks within
DoSector. Unfortunately, modifying DoSector itself to
unconditionally call MoveSectorObjects(sop, synctics) technically
changes the way sectors move (in the logical sense), and was
found out to make a specifically constructed user map unbeatable.
- Make it easy to disable interpolation of a whole sector object in
case of a need. This is especially important if such an object
is controlled by a player in multiplayer, mostly since this
isn't compatible with the way player prediction is working.
A known issue, which also applies to existing settings like the voxel
toggle, is that its value gets written to the saved game, and when such
a game is loaded, the its value gets overwritten by the one in the
saved game. Options should move to settings.cfg later, anyway.
similar manner to what's done in Duke3D (with the addition of the angle).
There seem to be some jitters with this, mostly in Master/Slave mode.
Decreasing PAKRATE in mmulti.cpp might also increase the frequency
of this occuring in Peer-2-Peer mode.
less dependent on the frame rate.
It would probably be better to update this from the game loop side,
like in Duke3D, but it's still better than the preceding situation.
DoPlayerTurn/DoPlayerHorizon while input is tied to the frame rate:
Introduce the new player flags PF2_INPUT_CAN_TURN and PF2_INPUT_CAN_AIM.
Set PF2_INPUT_CAN_TURN if DoPlayerTurn can be called outside
of getinput. Similarly set PF2_INPUT_CAN_AIM if DoPlayerHorizon
can be called in this manner.
getinput will only call DoPlayerTurn/DoPlayerHorizon
if PF2_INPUT_CAN_TURN/PF2_INPUT_CAN_AIM is set. These flags are reset
right before the call to the player's current DoPlayerAction function.
For one example in which this assists, it's not always the
case that DoPlayerDeathFollowKiller may call DoPlayerTurn,
even if we assume that pp->input.q16angvel is never zero.
This fixes truncations of q16ang in MovePlayer. One known
fixed issue is a minor micro-shaking effect, reproduced
while standing on a non-moving SO (e.g., the bus in level 1).
The latter is also related to the use of camq16ang.
Based in idea on patch from mjr4077au.
is non-null seems to resolve the newly introduced interpolation
issue for looking up/down while controlling a sector object.
We can also remove the PF_DEAD test, since
game.cpp:getinput should lock any kind of aiming.
src/src/game.cpp:getinput: We now, however, need to further
lock turning here while controlling a sector object.
sector. This re-introduces the angle interpolation in drawscreen
while sector object interpolation is in use.
A side-effect of this is that looking up/down is now less smooth
while controlling a sector object (e.g., a turret).
PACKED macro. This is more consistent with the current Duke3D codebase,
and further fixes build with older versions of MinGW GCC, in which
attribute packed is broken without specifying -mno-ms-bitfields.
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.
While it is understandable that avel and horz came from Duke3D,
having both q16horiz and q16horz in the updated SW_PACKET struct
can be confusing, and the alternative notation is more consistent
with the original struct field names of angvel and aimvel, as well
as the differing uses of the name angvel still present in player.cpp.
for them to modify the player's camq16ang/camq16horiz field
instead of q16ang/q16horiz. Additionally, pass to them the
change in angle/horiz via a parameter, as an alternative
to direct access to the corresponding player input field.
Add the camq16ang and camq16horiz fields to the player struct.
With the exception of DoPlayerTurn and DoPlayerHorizon, whenever
code in player.cpp updates player's q16ang/q16horiz, also write
the updated values to camq16ang/camq16horiz. These variables'
preceding values are never used in these functions.
related to the definitions of RANDOM_NEG in bunny.cpp, ripper.cpp
and ripper2.cpp. Do so in a way that isn't re-introducing compiler
warnings. This partially fixes compatibility with demos made for SW 1.2.
Additionally, replace the 3 separate definitions of RANDOM_NEG
with a common one within game.h.
From-SVN: r8798
This reverts commit e878c5bab8.
Revert "SW: Use Q16.16 for horiz."
This reverts commit f07a0ae01e.
Revert "SW: Use Q16.16 for angle."
This reverts commit 1ecc74c2ec.
Revert "SW: Minor repairs for Q16.16 implementation."
This reverts commit d78d046bad.
Revert "SW: Process input at frame rate."
This reverts commit c162014dab.
Revert "SW: Amendments to accommodate changes in master."
This reverts commit eaa51138ad.
Revert "SW: Fix incorrectly declared function input type."
This reverts commit 1cdd5b08d8.
Revert "SW: Amend scaleAdjustmentToInterval() with correct value for SW."
This reverts commit d4dd737cd5.
Revert "SW: Refinements to new input code."
This reverts commit 5ebc65a1fb.
Revert "SW: Adjust look and snap up/down keys and slightly tune PLAYER_TURN_AMOUNT."
This reverts commit 2852536dbf.
Revert "SW: Get PLAYER_TURN_SCALE to be just right."
This reverts commit 4630c8a0b7.
Revert "SW: Make map follow mode work better."
This reverts commit 8e94c48eff.
Revert "SW: Remove line accidentally left from 'MoveScrollMode2D()'."
This reverts commit 5db8047b41.
Revert "Fix multiplayer desync after the change to q16 angle and horiz."
This reverts commit 3bc46078b8.
Revert "SW: Revert commented out horiz->q16horiz renames in DSPRINTF strings"
This reverts commit 537313f620.
Revert "sw/src/draw.cpp:drawscreen: We can set the pp->si* fields just once,"
This reverts commit d2e9595980.
Revert "sw/src/game.cpp:LoadLevel: Rename q16ang -> ang"
This reverts commit a178961a3e.
Revert "SW: Minor tweaks."
This reverts commit 377ba68344.
Revert "SW: Further refine turning and optimise horizon adjustment."
This reverts commit 039022d9ac.
Revert "SW: Don't process input at frame rate if ScrollMode2D is true."
This reverts commit 1aa1e62c4d.
Revert "SW: Use a bit more Q16.16 in places."
This reverts commit 40ca656f38.
Revert "SW: Use the old interpolation path in drawscreen if player is dead"
This reverts commit 2d73466425.
Revert "SW: Smooth out 180 degree turn landing and replace some fix16_min/max with fix16_clamp."
This reverts commit 0996e87f79.
Revert "Change Next/Previous Weapon button handling for Shadow Warrior."
This reverts commit f6b8ca6a22.
Revert "SW: Make "Center_View" key return smoothly."
This reverts commit 23c401fbc2.
Revert "SW: Use the old interpolation path in drawscreen if player is dead"
This reverts commit 43ec16eb55.
Revert "Interpolation fixes for SW:"
This reverts commit ac8a7ecfbd.
Revert "SW: Reset the number of interpolations on level load"
This reverts commit 04bf8499e7.
Revert "Another change modifying saved game format in SW:"
This reverts commit e80888523e.
Revert "SW: Interpolate sector objects in non-demo, single player games."
This reverts commit 996ab77cf4.
Revert "- fixed merge errors in SW."
This reverts commit b8cfa94568.
Revert "- fix interpolation stutters when opening console for SW."
This reverts commit 99fdbfb6cb.
Revert "- reset buttonMap button states after returning from pause for SW (stops keys acting stuck down if down prior to pausing)."
This reverts commit 693b6955da.
Revert "SW: fix stupid input scaling bug"
This reverts commit 1c79e6e17c.
Revert "SW: Make vehicle input better."
This reverts commit 670a53c402.
Revert "SW: Change fix16_from_float() to fix16_from_int() that was changed in 4630c8a0b7 but should have been reverted in 377ba68344e34495638c6fa7685ff78c9a0ed6f8."
This reverts commit 423c9da071.
Revert "SW: Remove ScrollMode2D extern boolean and move into PLAYERp struct."
This reverts commit 31eb55c1fa.
- 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.
Includes the new weapon, enemy projectiles, and breakable objects.
Patch from Nuke.YKT.
I edited it some, mostly to add the proper "if (WORLDTOUR)" checks.
From-SVN: r8788
# Conflicts:
# source/duke3d/src/namesdyn.cpp
