[Scummvm-devel] RFC: Flexible keymapping via new EVENT_ (post 0.10) (Serhiy Batyuk)

[Serhiy Batyuk]

Hi Max,

Taking into consideration your comments, here is a new refined proposal of
key mapping implementation.

On 7/13/07, Max Horn <max at quendi.de> wrote:
>
> 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.


I also agree that key/button press events will save us a lot of work. That
is what I actually wanted to get from you as a feedback on UserActionType
enum.
So, as you probably also mean it, I propose to use UserAction struct (maybe,
even renaming it to ActionMapping, to better reflect its purpose) strictly
for mapping purposes. How this will look like:

- I will repeat myself, but each engine/game will have a list of
ActionMapping constant objects with their string descriptions and default
keys;
- now, the default keys will be the keys currently used in the
engines/games;
- once the engine registers its supported actions with the event manager,
the event manager will map its available inputs to these default keys;
- with regard to such event as EVENT_QUIT I don't see a reason to use a new
UserActionType enum instead of already present EventType enum;
- in the pollEvent function, once a backend key is triggered, the backend
will look and find the correct default key and/or the corresponding EnumType
to set into the Event struct; (this way we don't have to modify the engines'
code at all)

By the way, as you pointed this Max, it would be nice to have default key
mapping tables for all the backends.
And, yes, it seems that virtual keyboard should fit nicely into this idea of
key mapping.

> 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.


Yeah, sure, we can add a priority field to ActionMapping.

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.


We can simply use register/unregister mappings functionality to achieve
that.

> 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.


Not sure I get the idea of engine and game IDs. Can you, please, describe it
in more detail?

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 :-).


It was but I agree it would take too much time to develop

-- 
Best regards,
Serhiy Batyuk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20070713/512ad88a/attachment.html>