In contrast to “Old” input system, TouchPhase stays on “Begin” for the New Input System and it’s lowlevel Touchscreen API until a touch has moved.
Additionally, “startTime” seems to never be 0; which makes it impossible to figure out of a touch has actually started in a given frame.
EnhancedTouch seems to have that information — how can I, without using EnhancedTouch, see that a touch has just started (so that I get “true” in a single frame)?
(Seems the only way is to keep track of the arbitrarily chosen 10 touch IDs myself and reset a flag when they are ended or canceled. That can’t be right.)
The Touchscreen device indeed makes for a poor polling API. The intention is for “EnhancedTouch” (which really should have just been named “TouchPolling”) to fulfill that role. The problem is that a polling API needs to store quite a bit of additional state in order to not lose data. By splitting the two APIs, actions can use the device-level touch information directly and EnhancedTouch can focus entirely on polling.
There is a bug/problem in 1.0 where if a frame has both a Began and one or more Moved events for a touch, the touch record in EnhancedTouch will be Moved instead of Began. A fix is on the way. There’s a couple issues with EnhancedTouch that have pending fixes. All of them will go out in 1.1.
Thank you. I’d recommend you make the documentation more clear; currently it (very explicitly) states that using EnhancedTouch is optional, the above is clearer (Touchscreen for events / actions; EnhancedTouch if you want the previous behaviour of polling for states).
The main issue with EnhancedTouch as far as I can see is that it’s up to code to enable/disable it, which means nobody can use it from e.g. AssetStore packages, really. You never know if a user project wants to have it enabled or disabled, or explicitly disables it, … which means EnhancedTouch is basically a no-go for any kind of plugin.
I guess it’s not “just always on” for performance reasons?
Will 1.1 come with better touch support on devices? Currently seems there’s quite some things still missing (e.g. tapCount is broken, there’s a ton of //TODO comments scattered around all things touch in the code, …)
The fact it needs to be enabled explicitly has indeed repeatedly come up as a problem. My thought ATM is to just turn it into something that implicitly enables itself. I.e. if you call any of the EnhancedTouch APIs, it will implicitly enable itself if it hasn’t already.
Yup. I have some optimizations in the pipe that greatly bring down the overhead but the overhead is still there. And with touch already being costly, the most sensible thing seemed to be to not let it run except the user really wants touch polling. Also with a view towards the goal being to ultimately get action-level touch input to a point where no one would want to poll touch anymore
Improved, yes. It will have a number of fixes and optimizations. The big step forward, however, will only come with gesture support and being able to consume touch input without any hoopla at the action level.
I think implicitly enabling it (and not allowing to be disabled again from user code) is a good way forward, otherwise third-party providers will have to “roll their own state logic” (like I currently have to for that Begin/Moved issue).
A fully action-based workflow sounds good!
By the way, you get from me on behalf of all package users, the InputSystem changelogs are a piece of art :). By far the best in the Unity package ecosystem! Keep up the great work and documentation
