Commit graph

18 commits

Author SHA1 Message Date
Christoph Oelckers
be3292d29b - removed the mostly unused macros for sprite iteration. 2020-10-15 20:22:38 +02:00
Mitchell Richters
be6e0d87d7 Revert "- SW: Attempt at making vehicle movement work nicely while uninterpolated."
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.
2020-09-10 19:56:13 +10:00
Christoph Oelckers
2ffb6a3580 - finally got rid of SWBOOL. 2020-09-09 20:32:24 +02:00
Christoph Oelckers
e044582aef - fixed all issues with SWBOOL as pointed out by a type-safe wrapper class. 2020-09-09 20:28:05 +02:00
Christoph Oelckers
1a647e8104 - globally search and replaced TRUE and FALSE in SW.
There were a handful of warnings afterward which were also addressed.
The SWBOOL type has not been handled yet.
2020-09-09 19:52:52 +02:00
Mitchell Richters
28a3ef131f - SW: Attempt at making vehicle movement work nicely while uninterpolated. 2020-09-09 22:45:21 +10:00
Mitchell Richters
73d0772e87 - SW: Call DoPlayerMoveTurret() in processMovement() in lieu of DoPlayerTurnTurret() and don't interpolate sector object's sprite while !cl_syncinput.
* Makes operating the tank silky smooth while unsynchronised.
2020-09-08 19:42:22 +10:00
NY00123
6920ef8fc3 SW - interpso.cpp: Imperfect hack for jittery coolies in level 1's train
(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.
2020-05-30 23:27:18 +02:00
NY00123
217bf454f4 sw/src/interpso.cpp:so_dointerpolations:
Move ratio calculation out of inner loop.
2020-05-30 23:27:18 +02:00
NY00123
ccf6722b70 SW: Don't interpolate a sector object if the corresponding lasttic value is 0 2020-05-22 23:41:10 +02:00
NY00123
37c3f1cc46 SW: Add the macro SO_EMPTY and use it instead of
separate checks of the form sop->xmid == INT32_MAX
2020-05-22 23:41:09 +02:00
NY00123
916cd01550 SW: While not exactly a favorite of mine, this fixes the floorz updates
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.
2020-05-22 23:39:12 +02:00
Mitchell Richters
d98813f00f SW: Allow sector object interpolations to be disabled for debugging.
New code is causing some issues. Upstream allow it to be toggled, so let's do that also.
2020-05-22 16:43:34 +02:00
Mitchell Richters
45cc95401f SW: Make game compile after upstream backports. 2020-05-21 18:47:37 +02:00
NY00123
024d4e7297 SW: Afraid that we should disable almost all kinds of SOs in multiplayer
for now, due to possible jitters. Currently leaving remote-controlled SOs.
2020-05-21 18:47:37 +02:00
NY00123
5baba6b9f3 SW: Don't interpolate a non-remote sector object controlled
by the player. Make sure looking up/down is still smooth.
2020-05-21 18:47:37 +02:00
NY00123
bdacab366a SW: Disable interpolation of sector objects that
don't move as smooth as possible in multiplayer
2020-05-21 18:47:37 +02:00
NY00123
2b1e32bf3d SW: Add the currently-unused interpso.* files, enabling interpolation
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.
2020-05-21 18:47:37 +02:00