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
Detect when a legacy string function (StrCopy, StrCat, StrFormat, etc) modifies
Character's fixed-sized field, and sync that with the new unrestricted property value.
Also fixed check_strcapacity() which incorrectly use new Character field's size instead
of legacy field size after recent changes.
From upstream ad7d19232bf9d69b6060e0cb20585628a6687c9f and
e1a06c5abf2ae0dd55dedc25404f71ef8c4b2fe5
This potentially allows to access any metadata while passing string pointer around the script functions.
As a consequence: never wrap external buffer, always allocate your own.
From upstream 043758b1bb5116f038c5c597d17fe9524b92b3c2
I realized this recently that SUOs were not registered in the script exports
properly. In AGS standards the object having a memory buffer should
register that buffer's address directly, so that it could be read and written
to directly. That is how strings, arrays, and any other structs are exported.
This also how the engine plugins can access the data if they use script API
to retrieve it.
There have not been any script API working with custom structs earlier,
but there is since 3.5.0 (few functions returning managed Point struct).
Plugins won't be able to use them correctly without this fix.
From upstream 9658c71528676acb386e2c638e782cc4e7d2afe5
The purpose is to at least keep string iteration relatively fast in ASCII
game mode, for backwards compatibility.
Also fixed String.Length for plugins in Unicode mode.
From upstream 052def762633796b5565fd0e79295392e5e43b52
New string arithmetic is using pointers diff casted to long...
Trying to avoid C++11 features, the best option is to cast them to intptr_t instead of long
This not only simplifies all the use of _t types to the
ScummVM equivalents, it gets rid of the int32 usage in
favor of just int, solving common type clashes with the
Amiga, for which int doesn't match int32
Some of these are legitimate, because the AGS source did some
nasty code sharing a char * buffer for both reading and writing
stuff to savegames. Will need to refactor it at some point to
use the Common::Serializer
Walter Agazzi
Paul Gilbert
Le Philousophe
Paweł Kołodziejski
Eugene Sandulenko
aviloria
Thierry Crozat