[Scummvm-devel] RFC: Flexible keymapping via new EVENT_ (post 0.10) (Serhiy Batyuk)
Max Horn
max at quendi.de
Fri Jul 13 01:03:20 CEST 2007
Hi Serhiy, hi all,
Am 12.07.2007 um 14:25 schrieb Serhiy Batyuk:
> Hi all,
>
> I am working on the new key mapping architecture in the course of
> my GSoC backends project. As I see, Max's idea (http://
> wiki.scummvm.org/index.php/Talk:Keymapping_Improvements ) is
> generally approved, so I would like to post some implementation
> ideas to get your feedback.
Great to hear that :-)
> First of all, we introduce new type of events called UserActions.
As I stated in my last email on the subject, I am not convinced
anymore that a new event type is the way to go here, at least for in
game key mapping. It requires extensive changes to all engines to
work, when we could achieve virtually the same goal by generating
fake key/button press events...
But a UserAction struct definitely is needed to allow engines to tell
the backend what kind of "UserActions" it supports, aye.
> They hold the information about the type of action (the most
> important property), it's human readable description for
> referencing in key mapping dialogs, the default key (will be used
> by the backend to automatically map the action if this default key
> is available on the device), and whether the action mapping is
> required or optional (bool required;).
I don't think a "bool required" is quite enough, we'll need a more
fine grained "int priority", I think. There are some *crucial* maps,
some "very nice to have", and some "other stuff" actions, and many in-
between. Yet the number of available buttons usually is small, and
varies between different devices, so we should be flexible in this
regard.
BTW, another thing I just had to think off: Some "user actions" are
context specific and only relevant at certain times. The "keyboard
fighting" in Indy3 & Indy4 comes to mind. For that it would be nice
to be able to dynamically & temporarily remap everything.
> I propose that the action types are developed on a totally abstract
> layer, meaning that we simply have engine specific (quit, pause,
> save/load) and game specific actions (move left, right, jump,
> fight, etc.).
Not sure I fully understand you here, so let me just sketch my
thoughts: What I had in mind here originally was that we have some
generic types, i.e. those which are likely to be used by many many
engines; and beyond that, we simply allow the engines to use their
own internal IDs. The backend would not know anything about these
IDs, and wouldn't *have* to know about them either; the IDs are for
internal referencing only, and (in the case of the "global" ones),
can be used to help ensure consist mapping across games or even engines.
In a nutshell: I think it's hopeless (due to the amount of work) and
pointless (where's the benefit) to try to come up with an enum of all
possible "action types". But maybe that wasn't what you had in mind
anyway (it was/is not quite clear to me what precisely you meant
above :-).
> This way we'll have a totally device independent code, we'll be
> able to map an action that by default is assigned to, say, a mouse
> click to some keyboard button. And we'll also have a nice, readable
> code.
To map both key & mouse button events, we don't need a new event
type, though :-)
> Though this is actually the point where I would like to get most of
> your comments, as these abstract action types will require a bit of
> work from the engine authors.
Another reason why I more and more tend to prefer generating fake
key&button events: This reduces the work load for engine authors a
lot. Which makes it more likely that the new feature is implemented.
So, I prefer the pragmatic approach, over the grounds-up, "new event
type that has to be implemented and fully supported by all engines
before we can switch to the new system", *unless* the latter provides
some serious advantages. Which I don't quite see yet, but I'll be
happy to be taught differently -- this is a complex matter and I
don't claim by far to have understood all of it :).
> Another important detail: I propose to replace the KeyCode enum
> with ButtonCode enum (and KeyState struct with Button struct
> respectfully) which will be basically the same with the only
> difference that it will also contain codes for mouse buttons and
> all other device specific buttons. This way we can map our actions
> directly to any buttons available.
That would only make sense if we decided to *completly* drop both key
& button events, I think. Otherwise, a key press should generate a
KEY event including a KeyState, and a button press a BUTTON event
(with maybe a "button state"). Renaming KeyState like this feels like
mixing up abstraction layers....
> All of the key mapping will be handled in the event managers. Each
> backend will have its own event manager which will be aware of all
> device buttons and able to detect which button was pressed/
> released. Engines on the other hand will provide these event
> managers with all the actions it and the currently selected game
> needs.
All actions the currently selected game *needs* ? Hm, that might be
possible. But we want to be able to map all the actions the currently
selected games *supports*, too, if possible (e.g. on a desktop
machine with a full keyboard). For many games, it's difficult or next
to impossible to generate such a list, though, since the game scripts
handle the key events (so you would have to manually collect the keys
supported by each game (and variants), and hard code those in a long
list of tables... *Unless* you keep allowing classic key/button
events. But then you force the engines to support both types of
events (key/button vs. "user action" events). At which point I once
more wonder whether we need that, or whether we could not just get
along with only the former... :-)
> It will be the job of the GenericEventManager (a base class for all
> backend specific event managers) to resolve button/action mappings,
> save/load these mappings, open key mapping dialogs, etc.
> GenericEventManager will also provide a way to find out which
> button was actually pressed that generated this specific action as
> this may be needed by some engines (or maybe even simply to return
> pressed buttons, depends on the engine needs). Any other specific
> features may be added by the backend authors in their own
> implementations of GenericEventManager.
>
> Please, write comments of what do you think of this, what features
> will be useful and what not; maybe you also have your own ideas to
> share.
Done :)
Cheers,
Max
More information about the Scummvm-devel
mailing list