The SCUMMVM_NEON definition is alredy added by default for aarch64
host cpus. NEON is also supported on iOS devices running on armv7
cpus. Make sure to enable NEON for all ios7 devices.
Add the definition of SCUMMVM_NEON in create_project for the iOS
and tvOS targets. Do not add the same definition to corresponding
simulators since they can run on x86_64 hosts, which for obvious
reasons lacks support for NEON.
The surface_neon.cpp file is only added to the project if the flag
SCUMMVM_NEON is defined. However some backends, e.g. iOS, adds the
definition of SCUMMVM_NEON in create_project so the file can be
added to the project during configuration.
The same backend can then unset the definition due to changing
build target, the iOS simulator in this example, which runs can
run on x86_64 hosts which doesn't support NEON.
Since the project still include the source file it will be compiled.
Make sure to not build the file if not SCUMMVM_NEON is defined at
compile time.
The blit-neon.cpp file is only added to the project if the flag
SCUMMVM_NEON is defined. However some backends, e.g. iOS, adds the
definition of SCUMMVM_NEON in create_project so the file can be
added to the project during configuration.
The same backend can then unset the definition due to changing
build target, the iOS simulator in this example, which runs can
run on x86_64 hosts which doesn't support NEON.
Since the project still include the source file it will be compiled.
Make sure to not build the file if not SCUMMVM_NEON is defined at
compile time.
Reimplemented from upstream a526a401cbf716ac7c0fc09eed92d24d60b54471
(branch 2.6.1)
This fixes the inventory scrolling in King's Quest 3 (Infamous Adventures)
and possibly other games of the era
This fixes idle animation getting reset to frame 0 at the blocking speech start
if there's no speech view set. In such case the idle anim is expected to continue
playing seamlessly.
From upstream 7b399933a291a05e868cd9589b02d83d05f33314
Since older commit 5f3b8eb the properties are stored in vectors,
strictly resized to the number of characters and objects.
But the script functions that access these do not do any assertion
whether the object or char is valid, which could cause bad mem
access in case script loops over a array of objects of MAX_OBJECTS
size, or tries to access something using Object* pointer from another room.
From upstream 6ad4b220d75a32ea8df959e9a7b7f1ecb21d0c26
I did a terribly stupid mistake when was expanding the old save format in the
past (in pre-3.5.0 engines). Instead of checking for the save format,
I've been checking for the game's data format.
This causes following problem: if a game made in a particular range of versions
(something like 3.2.1 to 3.4.4) gets upgraded to a newer version (say 3.6.0),
then all the old saves made in a pre-3.5.0 game version will not load correctly,
as they are relying on the new compiled game data format.
Unfortunately there's no *proper* way to fix this, as the old save format
had been in use for years, nothing can be done about it.
Hence the workaround that I may think of is to provide a config hint,
that would tell the engine: whenever you load a legacy save format,
assume that it was written by a game of particular data version.
From upstream 0a2a0177dd8eaad817b39905bf0471663c431f96
