Add initial axis input proposal draft #2415
Conversation
|
@dotnet-policy-service agree |
| public class DualsenseDevice : IAxisDevice | ||
| { | ||
| IReadOnlyList<AxisDescription> | ||
| private static readonly IReadOnlyList<AxisDescription> Axes = |
There was a problem hiding this comment.
I know this is INFORMATIVE TEXT but... triggers? Only reason I mention it is because it's quite pertinent for DualSense specifically. Feel free to ignore this comment though as it may open irrelevant discussions now I mention it (namely application-controlled axes like the haptic feedback)
There was a problem hiding this comment.
I haven't yet thought of any sort of API for axis output yet. my thoughts were outputs could be a non-breaking extension to this API as you mightve guessed - lots of things to consider there (and potentially lots of input-related expansions too e.g. microphone/audio out, LEDs, etc). i have no problem re-visiting this to properly complete the axis list though
There was a problem hiding this comment.
I do think it would be a shame to accept the proposal not having a path to implementing the base proposal in terms of this proposal, as that is ultimately one of the main goals.
A lot of the benefits we get from this axis model still exist without that mind e.g. it makes developing an input action model a lot easier, but we should have a clear strategy for getting to the future we want. And if we accept this proposal without everything, we open up opportunities to have fragmented implementations given that we'd have to care about backwards compatibility if it does get implemented without the other proposals being approved.
There was a problem hiding this comment.
lemme stew a bit. i just dont want to paint ourselves into a corner with device outputs (since some may not be very simple - e.g. streaming outputs that arent abstractable to a floating point value)
| /// <summary> | ||
| /// An interface for handling deadzones in different ways | ||
| /// </summary> | ||
| public interface IDeadzoneHandler |
There was a problem hiding this comment.
Sceptical about calling this IDeadzoneHandler given that in our input API "handlers" usually refer to our actor-like model for handling input events.
Maybe IDeadzoneDeterminant, or maybe call this IDeadzone and rename Deadzone to DeadzoneBounds? Or something else?
There was a problem hiding this comment.
the naming was an attempt to keep the API consistent with how people will be used to handling input events, though if this doesn't actually follow the model of the others then I'm totally down to change the name. Though not crazy about those names in particular bc i think it's less clear
we can shop it with The Gang? ¯_(ツ)_/¯
Co-authored-by: Dylan Perks <[email protected]>
Co-authored-by: Dylan Perks <[email protected]>
Co-authored-by: Dylan Perks <[email protected]>
…xisGroupType.Position2D and 3D
this feedback was more-or-less answered by myself in the axis group priority section. if we need or would like to provide anything more specific, it could be an extension method
ty perksey :) Co-authored-by: Dylan Perks <[email protected]>
Summary of the PR
Adds the axis-based input proposal's first draft
Related issues, Discord discussions, or proposals
Several I've lost track of and I am sorry to report I am feeling particularly lazy after spewing so many words from my fingertips in a single afternoon
Further Comments
Any and all feedback ahead of our discussion this sunday is welcome - even if just for clarity of writing, and especially re: the contents of the proposal