Age | Commit message (Collapse) | Author |
|
|
|
|
|
Closes #837.
|
|
Used only by chapter 7 of Phant1.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(cherry picked from commit 7d7c36b5933d1e777e1246c8fe84a3c2379f082d)
|
|
|
|
|
|
|
|
|
|
Was changed to Ctrl-Shift-D at some point, because a SCI game
uses Ctrl-D. Comment wasn't changed accordingly back then.
|
|
Renamed "ourModifiers" to "scummVMKeyFlags"
Now also using the flags directly from the ScummVM event in case
it actually was a Keyboard event.
|
|
7aeadba863ed1893fa6095008d35b32ce5117749
Thanks LordHoto for spotting it
|
|
Was the ScummVM-system-Keycode, sometimes modified.
Changed Menu/Portrait/Controls32-code to use .character instead.
Cleaned up a bit of code in getScummVMEvent()
|
|
|
|
Also added comment about .data field. Should be renamed.
|
|
Was effectively caused by commit adding the keyboard driver bug
for SCI0/SCI01, although the bug is actually real and happens.
It seems Sierra did not check the key-modifier in kMenuSelect.
We do and that's why the code didn't recognize all sorts of
menu keys anymore.
We now isolate the lower byte before comparing.
I also noticed, that Sierra passed keyboard modifiers in mouse
events. This was probably done, so that owners of a 1-button
mouse were able to right-click. We do this now too.
Also added information about mouse modifiers in kGetEvent.
Moved the mouse modifier code into getScummVMEvent().
This should fix bug #7009.
|
|
It seems the issues on AmigaOS aren't actually caused by the new
code. Reverting the revert.
|
|
Seems to cause at least issues on AmigaOS probably b/c SDL.
See bug #7009.
Added FIXME. Underlying issue needs to get fixed in SDL backend
or in SDL itself.
|
|
When the users presses keys on the numpad, we get digits in .ascii
even when Num-Lock is not enabled. This caused numpad cursor keys
not working anymore. Imo we should only get .ascii in those cases,
when Num-Lock is enabled.
|
|
New way is probably better. Sadly we get a few keys atm in the
ascii field, like cursor left and the function keys. That's why
a check for <= 0xFF is needed.
|
|
This actually affected all Control+key combinations. A regression from
0f90b8eaad0335715d5f6aea6ede32ebbb746e25
|
|
|
|
|
|
Fixes bug #3580473
|
|
Regression from 906f0248317e1a4167190a666fe308a09334bfac.
Fixes bug #3533069.
|
|
Such key combos are used for the game debugger in SCI1.1 and GK1
|
|
This tries to make our code a bit more compliant with our code formatting
conventions. For future use, this is the command I used:
git ls-files "*.cpp" "*.h" | xargs sed -i -e 's/[ \t]*$//'
|
|
A check for alt was changed into this check for shift in the
cleanup commit 906f0248317e1a4167190a666fe308a09334bfac.
|
|
|
|
Applied from patch #3258985.
The previous hotkey interfered with the hotkeys of some games (e.g.
the "time of day" hotkey in QFG2, bug #3250996).
|
|
A regression from 463e475bd65
|
|
|
|
Instead of querying the event manager for the current mouse cursor coordinates
kGetEvent now uses the saved mouse positions, which will assure every event
will be processed with the correct coordinates instead of the current ones.
Various other functions using SciEvent directly were adapted too.
This fixes cursor click positions for the WinCE backend.
Thanks to wjp and waltervn for helping me with this.
|
|
|
|
The heuristic in question was used to detect the pseudo mouse control
functionality, however the change in controls seems to have occurred with the
transition to cursor views. Fixes keypad control in Conquest of the Longbow.
Moreover, the code also checked for key scan code 76 when checking for the middle
keypad button, which seems to be a mistake, as that case never occurred.
|
|
special keys are translated
svn-id: r54493
|
|
svn-id: r54420
|
|
Script 944 does constant reallocations whenever the selection changes,
which leads to all sorts of unpredictable crashes. Thanks to waltervn for
his help on this issue
svn-id: r54413
|
|
(import works)"
svn-id: r54407
|
|
This fixes function key input (e.g. F3) when num lock is on
svn-id: r54294
|
|
SCI constantly invoked Engine::shouldQuit(), which in
turn called 2 virtual functions. This added a significant
overhead, as this was called constantly without any
throttling whatsoever. Now, the invocation of shouldQuit()
is throttled to be on each frame update (i.e. at a rate of
60fps). Thanks to wjp for profiling this.
svn-id: r52431
|
|
svn-id: r52255
|
|
handling synthetic (keyboard repeat) events and adding support for Control-C
svn-id: r52252
|