(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.
NY00123
Richard C. Gobeille
Christoph Oelckers
Dino Bollinger
Jordon Moss
Mitchell Richters
sirlemonhead
nukeykt
alexey.lysiuk