The previous attempt, using a boolean spritemodified array, proved to be having logical
loopholes. In simple words, because spritemodified flag was resetting each draw pass, it won't
affect objects that are temporarily not visible, and they failed to reupdate when becoming
visible again. This affected Software renderer.
Texture-based renderers have a different problem, where they fail to recognize when an old
sprite was deleted and a completely new dynamic sprite created accidentally with the same ID.
The cause was simply that the check for this was done inside sync_object_texture(), but
sync_object_texture itself was not called unless draw() function thought that object had
changed. So there has to be a check outside too...
Here I decided to reimplement notification mechanism, and use it for both types of renderers,
for the sake of more straightforward code logic. (Although, strictly speaking, texture-based
renderers could check their texture's "ref id" instead.)
The idea of a new implementation is this:
1. There's a map of "control blocks" per each active sprite (that is - sprite that was drawn as a
part of object). The "control block" is simply a integer with a sprite ID in it, allocated and
wrapped by shared_ptr.
2. When the ObjectTexture syncs its texture with a new sprite, the control block is retrieved (or
new created), and from now on it may be shared among multiple objects which display same
sprite.
3. When the sprite gets either updated or deleted two things happen: the previous control
block is assigned an "invalid value", serving as a marker, and then it is removed from the map,
left only if referenced by any ObjectTexture.
4. When checking whether texture needs to be re-synced we test the control block too, to see
if it was invalidated. In such case this tells us to call sync_object_texture() again.
NOTE that dynamic sprites that do not appear on screen, and are only used for drawing on
another surface, do not allocate control blocks, nor notify anything.
From upstream ab2dd5846075a73e3a3415c45c37fe6b37805964
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
The spriteset's [] operator loads a sprite, but some operations may
omit that and check the preloaded information instead.
This also makes it more certain where the actual sprite's bitmap is necessary.
From upstream df30fc1edd30d4f334addaf7883286e745dea2c3
Historically, this function could *happen* to create bitmaps of
0x0 or even -1x-1 sizes and return a valid DynamicSprite
object. Try to ensure the image library is passed valid
parameters in such case, and keep going, for backwards compatibility.
From upstream 82194b261b4649281742c45498a4c34f452fd350
Leave it with a new name as `update_polled_stuff()` only in functions
related to the game update.
From upstream 95dc139f51e704da19792e5480e69bbfe7ec27aa
mausimus
Walter Agazzi
Thierry Crozat
Paul Gilbert
Eugene Sandulenko