Firstly, this is not necessarily optimal, as the next graphic
assigned to these objects may be of same size, in which case
the texture surface may be reused.
But there's another thing: there've been a bogus behavior in
the AGS, where a dynamic sprite, deleted right before the
room's exit transition, was still displayed for room objects (and
everything else really).
This is because although the sprite was disposed, the image
remained on a texture connected to these objects, at least
until the next object update. But object updates don't run
during room transitions, hence the effect.
From upstream 38d0dd3d7f0d6a4624d1f908f2e8d3c1abfee52a
This is necessary for the touch-to-mouse emulation to work
properly (and perhaps true touch controls in the future).
The order of updates is a bit wrong historically, where cursor
position and gui control focus is updated later than the
handling of button events. This means, for example, that if the
cursor was positioned over button in game frame 1, then the
mouse click will only trigger button press not later than the frame 2.
Changes:
* moved "cursor over gui" poll from draw_gui_and_overlays()
to update_cursor_over_gui(), call it in the main game update fn.
* moved update_mouse_cursor() call from
construct_game_screen_overlay() to the game update fn
(renamed to update_cursor_view().
* picked out "cursor over location" trigger out of the "render"
function into update_cursor_over_location(), call it explicitly in
the main game update fn.
Effect on user script callbacks:
* the cursor position (and gui focus) will now be updated prior
to `late_repeatedly_execute_always()` callback. Other callbacks
will not be affected, as their relative order won't change
compared with these updates.
From upstream 23493a681d4f66ae0b1088cddb82241b0bc80dbb
NOTE: the code theoretically allows any object to be sorted this
way, but the problem is, the ID sequences are not shared, and
multiple object types may have same IDs.
This is something to consider in the future.
This is primarily for backwards compatibility with the older plugins,
that relied only on software drawing.
Previously we added "stage screens" to the hardware-accelerated
graphic drivers (Direct3D/OpenGL), which provide a surface for
plugins to draw upon. If used, these surfaces would then be rendered
as plain sprites in 3D scene at certain place in the sprite sequence.
The remaining problem (left unnoticed) was that the surfaces which
correspond to the two room render callbacks (right after background,
and right after all objects) did not follow the room camera position and
scaling correctly (not all, tbh). This commit addresses these problems by
letting the engine to request certain size and optional position for these
"stage screens" for particular sprite batches.
Partially from upstream 2d43bffc2cb07935ae72d7c5677ad622c8b4d37e
I'm baffled how I did not notice this behavior earlier, but engine was
created at least 2 redundant intermediate bitmaps meant to cache
transformed sprites per each object and character on screen for
HW-accelerated renderers, - which they do not need, as they don't
use software transformations.
The resulting effect won't be too notable for low-res games with low
amount of simultaneous objects, but may be quite significant for the
high-res games with multiple large objects in the room.
From upstream cca997fe83ec5f7014677a69095a7c9ec1494cd9
Leave it with a new name as `update_polled_stuff()` only in functions
related to the game update.
From upstream 95dc139f51e704da19792e5480e69bbfe7ec27aa
This render stage overlays the room with objects and characters, but
stays within room transform, therefore will work with non-standard
viewport positions and multiple cameras.
The next closest stage is AGSE_PREGUIDRAW, which is rendered outside
room viewport. The new one fills the missing stage, lacking after the
viewport/camera update in 3.5.0.
From upstream 4ff7e14400ab81693fb64195d9ada70e979647ac
This may result in object texture not updating if the old sprite was deleted but a new dynamic sprite was created right after having same ID.
Was broken by upstream 9dffb04 in 3.5.1, and also some later changes in 3.6.0.
From upstream 7ed51861898d864902b0f61b0cb7d0acadef1fe3
This code is not used in ScummVM, but since it was still there in
comments it's probably better to keep it in sync with upstream.
The code was updated in upstream 0d1034df1a0e6593e7e61bbdb75d2996b8721b14
(tidy Direct3D renderer code, remove redundant parts, etc)
and 2f04e3b81db598eb7950668ce9d88a145f796f2c
(fixed Ali3DException's message string misuse)
Fixed getting stuck in a render attempt loop, because the window
events are not being processed.
From upstream 25329949f4d4a17ea8e6ad11fc7bd0ecccdfaca7
Specify sprite ID for shared textures for: characters, objects, overlays
GUI and GUI objects are more complicated, a they may contain custom
(generated) graphics; using shared textures for them would require a
bigger change in how their sprites are organized when gathering draw
lists for render.
From upstream b724b43fa7f13ea2e89a3e9213dd76b00e59f9f4
Walter Agazzi
Thierry Crozat
elasota
Hubert Maier
D G Turner
Paul Gilbert