diff --git a/Packages/com.unity.inputsystem/InputSystem/Actions/InputActionTrace.cs b/Packages/com.unity.inputsystem/InputSystem/Actions/InputActionTrace.cs index cbeb641a92..95c4703d54 100644 --- a/Packages/com.unity.inputsystem/InputSystem/Actions/InputActionTrace.cs +++ b/Packages/com.unity.inputsystem/InputSystem/Actions/InputActionTrace.cs @@ -6,19 +6,6 @@ using Unity.Collections.LowLevel.Unsafe; using UnityEngine.InputSystem.LowLevel; -////REVIEW: why not switch to this being the default mechanism? seems like this could allow us to also solve -//// the actions-update-when-not-expected problem; plus give us access to easy polling - -////REVIEW: should this automatically unsubscribe itself on disposal? - -////TODO: make it possible to persist this same way that it should be possible to persist InputEventTrace - -////TODO: make this one thread-safe - -////TODO: add random access capability - -////TODO: protect traces against controls changing configuration (if state layouts change, we're affected) - namespace UnityEngine.InputSystem.Utilities { /// diff --git a/Packages/com.unity.inputsystem/InputSystem/Actions/InputBindingComposite.cs b/Packages/com.unity.inputsystem/InputSystem/Actions/InputBindingComposite.cs index d3d46bf959..72db218f66 100644 --- a/Packages/com.unity.inputsystem/InputSystem/Actions/InputBindingComposite.cs +++ b/Packages/com.unity.inputsystem/InputSystem/Actions/InputBindingComposite.cs @@ -6,15 +6,6 @@ using UnityEngine.InputSystem.Utilities; using UnityEngine.Scripting; -////TODO: support nested composites - -////REVIEW: composites probably need a reset method, too (like interactions), so that they can be stateful - -////REVIEW: isn't this about arbitrary value processing? can we open this up more and make it -//// not just be about composing multiple bindings? - -////REVIEW: when we get blittable type constraints, we can probably do away with the pointer-based ReadValue version - namespace UnityEngine.InputSystem { ////TODO: clarify whether this can have state or not diff --git a/Packages/com.unity.inputsystem/InputSystem/Controls/InputControl.cs b/Packages/com.unity.inputsystem/InputSystem/Controls/InputControl.cs index 8b0ae4699b..4ea6943039 100644 --- a/Packages/com.unity.inputsystem/InputSystem/Controls/InputControl.cs +++ b/Packages/com.unity.inputsystem/InputSystem/Controls/InputControl.cs @@ -8,26 +8,6 @@ using Unity.Collections.LowLevel.Unsafe; using UnityEngine.InputSystem.Layouts; -////REVIEW: should EvaluateMagnitude() be called EvaluateActuation() or something similar? - -////REVIEW: as soon as we gain the ability to have blittable type constraints, InputControl should be constrained such - -////REVIEW: Reading and writing is asymmetric. Writing does not involve processors, reading does. - -////REVIEW: While the arrays used by controls are already nicely centralized on InputDevice, InputControls still -//// hold a bunch of reference data that requires separate scanning. Can we move *all* reference data to arrays -//// on InputDevice and make InputControls reference-free? Most challenging thing probably is getting rid of -//// the InputDevice reference itself. - -////REVIEW: how do we do stuff like smoothing over time? - -////TODO: allow easier access to the default state such that you can easily create a state event containing only default state - -////TODO: come up with a way where we do ReadValue on the most common forms/setups of controls and not have any virtual method dispatch but -//// rather go with minimal overhead directly to reading out memory -//// (this should at least cover FLT, single BIT, and INT controls; and should be able to apply the common transformations -//// as per AxisControl) - namespace UnityEngine.InputSystem { /// diff --git a/Packages/com.unity.inputsystem/InputSystem/Controls/InputControlLayout.cs b/Packages/com.unity.inputsystem/InputSystem/Controls/InputControlLayout.cs index 3d7430d722..3f36895354 100644 --- a/Packages/com.unity.inputsystem/InputSystem/Controls/InputControlLayout.cs +++ b/Packages/com.unity.inputsystem/InputSystem/Controls/InputControlLayout.cs @@ -8,55 +8,6 @@ using UnityEngine.InputSystem.LowLevel; using UnityEngine.InputSystem.Utilities; -////TODO: *kill* variants! - -////TODO: we really need proper verification to be in place to ensure that the resulting layout isn't coming out with a bad memory layout - -////TODO: add code-generation that takes a layout and spits out C# code that translates it to a common value format -//// (this can be used, for example, to translate all the various gamepad formats into one single common gamepad format) - -////TODO: allow layouts to set default device names - -////TODO: allow creating generic controls as parents just to group child controls - -////TODO: allow things like "-something" and "+something" for usages, processors, etc - -////TODO: allow setting whether the device should automatically become current and whether it wants noise filtering - -////TODO: ensure that if a layout sets a device description, it is indeed a device layout - -////TODO: make offset on InputControlAttribute relative to field instead of relative to entire state struct - -////REVIEW: common usages are on all layouts but only make sense for devices - -////REVIEW: useStateFrom seems like a half-measure; it solves the problem of setting up state blocks but they often also -//// require a specific set of processors - -////REVIEW: Can we allow aliases to be paths rather than just plain names? This would allow changing the hierarchy around while -//// keeping backwards-compatibility. - -// Q: Why is there this layout system instead of just new'ing everything up in hand-written C# code? -// A: The current approach has a couple advantages. -// -// * Since it's data-driven, entire layouts can be represented as just data. They can be added to already deployed applications, -// can be sent over the wire, can be analyzed by tools, etc. -// -// * The layouts can be rearranged in powerful ways, even on the fly. Data can be inserted or modified all along the hierarchy -// both from within a layout itself as well as from outside through overrides. The resulting compositions would often be very -// hard/tedious to set up in a linear C# inheritance hierarchy and likely result in repeated reallocation and rearranging of -// already created setups. -// -// * Related to that, the data-driven layouts make it possible to significantly change the data model without requiring changes -// to existing layouts. This, too, would be more complicated if every device would simply new up everything directly. -// -// * We can generate code from them. Means we can, for example, generate code for the DOTS runtime from the same information -// that exists in the input system but without depending on its InputDevice C# implementation. -// -// The biggest drawback, other than code complexity, is that building an InputDevice from an InputControlLayout is slow. -// This is somewhat offset by having a code generator that can "freeze" a specific layout into simple C# code. For these, -// the result is code at least as efficient (but likely *more* efficient) than the equivalent in a code-only layout approach -// while at the same time offering all the advantages of the data-driven approach. - namespace UnityEngine.InputSystem.Layouts { /// diff --git a/Packages/com.unity.inputsystem/InputSystem/Devices/Pointer.cs b/Packages/com.unity.inputsystem/InputSystem/Devices/Pointer.cs index 4a6b3bf2df..960dee0f65 100644 --- a/Packages/com.unity.inputsystem/InputSystem/Devices/Pointer.cs +++ b/Packages/com.unity.inputsystem/InputSystem/Devices/Pointer.cs @@ -5,26 +5,6 @@ using UnityEngine.InputSystem.Utilities; using UnityEngine.Scripting; -////TODO: add capabilities indicating whether pressure is supported - -////REVIEW: is there an opportunity to collapse "press" and "pressure" into one? after all, if there's any pressure, isn't the pointer pressed? - -////REVIEW: should "displayIndex" be called "windowIndex"? or be part of a better thought-out multi-display API altogether? - -////REVIEW: add click and clickCount controls directly to Pointer? -//// (I gave this a look but in my initial try, found it somewhat difficult to add click detection at the Pointer level due -//// to the extra state it involves) - -////REVIEW: should we put lock state directly on Pointer? - -////REVIEW: should pointer IDs be required to be globally unique across pointing devices? -////REVIEW: should we create new devices instead of using pointer IDs? - -////FIXME: pointer deltas in EditorWindows need to be Y *down* - -////REVIEW: kill EditorWindowSpace processor and add GetPositionInEditorWindowSpace() and GetDeltaInEditorWindowSpace()? -//// (if we do this, every touch control has to get this, too) - namespace UnityEngine.InputSystem.LowLevel { /// diff --git a/Packages/com.unity.inputsystem/InputSystem/Devices/Touchscreen.cs b/Packages/com.unity.inputsystem/InputSystem/Devices/Touchscreen.cs index 69735b1abe..3463559f82 100644 --- a/Packages/com.unity.inputsystem/InputSystem/Devices/Touchscreen.cs +++ b/Packages/com.unity.inputsystem/InputSystem/Devices/Touchscreen.cs @@ -8,25 +8,6 @@ using UnityEngine.InputSystem.Utilities; using Unity.Profiling; -////TODO: property that tells whether a Touchscreen is multi-touch capable - -////TODO: property that tells whether a Touchscreen supports pressure - -////TODO: add support for screen orientation - -////TODO: touch is hardwired to certain memory layouts ATM; either allow flexibility or make sure the layouts cannot be changed - -////TODO: startTimes are baked *external* times; reset touch when coming out of play mode - -////TODO: detect and diagnose touchId=0 events - -////REVIEW: where should we put handset vibration support? should that sit on the touchscreen class? be its own separate device? - -////REVIEW: Given that Touchscreen is no use for polling, should we remove Touchscreen.current? - -////REVIEW: Should Touchscreen reset individual TouchControls to default(TouchState) after a touch has ended? This would allow -//// binding to a TouchControl as a whole and the action would correctly cancel if the touch ends - namespace UnityEngine.InputSystem.LowLevel { [System.Diagnostics.CodeAnalysis.SuppressMessage("Microsoft.Design", "CA1028:EnumStorageShouldBeInt32", Justification = "byte to correspond to TouchState layout.")] diff --git a/Packages/com.unity.inputsystem/InputSystem/InputManager.cs b/Packages/com.unity.inputsystem/InputSystem/InputManager.cs index f2242eac9a..1edf9ad90f 100644 --- a/Packages/com.unity.inputsystem/InputSystem/InputManager.cs +++ b/Packages/com.unity.inputsystem/InputSystem/InputManager.cs @@ -28,22 +28,6 @@ using CustomBindingPathValidator = System.Func; #endif -////TODO: make diagnostics available in dev players and give it a public API to enable them - -////TODO: work towards InputManager having no direct knowledge of actions - -////TODO: allow pushing events into the system any which way; decouple from the buffer in NativeInputSystem being the only source - -////REVIEW: change the event properties over to using IObservable? - -////REVIEW: instead of RegisterInteraction and RegisterProcessor, have a generic RegisterInterface (or something)? - -////REVIEW: can we do away with the 'previous == previous frame' and simply buffer flip on every value write? - -////REVIEW: should we force keeping mouse/pen/keyboard/touch around in editor even if not in list of supported devices? - -////REVIEW: do we want to filter out state events that result in no state change? - #pragma warning disable CS0649 namespace UnityEngine.InputSystem { diff --git a/Packages/com.unity.inputsystem/InputSystem/InputSettings.cs b/Packages/com.unity.inputsystem/InputSystem/InputSettings.cs index 013be0c13a..03a81d2150 100644 --- a/Packages/com.unity.inputsystem/InputSystem/InputSettings.cs +++ b/Packages/com.unity.inputsystem/InputSystem/InputSettings.cs @@ -6,26 +6,6 @@ using UnityEngine.InputSystem.Processors; using UnityEngine.InputSystem.Utilities; -////TODO: make sure that alterations made to InputSystem.settings in play mode do not leak out into edit mode or the asset - -////TODO: handle case of supportFixedUpdates and supportDynamicUpdates both being set to false; should it be an enum? - -////TODO: figure out how this gets into a build - -////TODO: allow setting up single- and multi-user configs for the project - -////TODO: allow enabling/disabling plugins - -////REVIEW: should the project settings include a list of action assets to use? (or to force into a build) - -////REVIEW: add extra option to enable late-updates? - -////REVIEW: put default sensor sampling frequency here? - -////REVIEW: put default gamepad polling frequency here? - -////REVIEW: Have an InputActionAsset field in here that allows having a single default set of actions that are enabled with no further setup? - namespace UnityEngine.InputSystem { /// diff --git a/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs b/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs index a5beeb412f..cd155adeda 100644 --- a/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs +++ b/Packages/com.unity.inputsystem/InputSystem/InputSystem.cs @@ -28,27 +28,6 @@ using CustomBindingPathValidator = System.Func; #endif -////TODO: allow aliasing processors etc - -////REVIEW: rename all references to "frame" to refer to "update" instead (e.g. wasPressedThisUpdate)? - -////TODO: add APIs to get to the state blocks (equivalent to what you currently get with e.g. InputSystem.devices[0].currentStatePtr) - -////FIXME: modal dialogs (or anything that interrupts normal Unity operation) are likely a problem for the system as is; there's a good -//// chance the event queue will just get swamped; should be only the background queue though so I guess once it fills up we -//// simply start losing input but it won't grow infinitely - -////REVIEW: make more APIs thread-safe? - -////REVIEW: it'd be great to be able to set up monitors from control paths (independently of actions; or should we just use actions?) - -////REVIEW: have InputSystem.onTextInput that's fired directly from the event processing loop? -//// (and allow text input events that have no associated target device? this way we don't need a keyboard to get text input) - -////REVIEW: split lower-level APIs (anything mentioning events and state) off into InputSystemLowLevel API to make this API more focused? - -////TODO: release native allocations when exiting - namespace UnityEngine.InputSystem { /// diff --git a/Packages/com.unity.inputsystem/InputSystem/Plugins/Steam/SteamIGAConverter.cs b/Packages/com.unity.inputsystem/InputSystem/Plugins/Steam/SteamIGAConverter.cs index cb6dde9dd5..6a22280e45 100644 --- a/Packages/com.unity.inputsystem/InputSystem/Plugins/Steam/SteamIGAConverter.cs +++ b/Packages/com.unity.inputsystem/InputSystem/Plugins/Steam/SteamIGAConverter.cs @@ -9,23 +9,6 @@ using UnityEngine.InputSystem.Editor; using UnityEngine.InputSystem.Utilities; -////TODO: motion data support - -////TODO: haptics support - -////TODO: ensure that no two actions have the same name even between maps - -////TODO: also need to build a layout based on SteamController that has controls representing the current set of actions -//// (might need this in the runtime) - -////TODO: localization support (allow loading existing VDF file and preserving localization strings) - -////TODO: allow having actions that are ignored by Steam VDF export - -////TODO: support for getting displayNames/glyphs from Steam - -////TODO: polling in background - namespace UnityEngine.InputSystem.Steam.Editor { /// diff --git a/Packages/com.unity.inputsystem/InputSystem/State/InputStateBlock.cs b/Packages/com.unity.inputsystem/InputSystem/State/InputStateBlock.cs index 94a9883215..7dd0800305 100644 --- a/Packages/com.unity.inputsystem/InputSystem/State/InputStateBlock.cs +++ b/Packages/com.unity.inputsystem/InputSystem/State/InputStateBlock.cs @@ -3,22 +3,6 @@ using Unity.Collections.LowLevel.Unsafe; using UnityEngine.InputSystem.Utilities; -////TODO: the Debug.Asserts here should be also be made as checks ahead of time (on the layout) - -////TODO: the read/write methods need a proper pass for consistency - -////FIXME: some architectures have strict memory alignment requirements; we should honor them when -//// we read/write primitive values or support stitching values together from bytes manually -//// where needed - -////TODO: allow bitOffset to be non-zero for byte-aligned control as long as result is byte-aligned - -////REVIEW: The combination of byte and bit offset instead of just a single bit offset has turned out -//// to be plenty awkward to use in practice; should be replace it? - -////REVIEW: AutomaticOffset is a very awkward mechanism; it's primary use really is for "parking" unused -//// controls for which a more elegant and robust mechanism can surely be devised - namespace UnityEngine.InputSystem.LowLevel { /// diff --git a/Packages/com.unity.inputsystem/InputSystem/State/InputStateHistory.cs b/Packages/com.unity.inputsystem/InputSystem/State/InputStateHistory.cs index 1cd3f4a620..b70dc2ae6c 100644 --- a/Packages/com.unity.inputsystem/InputSystem/State/InputStateHistory.cs +++ b/Packages/com.unity.inputsystem/InputSystem/State/InputStateHistory.cs @@ -9,14 +9,6 @@ using UnityEngine.InputSystem.LowLevel; using UnityEngine.InputSystem.Utilities; -////REVIEW: should this enumerate *backwards* in time rather than *forwards*? - -////TODO: allow correlating history to frames/updates - -////TODO: add ability to grow such that you can set it to e.g. record up to 4 seconds of history and it will automatically keep the buffer size bounded - -////REVIEW: should we align the extra memory on a 4 byte boundary? - namespace UnityEngine.InputSystem.LowLevel { ///