Input Module Planning

Tacent Input Module

The next module for Tacent is going to be for controller and gamepad input.

The Input Module handles retrieving input from various devices including gamepads that may be attached. A few definitions are helpful to describe the types and nomenclature used in this module. We'll start from the top-down.

Device

A device is a piece of hardware attached to your computer that supports providing the computer with one or more forms of input. A gamepad / xbox 360 controller is a device. There is a one-to-one mapping between the specific tDevice sub-class and a physical device. The tDevice base class provides common functionality for a sub-classed tDevice type. Currently the only supported device is a 360 controller or suitable compatible devices like the 8BitDo. All instances of a tDevice have a unique identifier in case multiple are plugged in simultaneously. Devices contain one or more "components" described below.

Component

A component is one of possibly many pieces of "independent" input hardware in a device. For example, a gamepad device often has two joysticks, multiple buttons, triggers, and a d-pad. A component is basically a base class that contains a unique identifier/name for every part of a device. Some components have multiple dependent parts. For example, a joystick has two axis units, but these are controlled by a single physical 'stick' which means that, for example, dead-zone calculations need to take into account both axes to be done correctly. Units are described below.

Unit

The atom of the input world. Indivisible. An input unit is one of (usually many) pieces of hardware in a device that reads a single user input. A physical button, for example, is an input unit. So is one of the axes of a joystick. Note that a joystick is not a unit -- it is a component made with two axis units, one for each orthogonal direction. There is a one-to-one mapping between the tUnit class and a physical device that reads a single value. Units do not do any input processing so no dead-zone or anti-jitter functionality exists in units themselves -- they simply get updated/clamped and have accessors. The supported input units are described below.

Summary

In short, a device is made up of components, and components are made up of units.

• Devices are uniquely identified and have names.
• Components are uniquely defined within a device and have names.
• Units are uniquely defined within a component. All three exist in the tInput namespace and have base classes: tDevice, tComponent, and tUnit.

Sub classes start with the following prefixes to identify them:

• td : Tacent Input Device.
• tc : Tacent Input Component.
• tu : Tacent Input Unit.

Supported Units

• tuBoolean
  A binary unit that is either on or off. Think buttons and switches. No intermediate states.

• tuMultiState
  An input unit with multiple input states. Things like a button that responds to different pressure levels.

• tuAxis
  An input unit that contains a value in [-1.0, 1.0]. Things like a trigger are made of one of these. Things like a joystick are made of two of these.

• tuDisplacement
  An input unit that reports a value in [0.0, 1.0]. Displacement units do not return to any default/resting position if untouched. May need anti-jitter to be implemented.

Supported Components

• tcButton
  Contains a single tuBoolean. Buttons always return to their default off state when not physically held down.

• tcSwitch
  Contains a single tuBoolean. Switches remain in the state they're set to last. On or off.

• tcDirectionPad
  D-Pads are made of dependent tuBoolean units, one for each or the 4 cardinal directions. They are dependent because they are mechanically restricted from all being pressed at the same time. Typically only one or two of the 4 buttons may be simultaneously engaged (at 45 degrees). They all return to the off state if no physical input.

• tcTrigger
  Made up of a single tuDisplacement. Dead-zone implemented for values close to zero, plus optional anti-jutter. Returns to 0 if no physical input applied.

• tcPedal
  Made up of a single tuDisplacement. Dead-zone implemented for values close to zero, plus optional anti-jutter. Returns to 0 if no physical input applied.

• tcJoystick
  A joystick contains one tuAxis for the horizontal (X) direction, and another for the vertical (Y) direction. The axes of a joystick are NOT independent since the same physical stick displaces both X and Y magnets for the hall effect transistors to pick up. This class implements dead-zone and anti-jitter correctly as it can read both axes. It's 'resting' position is 0.0 and is unstable due to the small physical forces (often springs) keeping it at 0. No physical input and a joystick returns to 0.0 for both X and Y axes.

• tcDial
  Made up of a single tuDisplacement. Dials do not return to 0. Implement anti-jitter but no dead zone. Used for things like volume control knobs.

• tcSlider
  Made up of a single tuDisplacement. Sliders do not return to 0. Implement anti-jitter but no dead zone.

Device Manager

Describe how it polls and directly updates all the devices input units. It starts a thread for the input polling for this purpose. Members are mutex protected so the main thread can read the devices components.