Skip to content

Docs review #866

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jechter merged 3 commits into from
Sep 18, 2019
Merged

Docs review #866

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ebb2df6
Docs feedback
jechter Sep 18, 2019
d073522
Fix links
jechter Sep 18, 2019
6897381
format
jechter Sep 18, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
96 changes: 49 additions & 47 deletions Packages/com.unity.inputsystem/Documentation~/ActionAssets.md
View file
Open in desktop

Large diffs are not rendered by default.

174 changes: 89 additions & 85 deletions Packages/com.unity.inputsystem/Documentation~/ActionBindings.md
View file
Open in desktop

Large diffs are not rendered by default.

176 changes: 89 additions & 87 deletions Packages/com.unity.inputsystem/Documentation~/Actions.md
View file
Open in desktop

Large diffs are not rendered by default.

24 changes: 12 additions & 12 deletions Packages/com.unity.inputsystem/Documentation~/Architecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,27 +1,27 @@
# Architecture

The input system has a layered architecture. Principally, it divides into a low-level and a high-level layer.
The Input System has a layered architecture that consists of a low-level layer and a high-level layer.

# Native Backend

The foundation of the input system is the native backend code. This is highly platform-specific code which collects information about available devices and input data from devices. This code is not part of the Input System package, but is included in Unity itself instead, and has implementations for each runtime platform supported by Unity (This is also why some platform-specific input bugs can only be fixed by an update to Unity, and not by a new version of the Input System package).
The foundation of the Input System is the native backend code. This is highly platform-specific code which collects information about available Devices and input data from Devices. This code is not part of the Input System package, but is included with Unity itself. It has implementations for each runtime platform supported by Unity. This is also why some platform-specific input bugs can only be fixed by an update to Unity, and not by a new version of the Input System package.

The Input System interfaces with the native backend using [events](Events.md) which are sent by the native backend. These events notify the system of the creation and removal of input [devices](Devices.md), as well as of any updates to the state of devices. For efficiency and to avoid creating any garbage, the native backends reports the events as a simple buffer of raw, unmanaged memory containing a stream of events.
The Input System interfaces with the native backend using [events](Events.md) that the native backend sends. These events notify the system of the creation and removal of [Input Devices](Devices.md), as well as any updates to the Device states. For efficiency and to avoid creating any garbage, the native backend reports these events as a simple buffer of raw, unmanaged memory containing a stream of events.

The Input System can also send data back to the native backend in the form of [commands](Devices.md#device-commands) sent to devices, which are also buffers of memory which are interpreted by the native backend and can have different meanings for different device types and platforms.
The Input System can also send data back to the native backend in the form of [commands](Devices.md#device-commands) sent to Devices, which are also buffers of memory that the native backend interprets. These commands can have different meanings for different Device types and platforms.

# Input System Low-Level
# Input System (low-level)

The low-level input system code will process and interpret the memory from the event stream provided by the native backend, and dispatch individual events.
The low-level Input System code processes and interprets the memory from the event stream that the native backend provides, and dispatches individual events.

The input system will create device representations for any newly discovered device in the event stream. For the low-level code, an input device is represented as a block of raw, unmanaged memory. If a state event is received for a device, the data from the state event will be written into the device's [state representation](Controls.md#control-state) in memory, so that the state always contains an up-to-date representation of the device and all it's controls.
The Input System creates Device representations for any newly discovered Device in the event stream. The low-level code sees a Device as a block of raw, unmanaged memory. If it receives a state event for a Device, it writes the data from the state event into the Device's [state representation](Controls.md#control-state) in memory, so that the state always contains an up-to-date representation of the Device and all its Controls.

The low-level system code also contains structs which describe the data layout of commonly known devices.
The low-level system code also contains structs which describe the data layout of commonly known Devices.

# Input System High-Level
# Input System (high-level)

It's the job of the high-level input system code to interpret the data in device's state buffers. To do this, it uses the concept of [layouts](Layouts.md), which describe the data layout of a device and it's controls in memory. Layouts are created from either the pre-defined structs of commonly known devices supplied by the low level system, or dynamically at runtime, as in the case of [generic HIDs](HID.md#auto-generated-layouts).
The high-level Input System code interprets the data in Device's state buffers by using [layouts](Layouts.md), which describe the data layout of a Device and its Controls in memory. The Input System creates layouts from either the pre-defined structs of commonly known Devices supplied by the low level system, or dynamically at runtime, as in the case of [generic HIDs](HID.md#auto-generated-layouts).

Based on the information in the layouts, the input system will then create [control](Controls.md) representations for each of the devices controls, which let you read the state of each individual control in a device.
Based on the information in the layouts, the Input System then creates [Control](Controls.md) representations for each of the Device's controls, which let you read the state of each individual Control in a Device.

The high-level system then also allows you to build another abstraction layer to map input controls to your game mechanics, by using [actions](Actions.md). Actions allow you to [bind](ActionBindings.md) one or multiple controls to an input in your game. The input system will then monitor these controls for state changes, and notify your game logic using [callbacks](Actions.md#responding-to-actions). You can also specify more complex behaviors for your actions using [Processors](Processors.md) (which perform processing on the input data before sending it to you) and [Interactions](Interactions.md) (which let you specify patterns of input on a control to listen to, such as multi-taps, etc).
The high-level system also allows you to build another abstraction layer to map Input Controls to your game mechanics, by using [Actions](Actions.md). Actions allow you to [bind](ActionBindings.md) one or more Controls to an input in your game. The Input System then monitors these Controls for state changes, and notifies your game logic using [callbacks](Actions.md#responding-to-actions). You can also specify more complex behaviors for your Actions using [Processors](Processors.md) (which perform processing on the input data before sending it to you) and [Interactions](Interactions.md) (which let you specify patterns of input on a Control to listen to, such as multi-taps).
Loading