After compiling my project as a 8.1 / XAML C# Solution in Unity 4.3, all touch input is offset toward the top left by approximately 400 pixels when running on Surface Pro 8.1. Input.mousePosition is unaffected.
In my test app, you simply tap the rotating cube to turn it red. In this screenshot, the input event is being triggered even though the real touch position (the circle) is way off the cube’s collier, the mouse is positioned directly under the touch position to illustrate the discrepancy. Here is what the touch input looks like in the bottom right hand corner, note that the Y value is negative. Again the mouse has been positioned under the touch pos in the bottom right to demonstrate it is returning correct values. The number in brackets next to the touch input is touches[0].rawPosition.
In D3D mode, I tap the same areas I tapped in the previous images: the values line up as expected - and in the bottom right (The selection circle does not show up in these screenshots because XAML is not being drawn).
Both app versions preform as expected on Windows Surface RT (With the exception of some input lag), the bug only seems to effect touch input on Windows Surface Pro apps compiled in XAML mode.
Test project is attracted, simply build as an 8.1 XAML app and deploy to Surface Pro 8.1.
To fix the lag you are mentioning… you need to add these command arguments to your App.cs by calling a ppCallbacks.AddCmdLineArg() …
Surprising only Surface lags for you… both my PC and Tablet showed terrible input lag but fixed with the following…
Windows Store Apps/Windows 8.1: Added command line argument ‘-disable-independent-input-source’, this way you can disable this Windows 8.1 feature, and see if there are any performance differences.
Windows Store Apps/Windows 8.1: Added command line argument ‘-disable-low-latency-presentation-api’, this way you can disable this Windows 8.1 feature, and see if there are any performance differences.
I downloaded your project, and I get the same thing on my Surface Pro as what you described. It’s not offset when clicking with the mouse on my laptop.
Could it have to do with actual vs scaled “pixels”?
Hi all, I’ve got a surface RT, since two days i’m looking to add touch input to my project, i tried Input.GetTouch, TouchPhases but nothing work, if some one could help me ^^
Are you building to Windows store, or just standard Windows player? The Windows store build will work, but I dont think windows desktop player has good support for touch screens. Also, it likely wont work for you in the editor, only in builds.
so this really isn’t totally solving the problem. while it can fix the touch, the MOUSE on the surface pro w/ win 8.1 is offset incorrectly all the time, with ANY combination of those 2 args. (the type keyboard cover, or an attached USB mouse). this is a pretty bad bug methinks… anything else we can do to solve this before a new fix comes down? to be clear this WASN’T a problem pre 4.3
I’d like to add another issue here that has been resolved by adding the above command line arguments for the Unity team to observe and potentially fix in future releases;
[WinRT Build] Whilst making the game split-screen, the game loses touch input (occasionally receiving OnTouchDown and not OnTouchUp events) and on making the game full-screen again, touches would all come through at once. The above command line arguments have fixed this issue.
Has anyone notices a problem where building Windows Store apps on Unity 4.3.1 has an incorrect Input.mousePosition until the app loses and regains focus? Neither the two arguments on this forum solve the issue.
It’s like Input.MousePosition is scaled by almost half… I don’t understand it. This didn’t occur in Unity 4.3.0.
Anyone else notice this issue?
Edit:
Oh I just realised this is what scritchy is talking about a couple post before this one.
Is there anyway to force the app to lose and regain focus? It seems losing and regaining focus corrects the offset mouse issue. I need a workaround as it’s very urgent that I release a build this week before the holidays…
I don’t think you can do this with entire app, but you may experiment with the following:
bool AppCallbacks::UnityPause(int pause);
void AppCallbacks::UnitySetInput(bool enabled);
Pausing/continuing or disabling and re-enabling input can help. You can also try to put some XAML constrol on page you can set focus to and back to game.
I’m having a slightly similar problem with my Windows Store app. Deploying to a Samsung SmartPC (essentially a Surface Pro).
The touch (and mouse) inputs work just as expected normally, but when I change the application resolution to anything (other than 1371x771), an offset is introduced. This only happens when using Screen.SetResolution(). It also occurs regardless of the build type (D3D11/XAML). The offset isn’t noticeable when I touch the top left corner of the screen, but it increases linearily when I move the touch position towards the bottom left corner (increasing to about ~50 pixels when playing the app at 1280x720, the offset becomes larger if I force 1920x1080). Input.mousePosition and Touch.position both report the same offset.
I’m using the newest version the editor (4.3.4) where the independent input sources and low latency presentation are disabled by default. I’ve also tried enabling them. Any ideas? Anybody even tried using SetResolution()?
