Location: Main > Module Types > View Module Type

Input Modules

Engine Module Type StringInput
Module Type UsageSingle Type


Input Modules enable the Drag[en]gine to receive input from a user. Input modules are Single Type modules since only one can acquire input devices at the same time. You can use though for different games different Graphic modules if you like. This module is not the most important one. Usually there is only one for an operating system. Launchers usually do not download Input modules on their own since games do not request them.

User Informations

Input varies from operating system to operating system. Therefore for each of them exists an own Input module. Usually it is enough to pick the default Input module for your system. There can be though different modules to support input devices not commonly supported by other Input modules. The choice is usually done depending on the supported input devices.

Module Developer Informations

One of the major problems faced by Input Modules is the type of encoding to use. Every operating system has a different way of handling input and what encoding is used. To keep things simple the Input Module is required to provide all keyboard related input in the Unicode encoding. Now there exists two kinds of inputs you can acquire from a keyboard: down/up or type. The down/up event indicates if a certain key is pressed or released on the keyboard. Most keys have a multiple characters that can be produced but for the down/up event we are only interested in the major character. No modifications have to be applied to the keys hence pressing the 'A' key has to produce a 'a' key press/release event. The returned value has to be an ASCII value ( in the range 0 to 127 ). This is no problem as the first 128 characters in Unicode are matching the ASCII ones. The type event on the other hand can produce combined characters. A combined character for example would be '@' on certain keyboard layouts. Combined characters are all characters which you can only generate by typing two or more keys together ( shift, control, alt ), in sequence ( dead characters ) or that are not part of ASCII. All those characters have to be returned as Unicode value.

Another big problem is auto-repeating. Most operating systems generate a sequence of key down/up events if you press and keep down a key on your keyboard. Some systems resend only the key down event whereas others resend both key down and key up events. Input Modules are required to completely ignore any kind of auto-repeating that is in effect on the host computer. Only the raw key down/up and type events have to be send and repeated ones to be discarded. Auto-Repeating will be implemented in the Scripting Module to produce a concise result across multiple platforms.

Mouse movement can also be recorded in two possible ways: absolute and relative. In the absolute mode we register the current position of the cursor on the screen. In the relative mode we register only the actual movement done by the mouse no matter if the screen pointer is clipped to the screen boundary or moves. The Input Module has to provide the mouse input in relative mode to the engine. For this purpose mouse capturing can be used if properly given up in time. If the keyboard or mouse is captured and the engine enters recovery mode those captures have to be released to avoid interfering with the Crash Recovery Module.

To get started with Input modules have a look at these classes:

Note: The input system is still worked on hence it will change until the first release.