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

Max Horn max at quendi.de
Sun Jul 15 17:15:45 CEST 2007


Hi Serhiy, hi all,

First off: Your mail was using HTML quoting, which made it a bit  
tricky for me to reply, since your email client apparently is bugging  
and does not properly quote text in the plain text part of your  
email. Hence I had to manually mark quotes in your email as such.  
Hopefully I didn't forget any...


Am 13.07.2007 um 14:51 schrieb 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.

Yes, that's how I meant it. 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;
Agreed.

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

I assume you mean here something like this: "once a backend key or  
button is triggered, the backend check if that key/button has been  
(re)mapped, and if that is the case, will generate an appropriate  
event for the mapped control".


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

Actually, the virtual keyboard would simply generate "fake" keyboard  
events. The question is which keys it should show (letters, digits --  
also shift, control, alt, tab, esc...). For that part, though, it  
would be independent from the key mapping code -- at least I don't  
see right now how that would be involved at all. That is, for one  
thing it might be nifty: We could add also "quit", "mainmenu" etc.  
buttons to the virtual keyboard based on the useractions. But I am  
not sure that this would be such a great idea after all (considering  
space is scarce).

While I am thinking about this: The virtual keyboard should be  
reachable in all games; and so should the key remapping dialog. In  
the end this gets back to the old idea of a "global main menu  
dialog". This dialog would contain buttons for options, quit, key  
remapping, "about", and possibly more. See <http://wiki.scummvm.org/ 
index.php/User:Fingolfin#GUI> for some details.


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

What I meant is this: Each "UserAction" has an id or type. Think of  
an enum containing kPauseAction, kShowMainMenuAction, kSaveAction,  
kQuickSaveSlot5Action, kQuickLoadSlot3Action, kIndyLowPunchAction, etc.

Some of these actions are generic enough to be used in many engines  
(e.g. kPauseAction), while others are highly engine or even game  
specific (kIndyLowPunchAction...). So, the generic ones, we could  
define in a global header. But I don't think we should try to list  
*all* action IDs in such a global header. Instead, engines should be  
allowed to define their own custom action IDs. And they should be  
able to make up custom ones on the fly.

What is the point behind action IDs? Well, they help to provide some  
consistency: Ideally, you want the "pause" function to be mapped to  
the same button/key in *all* games. To make that possible, we just  
tell the backend which of the many actions we are mapping is actually  
the "pause" one.


Cheers,
Max




More information about the Scummvm-devel mailing list