This also fixed a potential memory leak in ccInstance::CreateEx().
From upstream 30167df0690e0a771a8eb4f14a4d6a72da526b49
Also remove unreachable code (same condition checked twice in a
function) as that caused a compilation error with the changes above
otherwise. This change is part of upstream commit
881d31966cf7600c9b5628fff4c194d628196f4a
It's illegal to reference an inactive member of a union and the types
are not layout compatible (and even not of the same size).
Instead, store every value in a integer of pointer size and cast
pointers to and from it.
This should really fix bug #13557.
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
The script handling part of the engine appeared to be too fragile and dependent on
a precise timing of **deleting** a ccInstance.
For example, restoring a saved game may execute in the midst of the call to
RunScriptFunction(), at the "post script cleanup" stage, while there are still references
to ccInstance on the engine's call stack (and few other places). If anything prevents
ccInstance's disposal at this moment, that would in turn lead to logical errors due to
the game scripts "instances" counting. The most outstanding consequence is that the
script exports are kept pointing into the deleted memory and not re-registered after the save is restored.
Overall, the script handling part of the engine would benefit from a major refactor,
with a goal to make it safe and consistent, but this is not something I might do at the moment.
From upstream 1f6abf4b678f77825c710d4ae18b57ff8f882c93
After the updates to cc_instance this should now work
From upstream b1e4f75141ce88b3146f55ecd9d7a95378428072
and 49e8aa0b566dea4ce025f9530a9f2392dbe67a33
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
This removes an excessive separation between "static managers" and "dynamic managers",
and let use the single ICCDynamicObject interface when working with both kinds.
Simplifies RuntimeScriptValue and StaticArray classes.
Picked out most common implementation into CCBasicObject, which is inherited by
AGSCCDynamicObject and AGSCCStaticObject.
From upstream 781632881dd64af2b57b789617da15107bca9451
This might happen when assigning a local pointer variable, which was not cleaned either with ZEROMEMORY or MEMINITPTR.
from upstream a989f3ed0150fc0218c47b3d7ac3c655d072e78a
This explicitly calls FixupArgument() only for the 2 instructions where a fixup may be expected to be applied to a literal arg. These are:
* SCMD_WRITELIT
* SCMD_LITTOREG
Based on the idea by @ericoporto
This is more code lines, and looks kind of ugly, but proved to be significantly faster enough to justify this change.
Maybe there are more ways to refactor and tidy this in the future.
From upstream 9f255eab2343896928039dbca71576718f5f7380
Although this means more code lines, it reduces redundant variable
initialization and assertions, which may lead to slightly optimized execution.
In addition, this change makes argument read explicit, under each individual opcode.
From upstream 777cd4a4effd1c1785582e847f9fcdadef5fe7e0
Stack stores either "values" or arrays. Values are always stored as int32:
these are ints, floats, managed handles, also "pointers".
Although we don't store things like pointers in the stack buffer for real,
we store them as stack "entries" as RuntimeScriptValues.
But we keep stack pointer consistent by moving along the buffer,
to avoid unnecessary data type tests. Basically, the stack buffer will be
holding 32-bit placeholders.
From upstream 338afc27ece7ff4030101887c9f00ab4f24ca3ca
This was an early attempt to pick out few operations into separate functions,
but IIRC this caused additional slowdown. Maybe was not done in an optimal way.
In any case, it's better to remove the old commented code, as there may be slight
differences between that and current inlined code now.
They may be recreated if necessary for another refactor. Just need to be aware of
potential performance issues, and do tests.
From upstream 961569db426af1c09c7d9da38f5f4e4a0e09b499
The latest change (c694126) was meant to fix a timeout test logic,
but it broke the primary loop count check.
The incorrect behavior may be observed when a function with
many loops and `noloopcheck` modifier is called *repeatedly*
from another function. Normally in such case the iterations
passed withing a `noloopcheck` function should not be counted,
but they were.
Apparently the situation cannot be resolved without having 2 counters:
1. One is working all the time, and is used to detect timeouts, as these
may occur both in normal circumstances and in functions with
`noloopcheck` modifier.
2. Second is working only in functions without `noloopcheck` modifier
and is used to do the "stuck in a loop" test.
+ backported small optimization from 3.6.1 branch.
From upstream 70afd47f4879b4eaed5dab664af9e4485055875f
Thierry Crozat
Le Philousophe
Walter Agazzi
Paul Gilbert
elasota