Avoid query gfxDriver's properties all the time, instead save them once in init_draw_method() and use saved values.
From upstream db535512af65119d50ae3d6fb06c221d56f42d85
Remapped sprites are the sprites that were supposed to be present in the game
assets (according to the sprite index), but failed to load for whatever reasons.
The idea is that whenever a remapped sprite is requested, sprite cache should
return a placeholder sprite (sprite 0) instead.
This commit corrects the logic of this, where it would use remapped sprite index
one step earlier. This should fix incorrect duplicating addition of same "bad" sprite
index to the MRU list, and also saves little redundant actions where the LoadSprite
would reload the sprite 0 unnecessarily per each such request.
From upstream eca2e2d3b47a7fcf235690ee0ebda9058a662c91
* 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
The idea is to have similar interface internally in the engine, without having to refer to the
plugin's API; at least to keep things consistent with the rest of interfaces for now.
(The whole engine interface system may need to be reorganized.)
* Renamed existing ICCObjectReader to ICCObjectCollectionReader, an interface that supports
multiple object types.
* ICCObjectReader is now an internal engine's alias for plugin's IAGSManagedObjectReader
(but it may be used for the internal purposes too if a need arises).
* Moved PluginObjectReader declaration, save 1 small h/cpp pair.
* Store pluginReaders in a std::vector, remove MAX_PLUGIN_OBJECT_READERS as redundant.
From upstream 49d037671e4daaa909a7a98e19456e0f29f8e3cb
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 complements the previous commits related to the upstream commit
9221ea54c1a81b9f37829d7fafc90ac2806d4eb1:
Engine: replaced script API registration with cleaner array tables
The benefits are:
1. Cleaner registration view, an array initializer instead of myriads of function calls.
2. Implicit distinction between static and object member functions based on prototype
detection, no need to explicitly pass a parameter or call respective registration function.
3. Enforced function registration for plugins, now combined with the regular registration
in one table entry, so more difficult to skip plugin variant
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
Walter Agazzi