请问大家一般是怎么处理键盘输入的？

noslopforever

我的AMConfig每个都是一个对象，不具备继承关系……是按照每个键为组织的，每个键对应一个Stack，Stack里面放的是相应的Action。默认空Stack表示没有任何操作，这样就不会转发出任何Action消息。有的话，就会转发Stack最上元素的Action。
Config总是把Action Push到相应Stack，因此而这个键的旧Action刷掉，这样应该是不会出现循环和多次命中的。因为只有Stack最上的那个Action会被转发。

进入一个状态，就把这个状态对应的AMConfig载入，这就会根据情况刷掉上个状态AM的重合的键。而退出这个状态的时候，自动把这个AMConfig的所有元素全都Pop掉。这就恢复了上一个状态的AM。这个一个不太好的地方是状态不能跳转，只能够顺序。如果进入状态的顺序是ABCD，退出的顺序必须是DCBA，而不能是DACB。大部分情况下这样是可以保证的，但毕竟不是完全的解决方案。所以我过一段时间会改。

AM带来的主要是跨设备的控制，并给游戏逻辑层提供底层设备无关性，不使用的话，小习作可以，大工程最好还是有一个AM，反正相对于大的项目，一个AM很容易了。

noslopforever

PS：我觉得AM应该尽量简单，线型表组织就可以了。太复杂的AM只会提供给使用者不必要的复杂性。而Action的体系可能会比较复杂，但是作为Listener或者Callback，Action的复杂几乎是不可避免的了，还好这是项目提供的，引擎不必提供什么太多的支持。
我的感觉是，只有一个不太复杂的AM体系，才能支持Actions的足够复杂度。 ^_^

sjinny

晕，为什么要用stack……我原来想的是每个键位对应一个链表，这个键被触发时会便利这个链表，如果一个链表项的bool enabled(void)函数为true，那么就调用它的callback……

另外想起来，如果是CheckState，那么岂不是每帧都要把每个键位都check一遍？而且如果以后有效键位增加了还要改动引擎的编码。那样还不如让输入系统来调用我的callback传递事件，这样我只需要把接受到的事件处理一下就行了。

“跨设备的控制”不太明白。
设备无关性……也不明白，因为即使使用时只是注册一下键位和callback，那也需要对不同设备的键位进行区分，而如果是直接检测键位，其实也差不多，似乎用ctrl+c/ctrl+v也麻烦不到哪去。

action的复杂性我倒没感觉到，反正对于输入部分而言，无论什么action都只是一个函数callback而已。至于这个action内部的逻辑，就完全取决于要做什么事了。


我越来越怀疑是否有必要做ActionMapping了……呵呵

noslopforever

晕，为什么要用stack……我原来想的是每个键位对应一个链表，这个键被触发时会便利这个链表，如果一个链表项的bool enabled(void)函数为true，那么就调用它的callback……
-----------------------------------------------------------
这样做的话，手动控制Enable和Disable会让写游戏逻辑的程序员吐血致死。因为大部分情况下，新的Action总是在替代旧的Action。如果新的需要旧的Action的功能，可以有无数种做法。但要是用一个简单的方法，让游戏逻辑脱离大量不必要的Enable和Disable则比较麻烦。Stack的做法只要能保证状态进入和退出的顺序一致，Config就会自动处理Enable和Disable的功能。写游戏逻辑的根本就不用手动Enable和Disable一个Action。



----------------------------------------------------------
另外想起来，如果是CheckState，那么岂不是每帧都要把每个键位都check一遍？而且如果以后有效键位增加了还要改动引擎的编码。那样还不如让输入系统来调用我的callback传递事件，这样我只需要把接受到的事件处理一下就行了。
----------------------------------------------------------
不是每个键位都Check，只是有Action的键才Check。而AM本就是输入系统调用你的Callback啊？我说不是了么？ ^_^
看来是没说清楚。流程是：键消息来的时候，先看有哪些键被Map了，For这些键，每个键，判断是否命中了Action所需求的相应状态（按下、抬起、双击），取Stack top的Action，然后调用Action里面的Callback即可。增加Action只不过是增加Callback，引擎代码不必更改啊。 ^_^否则干嘛做AM啊。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
“跨设备的控制”不太明白。
设备无关性……也不明白，因为即使使用时只是注册一下键位和callback，那也需要对不同设备的键位进行区分，而如果是直接检测键位，其实也差不多，似乎用ctrl+c/ctrl+v也麻烦不到哪去。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
Action射击，可以对应LMouse，也可以对应K键，也可以对应手柄A键，逻辑层只需要关注射击消息是否被触发，不必要去管它不该管的。而在逻辑层检测键位就要麻烦多了。我说过了，小习作可以，大项目危险。





－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
action的复杂性我倒没感觉到，反正对于输入部分而言，无论什么action都只是一个函数callback而已。至于这个action内部的逻辑，就完全取决于要做什么事了。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
对阿，就是写Callback，会比写AM麻烦的多。你如果做一个复杂点的项目就知道了，要写的Callback相对于AM的简单性而言，太多了。
还是那句话：如果只是用OGRE做个习作，真的没必要做AM。

sjinny

嗯……我想不一定要让逻辑程序员手动来enable/disable，也许可以这样：链表里的节点都只是一个基类，bool enabled(void)是个纯虚函数，然后具体的项目从这个基类派生出一个子类，在这个子类里实现bool enabled(void)，实现的时候可以检查一下游戏的状态，然后注册时制定按键、有效的状态、callback就可以了。这样只需要在转换状态时确保更新那个状态变量就可以了。

我说的不是增加action啦，我的意思是，比如说有了新的设备类型，这时虽然输入系统的头文件里会有这些新设备的按键的KeyCode，但是引擎还是要改的，如果不是主动地CheckState，而是被动的接收消息，那么应该只要重新编译一下就好了。

noslopforever

明白了，你说的链表节点可能更像一个消息链，但是实际上Enable这些的被推算到实现的时候去解决了，并不是自动在引擎中解决吧？看来咱们的实现实在差的太远，不过能实现自己的要求的就好，没必要大家的实现都一样，呵呵。我的实现我想我已经说得差不多了，如果你以后感兴趣的话，可以Email我：noslopforever@yahoo.com.cn

至于设备，我不知道你是怎么抽象的，在我这里不存在这个问题。引擎的设备抽象已经避免了这个情况的发生：或者说对我的引擎而言，是不必去管它所接管的设备到底是什么设备，重编译也不必要的，理论上同时使用两个鼠标都可以。具体的实现就不说了，OGRE的很多系统都有类似的实现，呵呵。 ^_^

有空多交流。 ^_^