Is that latest 1.7.0 or 1.8.0-pre.2 has been battle tested to support serious production mobile game like moba or even fast pace mobile game nicely? From what I know, there's asset store developer tells me that New Input System is still buggy and he still stay at old input system for his asset store package. Is that still the case?
#New Input System for mobile input issue
1 messages · Page 1 of 1 (latest)
Hi @sharp copper and thanks for reaching out. We have quality procedures in place to quality assure every release we ship. However, sometimes bugs slip through and we are always actively working on adressing them as they are discovered and reported. The currently known issues for Input System 1.7.0 may be found here https://issuetracker.unity3d.com/product/unity/issues?project=116&status=&unity_version=1.7.0-verified&view=hottest or remove the version filter and review known issues across versions. Is there any specific issue you are referring to that makes you raise this concern?
Unity is the ultimate game development platform. Use Unity to build high-quality 3D and 2D games, deploy them across mobile, desktop, VR/AR, consoles or the Web, and connect with loyal and enthusiastic players and customers.
Regarding 1.7.0 vs 1.8.0-pre.2 for production I would definately say 1.7.0 since it's a formal release. 1.8.0-pre.2 is our second prerelease of a coming 1.8.0 release and isn't mature enough for production yet. However we publish pre-releases for allowing early adopters to test them and provide feedback (and improve quality) before we do the formal release.
I will ask the asset store developer. For now my current concern is from what I know the performance of mobile input is slow at old input system for serious mobile music game that can't tolerance input lag. Is that has been addressed at latest new Input System 1.7.0 or 1.8.0-pre.2?
Sorry to hear that there are concerns about performance. It would be great to understand what kind of input we are talking about? Is it touch, keyboard, gamepad or general? It would also be great to understand more specifics about the performance problem you are referring to?
Thanks for sharing some details about the intended use-case, that is helpful. So it is a music game which would imply any lag would need to be taken into account. I would guess you would benefit from having a known/fixed lag?
It would be great if you could share some of the other constraints to allow be to provide advice? Is it beat-oriented and hence there is a correlation error between input lag and music output lag and BPM synchronisation that you need to take into account? What deviation is acceptable in your perspective for this use-case?
At the moment Input System in default update mode will provide input lag directly correlated to the achievable frame-rate, i.e. for 60 FPS the processing delay would be less than 16.66 ms. For 30 FPS it would be half. Is this a problem for your use-case?
This article clearly explain the performance problem. Actually it's not just input lag but also audio lag. https://exceed7.com/native-touch-archived/
Thanks for sharing. I understand the concerns mentioned in that article and https://docs.unity3d.com/Packages/com.unity.inputsystem@1.7/api/UnityEngine.InputSystem.EnhancedTouch.EnhancedTouchSupport.html?q=enhanced in Input System provides some improvements compared to Input (legacy) touch and delivers events derived from native touch events. There is also timestamps that are not in native format but translated to Time.realTimeSinceStartup timeline.
However, there is currently no async callback based processing since as the article suggest, we are also doing intermediate buffering to report the events on main thread in sync with Update.
It would be great to understand what the main features or capabilities you are missing or looking for could be summarized? Based on that article it seems to be desire to:
- Reduce input lag on touch?
- Do not coalesce or discard high frequency events?
- Desire to have input callbacks outside of regular Update loop?
🤔 For me I just want it to be performance by default using the regular input api not just for mobile touch input but also other input for all the supported platforms. I dun want to achieve the goal by using a lot of insanely low level api or hacky way
That makes sense @sharp copper. I'll take this to our internal team for discussion as a use case to consider and to assess the mobile performance vs performance in general. (e.g. music game that can't tolerate input lag).