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

[Max Horn]

Am 13.07.2007 um 14:08 schrieb Marcus Comstedt:

>
> "Max Horn" <max at quendi.de> writes:
>
> [...]
>> After all, confusing UI are bad (but I think the confusion can be
>> minimized in this case, in particular, "pause" would be "pause"  
>> even in
>> fight mode), but not being able to pass a section of the game due  
>> to a
>> lack of input mapping certainly is worse...
>
> What would guarantee that "pause" is still "pause" if new higher
> priority actions are dynamically added?  After all, "pause" would
> have to be rather low priority since it's never(?) needed to complete
> a game.  If there are not enough buttons to have both "pause" and
> fighting buttons, and fighting buttons are needed to complete the
> game, "pause" needs to go.
>

Good points. Let me try to address them...

First off, let me make clear that my remark as intended as a general  
remark concerning "problems and desirable features" of our input  
handling code, and is not tied to the particular proposal we are  
discussing here. So, one way to "guarantee" the above is to do what  
some existing backends do: Hard code special support for Indy4.  
Nothing automatic in here, so the programmer is responsible for  
guaranteeing this.

Of course we want to try to get away from such hard coded assumption.  
In the context of the new system we discussing and design here, the  
pause key would be fixed by two things: First off, it would have a  
high priority, and the mapper would take that into account; secondly,  
it would have the same "action ID" both in normal and in fighting  
mode. The mapper would recognize this, and try to keep using the same  
key for pause in all cases.

This touches a general problem of an "automated" mapper: Not all keys/ 
inputs are totally independent. Some physical requirements may have  
to be taken into account. For example, if a game wants to map the  
arrow keys for movement control, then ideally the backend/keymapper  
would map those to buttons in a similar physical arrangement as on  
the PC keyboard; or map them to a "joystick" / "D-pad" control (which  
many console controllers offer). Another example wold be volume up/ 
down controls, which should be mapped to neighboring keys by default,  
not keys on opposite ends of the controller.

I am not yet sure how we achieve that. Two things come to mind: By  
predefining some "action IDs" (for pause, quit, main menu, etc.), we  
can map these to "appropriate" keys (pause/exit maybe to the "start"  
button, and so on). Secondly, we could consider extending the  
proposal to allow grouping controls. That is, the four "arrow  
controls" would be grouped together, and the mapper would try to  
either map all of them at once, or none, and would try to map them to  
"close" controls... This is still rather fuzzy. Maybe it won't work  
out, maybe we just need sufficient predefined action IDs, and then  
incorporate knowledge into the "mapping" code of each backend as to  
how to map certain actions "best". We'll see...


Bye,
Max