It's not always set correctly by engines (AGS) and a fill call to clear
the screen will set it to 0 along with the other components.
Setting the framebuffer to some transparent value is not something we
intend to do as this let the content underneath the drawing texture
visible like it's the case on ChromeOS.
This has been reported here: https://forums.scummvm.org/viewtopic.php?p=99293
Now double-click works also on really slow hardware. And Hatari.
Also, partially revert commit 01a2d2ed because events can't be passed
to the (multitasking) OS. So basically let's hope that it works fine now
even without handling IKBD overruns. I'm not able to replicate the issue
with Hatari + FF + slow UI + mouse movement anymore.
Disable keymapper during Wizard Eye (spell and crystal ball effect)
so it can be controlled via the cursor keys again.
This was a regression introduced in
12a47d956e
"Add support for ScummVM keymapper".
SpellViewGump and SpellView:
When handling a MouseDown event, do not call target_spell() if
event_mode is set, as Events expects us to select a spell in that case.
Prevents calling Events::target_spell() with callback_target set to
nullptr and subsequentially crashing the game.
To reproduce:
1. Start/load a game
2. Acquire a spellbook (obj num 57)
3. Acquire a staff (obj num 78)
4. Enable cheats (CTRL+c)
5. Enable unlimited casting (ALT+w)
6. (C)ast enchant
7. Select the staff as target
8. When prompted to select a spell, press LMB somewhere on the map
instead
Close spellbook in cancelAction when resuming magic.
Additionally, as a precaution, do not propagate RMB events
from SpellViewGump to DraggableView.
On an RMB-down event, SpellViewGump::MouseDown() calls
Events::close_spellbook(), which uses cancelAction() to actually
close the spellbook.
However, this skipped doing so if Magic::is_waiting_to_resume() was
true.
In that case, the still open SpellViewGump received the RMB-up event,
which lead to it getting closed and deleted from
DraggableView::MouseUp().
This resulted in a crash, since the book's SpellViewGump is not
expected to be deleted during gameplay.
To reproduce:
1. Start/load a game in enhanced-mode
2. Acquire a spellbook (obj num 57)
3. Acquire a staff (obj num 78)
4. Enable cheats (CTRL+c)
5. Enable unlimited casting (ALT+w)
6. (C)ast enchant
7. Select the staff as target
8. When prompted to select a spell, press RMB instead
When casting enchant in new-style mode, after selecting an object
to enchant, the spellbook is opened to choose a spell.
While the book was open, walking and other actions were still
possible. This could lead to crashes, e.g. when pressing c to cast
instead of selecting a spell.
To prevent this, lock input to the spellbook's SpellViewGump and
unlock it again in endAction().
Do not delete widgets marked for deletion in GUI::AddWidget, so it
can safely be used from widget event handlers.
Fixes the following crashes in enhanced mode:
Using the look action on a spellbook in inventory eventually causes
a call to Events::look(Obj *obj) from ContainerWidget::try_click().
For spellbooks, look() then calls view_manager->close_all_gumps().
This closes all open gumps and marks them for deletion, including
the inventory ContainerWidget.
When the spellbook gump gets added via addWidget, this executes
the deletion.
Once control returns to ContainerWidget::try_click(), the
ContainerWidget has been deleted and the game will crash when it
tries to assign to member variable ready_obj.
A similar crash happens when selecting a staff in inventory
as the target for the enchant spell.
Fixes#14957
Disable the keymapper when entering KEYINPUT_MODE and restore
its previous state when changing mode.
Makes Events::key_redirect() work again.
The key_redirect method should cause all keyboard input to be
sent to a callback, but it was broken since commit
12a47d956e
"Add support for ScummVM keymapper".
This caused problems with spellcasting:
1. Keymapper-bound actions (including movement) were still
possible while the spellbook was open
2. Spell syllables whose keys were bound via the keymapper
could not be entered.
Fixes#14959
When gerbils are asleep Wilbur should be able to use the chute in the top right of the middle floor to go up or down
Also the chute in the middle of floor of the middle floor should lead to Wilbur fallin from the ceiling of the bottom cage floor.
After the cage door opens with the alien hand controlled motor, revisiting the room 602 would show the door misaligned to the left.
Revisiting as in leave the room from the chute (go up one floor) and then return to the bottom floor.
If the wheel motor is running with the alien hand, then revisiting the 602 room should also show the magnet vibating
This could be an "original" bug / missed detail, since the magnet is not vibrating in this case in the demo.
This would crash in the demo and also had some repeating animation issues
The fix includes:
- skipping Wilbur's quote which is missing in the demo (using a new play series "PLAY10Demo").
I can only test in demo, but I'm assuming the spoken quote exists in the full version.
- fix repeating the animation of throwing the kibble (this seems to have been a typing / copy-paste error)
- Removing the kibble from Wilbur's inventory after he throws it (this is an "original" bug since it's not removed in the demo).
- Waking up the Gerbils, after Wilbur throws the kibble at the wood shavings (this is the behavior in the demo).
This helps to solve the issue when one pushes 'Return' immediately after
Hatari's start. This issue appeared after introducing the
interrupt-driven audio mixer.
Not sure whether this was a real bug but it's much cleaner
implementation now anyway.
- every malloc is now aligned on 16 bytes
- no need for the hidden pointers
- ct60_vmalloc() is called only once, the rest is handled
by dlmalloc (SV XBIOS' vmalloc is pretty fragile)
This not only decreases the amount of XBIOS calls but also avoids
repeating the sample buffer in case of a heavier CPU load.
Also clean up the mixer code.
Use the helper function to create an array of UIKeyCommands for the
END, HOME, PAGE UP, PAGE DOWN and the ESC keys. Add a generic handler
function that decides which action for which key.
This allows the application to register key presses of these keys,
however some of them requires iOS 13.4 or later.
Use the helper function to create an array of UIKeyCommands for the
Fn keys. Add a generic handler function that decides which action
for which key.
This allows the application to register key presses of the Fn keys,
however only supoorted in iOS 13.4 and later.
Use the helper function to create an array of UIKeyCommands for the
number keys. Add a generic handler function that decides which action
for which key.
Since not all keyboards have the function keys, Fn1-Fn12, e.g. the
Apple Magic Keyboard for iPads, map these keys to the number keys
when pressed together with the CMD modifier key. Fn11 and Fn12
requires CMD + Shift as modifier keys.
Use the helper function to create an array of UIKeyCommands for the
roman letter keys. Since most of the games supports input of roman
letters, overload these keys. Keys with other characters than these
are not overloaded and will therefore trigger the call to the
delegate function:
"textField:shouldChangeCharactersInRange:replacementString:"
and will therefore still be passed to the IOS7 event handler.
However no modifier flags will be passed for those and they will not
support repeated presses.
Add a generic handler function that decides which action
for which key.
Use the helper function to create an array of UIKeyCommands for the
arrow keys. Add a generic handler function that decides which action
for which key.
Since not all keyboards have the PAGE UP/DOWN nor HOME/END keys,
e.g. the Apple Magic Keyboard for iPads, map these keys to the arrow
keys when pressed together with the CMD modifier key.
Currently the key inputs are sent to the IOS7 event handler on calls
to the delegate function:
"textField:shouldChangeCharactersInRange:replacementString:"
So when typing on either the software keyboard or a connected HW
keyboard the input is handled by the hidden textfield that is in
focus. The delegate is called on each key input and the character
typed is passed to the IOS7 event handler.
Doing as above has the drawback that if they user holds down a key,
common in games when shooting or moving, the key event is only sent
once. The delegate function is only called once per distinct key
press.
By implementing the keyCommands function and create UIKeyCommands
for a set of keys, the system will call a defined callback function.
This also enables repeatedly calls as long as the key is held down.
Modifier keys can also be configured to create UIKeyCommands to
trigger custom actions. This way we can overload the key functions
when they are pressed at the same time as a modifier key.
Add helper funtions that can be used to create UIKeyCommands for
a set of keys. Keys are represented by their input, e.g. the key
for the character 'c' is defined as a string with only one char,
the 'c', while special keys are represeented by strings defined
by the OS.
Register UIKeyCommands for all types of modifier keys and add a
function that can convert system modifier flags to flags used by
ScummVM.
