640x480 is too small to render some dialogs correctly, and is much
smaller than even a small laptop screen. Smaller resolutions are still
supported, if the user chooses to switch.
When the user opens the menu via the mouse, grd_curcanv points to a
canvas other than the top level canvas. When the user opens the menu
via the keyboard, grd_curcanv points to the top level canvas. For this
menu, the top level canvas must be used in order to get correct
alignment. Switch the constructor to always use the top level canvas.
Reported-by: dimag0g <https://github.com/dxx-rebirth/dxx-rebirth/issues/564>
Fixes: e45ba0b4a9 ("Make new game menu inherit from newmenu")
Callers only ever test for whether the movie was skipped, and never
distinguish between a movie that ran to completion versus a movie that
the user interrupted. Combine these two statuses into one value, and
eliminate the logic in RunMovie that picked which of the two to return.
Previously, rendering the preferred bomb type could also change it if
the active type was exhausted. This is undesirable, since it depends on
the user to have a HUD mode which causes the bomb type to render.
Switch to only change the active type if the user tries to drop a bomb
while the active type is unavailable. Some call sites already switch
bomb types automatically on depletion. Those sites will still do so.
v0.58.1 did this, but the functionality was accidentally removed in
859b399d20. Restore it.
Fixes: 859b399d20 ("Use mask for Secondary_last_was_super")
gcc computes a potential value range for game times as [0, 1092] instead
of the [0, 50] that the game uses. This could be reasonable as the code
was before, but even adding an explicit range check before the usage
does not eliminate the warning. Avoid the warning by increasing the
size of the buffer to avoid truncation even if the value were 1092.
After the previous commit, its only purpose is to automatically dismiss
the window after 3 seconds. Users may be surprised by this, and the
automatic dismissal has limited value. Remove it and let the user
remain at the cancel dialog until a decision is made.
The menu operated by kmatrix_poll2 exists only when the containing
kmatrix menu is also open. kmatrix has its own call to
do_protocol_frame, so there is no need for another one here.
Closing the kmatrix window while it is not in the foreground may cause a
use-after-free when it is closed again later, since the event loop can
reenter kmatrix_window::event_handler. Skip the exit logic if the
window is not in the foreground, so that it remains open until it times
out while in the foreground.