Sorry for these changes, i decided that it's annoying to save the "fixup"
values used only in rare circumstances, that may be easily calculated
from basic MoveList members.
From upstream 13e59c4855a4ddcf9bfe5f935d6de1191debaf1e
This is to avoid recalculating exact same values on each movelist update.
The "final move" may continue for a while if the "short" axis of the move
vector is finished earlier than the "long" one.
When serializing, use 2 freed int32s, left after removing 2 unused member variables.
From upstream 57e369ec2bcf6a8eee61c45be8266f45e8a0c922
Make MoveList::onpart a fixed point value too, allow more precise "current progress"
recalculation when the moving speed factor changes.
Possible TODO: on move update, the first step after recalculation should bring `onpart`
the the nearest integer, to make the movement progress more consistent.
From upstream b28ca9f86b8b70a73e4f6fa6f1c72ce76f29ecf6
AGS historically has a hidden problem: its pathfinder and walking algorithm uses math with relatively low precision.
This may result in rounding mistakes. What this means in practice is that under some circumstances the
"movement direction" (vector) is slightly off, e.g. more towards X than Y (or other way). In such case the character
may reach the X destination while Y destination is still few pixels away.
How is this issue solved currently in AGS (and for a long time): when AGS finds out that one coordinate is complete,
but another is not (for example X done and Y is still not reached), it starts waiting until character reaches Y, but also
accepts a certain "mistake", in 2-3 pixels. If character is already within 2-3 pixels from the destination, then it just stops.
This makes its real stopping point inaccurate, but nothing else happens.
However, if character is further away, then it keeps "walking", but because the movement vector is still pointing
in the same direction, usually it takes few moments for it to reach the proper Y coordinate.
This results in a buggy effect known as "walking in place".
This commit introduces a new solution: turn the walking vector to make it point right along the unfinished axis,
while keeping its length (that means - walking speed), in order to reach the destination faster.
This should make character make some extra short move, properly animating, but this may look more natural
than just moving legs in place.
NOTE: I still keep the "destination fix" for the old games, as they may be scripted specifically to test
where character has stopped moving.
From upstream c3f03dea01a897b23795298e77db56506e44902f
Keep ScreenOverlays in std::vector, but do not erase elements
in the middle and invalidate them instead. Record free indexes
in a helper stack.
When creating a new overlay, first check for the recorded free indexes.
Overlay's type now equals storage index.
This speeds up both creation/deletion of overlays, and their access.
Removed the gap between "fixed" overlay types and custom ones,
to save space. If we ever need more special overlays, these could
be created as custom and their ids saved in a variable (similar to
how background speech works). Previously present special overlay
types are left for backwards compatibility (and to simplify the transition).
From upstream f7d2f162fa55aa1b6f37195d890ebe047a204154
This fixes repeated post-state on/off switching, and as a consequence - endless loop
in cause of a "..." sentence, that is run until messagetime reaches -1 on its own,
which did not happen because of repeated post-state.
NOTE: looks like an original bug introduced along with the DisplayPostTimeMs property.
From upstream 37360990b22a79380f2a5b34e686a2d2fbcf7de1
Apparently, this field was used to store light level of the
walkable area in pre-2.55 engines, prior to introduction of the
Regions.
In current engine, when loading games that old, this value is
copied into Regions for backwards compatibility.
While in newer games it actually stores "player character
view" override.
Renamed update_shadow_areas() into update_player_view(),
and tidied the code for clarity.
From upstream 71e7dc880b4496dd6937cec00a56f0de66137482