First "on_event" firing after mouse button is released may cause a sequence of blocking actions.
If there's any control checks during them, the global "wasbutdown" variable will be tested again,
potentially leading to a recursive "mouse up" event, except it's not run immediately, but scheduled
until after the first one has completed running.
For this reason "wasbutdown" must be reset BEFORE firing any events.
This was broken a VERY long time ago, it seems, probably by commit 2f54a16
From upstream ff1baccbffd8ee79fe3a5aff547e2ac7b8d8aaf5 (branch 3.6.1)
Because some things were previously updated during the
render, we also need to explicitly run these whenever we do
not update whole game, but need to keep cursor updated:
* Dialog options;
* blocking Display command
* built-in gui dialogs
From upstream e236f3ee05bb7e1e748fb050c99ba1afa564ec65
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
Leave it with a new name as `update_polled_stuff()` only in functions
related to the game update.
From upstream 95dc139f51e704da19792e5480e69bbfe7ec27aa
* Changed from -1 - based constants to 0 - based constants;
* These were purely internal values, therefore no API would be harmed;
* Removed necessity of converting from internal mouse button code to script and back all the time;
* On a side note, this fixes a bug where WaitMouse etc were returning incorrect values on mouse skip, because we forgot to convert from internal to script code.
From upstream 471098d239b076c494beb2d554572ccb69372667
From upstream e924778ce3f88a4c821a4eecfea8edc353a6807b
In ScummVM they were already bools, but where still assigned values
of 0 and 1 instead of false and true in some places.
In order to specify that they should be treated as signed
Some ports may treat an (unspecified) "char" as unsigned by default. Android does this for its ARM architectures and while we did fix this by enforcing -fsigned-char to its compiler, the issue may come up for other ports. Also it should be better to clarify in the engine when a variable is not actually storing string characters.
I've spotted and changed the most "safe" cases I could find for this. As far as I can tell, out of these, only the Outline field and fontoutline array could potentially be assigned valid negative values which would cause bugs for ports treating chars as unsigned.