Changes between Version 2 and Version 3 of code/doc/InputManager
- Timestamp:
- Sep 15, 2008, 9:28:44 PM (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
code/doc/InputManager
v2 v3 17 17 Now, why distinguishing between the input devices? Whenever an InputState discards input, it is handed over to the next in line (by priorities), but for each device separately. Consider the example from above: You are playing in a level and call the console. Would there be any reason not to use the mouse to steer the game in that instant? No. So you can. And that requires differentiation between devices when distributing input to the input states. 18 18 19 === State switching === 20 Tis is the easy part. Once the state is created and therefore registered in the InputManager, you can activate it by calling 'requestEnterState(state as string)' and deactivate it with 'requestLeaveState(state as string)'. Activation doesn't necessarily mean that the input gets sent there. The priority among the active states are still present. 21 19 22 === The Master InputState === 20 23 This state is always active after the InputManager has been created. It can be used to log input for instance if that is desired. The main purpose however is to reserve certain keys that always have a function, like the key to open the console. In order to realise that, a KeyBinder is used.