[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