Feature #1229
Input plugins: generate events from connected controllers
0%
Description
Much like the audio plugins, input devices should be abstracted behind a plugin mechanism. An input plugin would feed input events into the engine's input subsystem from any controllers specific to / configured in the plugin.
One input plugin should be able to generate any kind of input events, for instance mouse, joystick, and keyboard events.
See related old proposal: Input drivers
Related issues
History
#1
Updated by skyjake almost 21 years ago
Updated by (originally posted by anonymous SF.net user)
Logged In: NO
Proper support for analog. Instead of holding down run, have
the stick determine your speed.
#2
Updated by skyjake almost 21 years ago
(originally posted by anonymous SF.net user)
Logged In: NO
Abiltity to drag and drop controllers to be used by players 1-4
when splitscreen arrives.
#3
Updated by skyjake over 10 years ago
- Tags set to Input, Plugin
- Category set to Redesign
- Priority changed from Normal to High
There is a related proposal: Input drivers
#4
Updated by skyjake over 10 years ago
- Tags changed from Input, Plugin to Input, Plugin, UI
#5
Updated by skyjake over 10 years ago
- Description updated (diff)
#6
Updated by skyjake about 10 years ago
- Subject changed from Controller plugins to Controller plugins (input drivers)
#7
Updated by skyjake over 9 years ago
- Target version set to 42
#8
Updated by skyjake over 9 years ago
- Related to Feature #1886: Use SDL 2 for window management, display modes, color correction, and keyboard/mouse/gamepad input added
#9
Updated by skyjake over 9 years ago
- Subject changed from Controller plugins (input drivers) to Input plugins: generate events from connected controllers
#10
Updated by skyjake over 9 years ago
- Description updated (diff)
#11
Updated by skyjake over 9 years ago
- Description updated (diff)
#12
Updated by danij about 9 years ago
Updated by - Assignee set to danij
#13
Updated by skyjake almost 9 years ago
- Target version changed from 42 to 2.0 – Home UI & Packages
#14
Updated by skyjake about 8 years ago
- Target version changed from 2.0 – Home UI & Packages to Input and game controllers
#15
Updated by skyjake almost 7 years ago
- Status changed from New to Rejected
- Assignee deleted (
danij) - Target version deleted (
Input and game controllers)
If SDL 2 is used for input (see #1886), having input plugins doesn't really provide much additional value.
#16
Updated by danij over 6 years ago
There are other motivations for at least a virtualized abstraction. For example, while for the most-part we will be communicating with APIs that will all largely follow the same device / control / input abstractions there are countless uncommon controllers used for all kinds of purposes for various accessibility reasons.
Originally input customization features have been limited to console scripts, for the purposes of automating the generation of event sequences. Nowadays things are handled a bit differently, with bindable modifiers et al. Also, on game side we have a special case mechanism for handling cheat codes using a high priority event responder.
Architecturally it would be nice to deal with both issues. Perhaps we could leverage Doomsday Script here?