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

[Serhiy Batyuk]

Hi Max, hi all,

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

Well, I am using gmail web client, but I've turned off HTML format now :)

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

Yes

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

What I meant is that keys from virtual keyboard may also be mapped.
So, we should place a call to resolving a fake virtual key before the
call to backwards mapping function.

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

Sounds logical; for the moment I am using Common::EventType for these
global action IDs, but we can add uint32 type for this reason to be
able to extend IDs with local game IDs.

> Cheers,
> Max

-- 
Best regards,
Serhiy Batyuk