Instead of allocating the GameState and GameSetupStruct variables on
stack and erase the heap version, deallocate the old ones and reallocate
new ones.
This is what upstream AGS does in the 3.6.1 and master branches,
while our code corresponded to the 3.6.0 branch.
This fixes an issue where deleting the screenoverlay vector later
on would try to access an already cleared SpriteCache.
This sould fix bugs #15488 and bug #15510.
The problem was that the delay formula used integer division (twice), and precision loss
resulted in calculated value to "jump" up and down even from a slight change in input text length.
Fixed this by reimplementing calculation using a floating point division instead.
Used a different literal coefficient, found experimentally, to approximately match the result of the
old formula in certain key text lengths, for backwards compatibility.
From upstream d783f5678d974b8d4cfdde3c7011b0a56dc4c3ac
Previous existing method ran through virtually all the game objects that may reference a sprite, and
checked each one of them. Those who did reference the modified dynamic sprite were marked for
update and/or had their draw caches cleared.
Furthermore, for safety reasons, the Graphic properties of these objects were reset to 0.
This process was slow under two conditions:
- if there are alot of objects (especially overlays which may be created at runtime in large quantities);
- if there are alot of temporary dynamic sprites created and deleted per game frame (for example,
when drawing something complicated).
The new method:
1. We no longer reset object properties, this turned to be a bad design. There's another safety fix done
in the SpriteCache, which returns a placeholder sprite for any invalid sprite ID. This should make things
simpler and faster.
2. For the texture-based renderers, it turned out that updating the shared texture entries was enough
to make objects using them redraw. So for these renderers we don't need to reset any more caches.
3. For software renderer, introduced a GameState::spritemodified vector of bools. Whenever a sprite is
modified or deleted, engine sets a corresponding flag in this vector, and that triggers an update at the
next draw pass for all the objects that still reference that sprite.
GUI PROBLEM: because GUIs rendering is still different from other objects, even in texture render
mode, they are still marked for update the old way.
This should be addressed separately in the future.
From upstream 0b84a21cfb486e3a9fa03e6c2b354750742ed3fd
and 3f70782761a698a69d31af77833c05bf38eb7394
* separate variant of add_dynamic_sprite() that searches for the free slot itself,
not requiring user to do this;
* the previously existing variant is used for: replacing modified dynamic sprite
and restoring sprites from save.
* add_dynamic_sprite() accepts unique_ptr<Bitmap>, explicitly saying that the
ownership will be taken by the spriteset.
* sprite info and SPF_* flags are set inside spriteset, instead of hacking them in
add_dynamic_sprite().
* simplified LoadSaveSlotScreenshot()
From upstream 0913f49e4212fea3a48539251ffc1ab92518a231
and aca47b9f466fe41d73d99a15b9f0ae41e65c6926
+ minor changes
Avoid query gfxDriver's properties all the time, instead save them once in init_draw_method() and use saved values.
From upstream db535512af65119d50ae3d6fb06c221d56f42d85
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
After the updates to cc_instance this should now work
From upstream b1e4f75141ce88b3146f55ecd9d7a95378428072
and 49e8aa0b566dea4ce025f9530a9f2392dbe67a33
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
This "console" implementation has multiple issues, making it unusable in practice:
- saves and displays only few lines, cannot scroll back;
while multiple game messages may be printed per a single game frame;
- messages cannot be filtered at runtime;
- uses a game font of a fixed number, which in unreliable (as the font may not be suitable);
There's not much value in its code; if a new console will be wanted in the future, then it
would be best to reimplement one from scratch, but with a good planning first.
From upstream c303590efca4632fef0fb2ab3143faba6e605ba8
They are not used anywhere in Editor nor Engine, looks like a pre-2.5 feature we have no knowledge about.
From upstream bf0cab71384c6eca996143ac12e56e1af2510004
Le Philousophe
Thierry Crozat
D G Turner
Walter Agazzi