gfxdrivers.cpp has become quite large. So I've now made a
separate file for each driver. I also separated the mode
validation and driver init code from the enigine and put
it into an extra file.
This removes the unnecessary Buffer subclass and stops most places
where the output buffer was being interrogated about dimensions
instead of GfxFrameout.
Basic keyup event support appears to have been added in the SCI1.1
IBM keyboard driver, and more robust support was provided in SCI32
which actually gets used by at least Lighthouse. This patch adds
support for keyup events in SCI1.1+.
Fixes Trac#10242.
Convert macros and vars to enums, rename keyboard events in
preparation for adding key up events, clean up unnecessary nested
conditionals, add TODOs for potential future work.
Calling through EventManager::getSciEvent to flush events is
pretty inefficient and created stalls that lead to dropped
frames during the chapter 7 chase in Phantasmagoria 1.
If necessary, performance could be improved further by extending
Common::EventManager to expose SDL_FlushEvents, but this seems to
finish in 0-1ms so should be OK for now.
Refs Trac#9974, Trac#9975.
Used by:
* All games with text inputs (Ctrl+C clears text boxes)
* QFG1VGA (Ctrl+S shows stats)
* Torin (Ctrl+N, Ctrl+O, Ctrl+S, etc. activate menu commands)
The branch that used to shift control keys for SCI versions <=
SCI_VERSION_1_MIDDLE was bogus; history indicates it was intended
to be used to fix backends that sent control characters when
Ctrl+Alt were used together, but that case is already handled by
the Alt-checking code just prior to that code. Games expect to
receive control characters only when Ctrl is the only active
modifier, and this seems to be consistent across all versions of
SCI engine from SCI0 all the way through at least SCI2.1.
Fixes Trac#6703, Trac#9837.
Was the ScummVM-system-Keycode, sometimes modified.
Changed Menu/Portrait/Controls32-code to use .character instead.
Cleaned up a bit of code in getScummVMEvent()
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.
