| 9 | | == OIS == |
| 10 | | [wiki: OIS] is the cross platform input library we are using. It is object oriented and supports all the features we need. |
| 11 | | |
| 12 | | == InputManager == |
| 13 | | Captures input and distributes it to the right InputState |
| 14 | | |
| 15 | | == InputState == |
| 16 | | |
| 17 | | |
| 18 | | == KeyBinder == |
| 19 | | |
| 20 | | |
| 21 | | == Tools == |
| 22 | | |
| 23 | | |
| 24 | | === KeyDetector === |
| 25 | | |
| 26 | | |
| 27 | | === Calibrator === |
| | 10 | == Capturing and distributing the input == |
| | 11 | We get input events from the OIS library in the form a function callback realised with inheritance. The class (and object at the same time) responsible for this task is the [wiki:InputManager]. It initialises the OIS components and input devices and takes care of the so called [wiki:InputState InputStates]. These again, act like input managers themselves in a way, just a lot smaller in implementation.[[br]] |
| | 12 | The general idea behind this concept is the fact that input distribution is heavily dependent on what is currently running. Simple examples are the console (only captures text), a GUI menu or the orxonox level itself.[[br]] |
| | 13 | These InputStates can then hold [wiki:InputHandler Handlers] that are thought to be fixed when everything is set up. These Handlers do the actual job. For instance the [wiki:KeyBinder] gets an input event and then maps it to an executable command in the form of a string. That command is then passed to the [wiki:CommandExecutor].[[br]] |
| | 14 | So much about the overall concept. Read more in the corresponding sections, mostly classes though. |