For completeness, this adds functions sys_window_fit_in_display
and sys_get_window_display_index.
Practically it has no effect as in ScummVM we don't support
multiscreen and the resolution is hardcoded.
Partially from upstream 1afc61df54681ffe2fddc0d30bb2221c38a0fa79 and
b17f58d90061c3b12c9e4c04183dc59b094d66cb
* This also fixes GUI.ProcessClick, apparently it always had an issue of using mouse
coordinates instead of provided ones.
From upstream ab3561359eb23fe17ba0758741f139165eb1f13c
This setting comes from the original mobile port of AGS, but it's not clear whether it was
useful. More importantly, there are issues with this:
1. It was never implemented in another hardware accelerated driver (Direct3D), being
exclusive to OpenGL.
2. It was never added to standard setup, so not very visible.
3. It's not clear whether it was working properly all this time. There were multiple changes to graphic renderers, and some of them may assume that rendering at "native resolution" is done at exactly, well, native resolution.
This fixes a mistake introduced in commit 4be1556, which in turn followed b02814b
The problem is, that CCStaticArray does not work as intended, and seems won't (at
least not without some extra workarounds).
When the script compiler is told to get an Nth element of a global struct array, such
as character[n], it calculates the memory address as
Character* ptr = (array address + sizeof(Character) * n).
If this address is used for the read/write operations, these ops can be intercepted by
interpreter and remapped into the real fields (see IScriptObject::ReadN, WriteN
interface).
But if this address is used IN POINTER COMPARISON BY VALUE, then we cannot do
anything. And if our real struct in the engine is stored on a different relative memory
offset than one expected by compiler, then this pointer comparison will fail.
This breaks script expressions like e.g.:
if (player == character[n])
From upstream 97ed18e95b587544ae47497f0a5f1d1ba00a7e29
NOTE 1: we *must* keep the old fixed-sized fields for the time being,
for compaibility with the plugin API. Would the plugin API be adjusted
and have direct access to a character data struct removed, then these
fields may be removed as well.
NOTE 2: we still read these old fields from game data, avoid changing the
data format in the middle (in the sake of both backward and forward
compatibility). These fixed-sized values are assigned to the character
properties first. For unrestricted values we'll have to add a data extension,
appended to the end of data format.
From upstream b02814b8bb3bb7a2cd00110466e2bd3047e772d1
* Moved plugin API event constants to a separate header agsplugin_evts.h.
Engine should not include whole plugin API, this is unnecessary, and may
create naming conflicts.
* Moved SimulateMouseClick to mouse.cpp.
* Minor cleanup in agsplugin.cpp
From upstream 510293c1fd277d853544534423ceea27b8ae3e2d
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
This is more logical than calling this from "engine_setup",
and also fixes running another AGS game from current game after commit 5596736 .
From upstream a82d8147d4424b0aa83762d810db96cff31d7af9
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
