Has anyone at Unity managed to find a touch-screen PC yet to do some testing? Perhaps Microsoft will lend them one as they are all about touchscreen PCs with Windows 8.
Come on Unity team! You can do it!
They keep telling me they are fixing these bugs while at the same time closing all the bug reports without fixing them. I’m not holding out much hope.
Any news about getting the mobile touch team and the PC team to communicate with each other yet? Or is one team in Brighton and the other in Denmark?
Main issue is a lot of focus has been put onto 5.0 for the guys looking at the windows phone 8 stuff. I’m thinking the “fix” status on the bugs are going towards 5.0 instead of 4.6 (just a guess).
Everyone seems to be on christmas holidays so no luck getting any answers yet.
Anyway, I’ve given up hope of any bug fixes so I’m now on to damage control. What I am thinking of doing is this:
For Windows 8 Store Apps: Remove all GUI containing input text boxes or sliders as they are broken. Replicate the functionality in the Metro XAML.
Webplayer: Remove all “Pointer Down” events from GUI and handle all mousedown and touches from within the Update() function sending “PointerDown” events to the buttons. (Not sure if this will work.)
Unsurprisingly the GUI works fine for Windows stand alone apps. Seeing as most of the testing would have been done on Windows PCs at Unity. Pity none of the tester(s) at Unity own a touchscreen PC with Windows 8.
If anyone has any workarounds for the bugs let me know below.
In conclusion I would say that the GUI in 4.6 is fine for prototyping games but because of all the bugs it shouldn’t be used in a serious product.
Sorry windows 8 stuff isn’t my strong point i honestly thought they were the same. Now i know :). either way i think its almost the same guys fixing both the issues and they are on 5.0 atm.
Part of the issue atm is everyone had started taking holiday in Dec, so some bugs never made it through to the dev team to fix. this hopefully will be better again in Jan
Well one reason that it doesn’t work as expected is as follows:
On a touchscreen PC in the webplayer and standalone apps:
OnMouseButtonDown(0) <— is false unless you drag your finger about 1cm. OnMouseButtonUp(0) <— is always called when you lift your finger
I tried this on Unity 3.5 and the same thing occurs. Perhaps it is a bug in the Webplayer itself? This seems like a fundamental bug. If you could just get OnMouseButtonDown(0) to be called when a touch occurs on the webplayer, that would mean the webplayer would work perfectly with touch. I have no idea why it does this as all other software such as the browser buttons work fine with touch on a touchscreen PC.
I wonder if it is the same bug that is making the Windows 8 Store apps not work properly?
Is there some way I can fix this myself?
PS. This may be why the buttons work in Windows 8 because they respond to PointerUp events, but the sliders or input text doesn’t.
Umm not likely. If you do a Input.GetButtonDown(0) does it return properly in the webplayer? If it returns properly then its likely fixable by you in the C# UI code. If it doesnt return properly then its a bug internally in the engine. My guess is its a internal bug that we need to fix.
I’d hope its the same bug that is making the windows 8 store apps not work properly but then again i have no idea :).
It would seem likely as in Windows 8 the buttons respond to ButtonUp events and they work just fine.
Yes, the same thing happens with GetButtonDown(“Fire1”). In that it doesn’t return true unless you drag your finger a little bit.
It is strange that I’ve not noticed this before! It is the same on webplayer and stand alone PC apps made with Unity. In all other software such as Windows Paint, it responds to a touch the same way as a mouse down.
I will check my touch setup, but don’t think this would be an issue seeing as all other software running on Windows 8 just responds to touch as if it was a mouse.
REVELATION!
In fact the ONLY software that doesn’t work this way is the Unity IDE itself! So fixing this bug will ALSO make the Unity IDE work with touch! You can try this by trying to drag a partition in the Unity IDE with your finger. This only works if first you drag your finger down along the partition!.
There you go. If you fix this bug, not only will touch work on webplayer and standalone but ALSO the Unity IDE will also work with touch! Two for the price of one.
I have submitted a bug report which will no doubt be dismissed and then closed.
Thanks!
I put the bug here: 659944
And then I made a bug specifically about the editor here: 659951 (Well not specifically a bug as Unity never claimed the IDE would work on touchscreen PC’s)
I don’t even know how such a bug can even happen as Windows 8 OS translates all touches to mouse events!
I noticed that someone found the same issue here further down the page they note that you have to swipe. I quote:
Good to know it’s not just me!
Just to reiterate I don’t think it is a touch driver problem as all other standalone software on Windows 8 touchscreen works as expected. Just apps made with Unity and the Unity IDE are the only ones that have this odd behaviour.
So I downloaded patch 3 and surprise surprise NONE of these Windows 8 Metro Store apps have been fixed.
To be honest I don’t really care if they get fixed but I would like to know if they EVER will be fixed for Unity 4.6? Or are they getting fixed for Unity 5?
Look here is the proof that they still aren’t fixed:
Tested on my HP Windows 8.1 touchscreen laptop compiling for Windows Store. (STORE not phone just to clarify). This occurs when you press backspace on a text input. Also there are all the other bugs still there https://sites.google.com/site/bugsexposed/unity-windows-8-store-bugs
I keep submitting the bugs and they keep getting closed without being fixed. I think you should have an investigation into who is closing these bugs without fixing them!
All I get is a reply from Unity that, we can’t do anything about it because the mouse team and touchscreen team are different departments and they don’t talk to each other. Which is ridiculous. Every second laptop sold today is a touchscreen PC with Windows 8. And the Unity UI does NOT work on these laptops. Such a shame. After all these competitions you had on the Unity website trying to promote Windows 8 store apps and then the new UI doesn’t even work for Windows 8 store apps. What is that all about?
Here’s my advice to Unity: Go to the shops and buy a Windows 8 touchscreen laptop and go test the new UI on it. You should be able to pick one up for about £500. Or get a second hand one off e-bay for about £200. Thanks.
Update - Some useful Tips
I have found that a few of these bugs can be fixed by deactivating the TouchInputModule in the Event Handler component.
Doing this means that now in a Windows Store App for a touchscreen PC: (for both mouse and touch)
The sliders now work
The buttons no longer flicker when you drag over them
But these things are still broken (mainly the text boxes)
The caret is always positioned at the front of the text, can’t select text
When you try and delete text it stops working
So obviously a lot of these bugs are down to the touch events conflicting or something.
But now I’m worried that my app won’t work on a Windows tablet which is purely touch-screen.
Scenario 2
If on the other hand you deactivate the StandaloneInputModule and leave the touch module. It no longer works with mouse but works for touch exept:
Nothing happens at all when you tap on Text Input.
Hope this helps people to see that the two teams making the TouchInputModule and StandaloneInputModule still haven’t been able to sit down and talk to each other. I’d be interested to know if these two teams both work in Brighton. Or does one work in Brighton and the other in Denmark? Or one in Denmark and the other in China? Why can’t they get round the table and fix this thing?
All they have to do is this:
if(Input.touchCount>0){
//do touch input stuff or mouse stuff being treated as touch by the OS
}else{ //no touch input, and no mouse being treated as touch by the OS
//do mouse stuff
}
It’s not rocket science.
Perhaps if I just activate the StandaloneInputModule and select Allow Activation on Mobile Device this should work on both Windows touchscreen and Windows tablet? (Except for the text boxes obviously)
Also, after you have fixed these bugs I want you to do some YouTube tutorials showing the UI working on Windows 8 touchscreen PC to prove it.
Here again is the “excuse” from Unity on why they can’t fix these simple bugs:
Well they’re not trying very hard that’s all I can say. This is soooooo simple to fix. That’s what I don’t understand about it. If they don’t know how to do it, why don’t they just ask one of the many developers who have successfully made apps for touchscreen PCs for years?
While I agree that a fix directly from Unity would be preferable and that this should have priority as it seems to be pretty badly broken, and without defending them - if it’s a simple bug that’s so easy to fix, shouldn’t it be possible to fix this yourself since the UI system is open source?
Well, when I say “simple”, I mean for someone who has written the code in the first place it should be simple! If they just took a day to do it! I’ve looked a bit at the code and it is obtuse to say the least. Also, if I start changing the source code and then update to the next version I’ll get in all kinds of compatibility difficulties.
What I’ve decided to do for now is to strip out all text inputs from my code and replicate the functionality in a XAML layer over the top. (That is actually a positive thing as the XAML input box has far nicer functionality). Turned off TouchInputModule and turned on “Allow activation on mobile” for the standalone input. Hopefully that would sort out most problems for Metro apps. Although I haven’t tested it on a Windows tablet (I’m hoping a Windows tablet interprets touch commands as mouse commands). Having these different permutations of Input Modules is confusing and unnecessary. What they SHOULD have done is listen for mouse and touch inputs, and if they get both JUST use the touch input as it means the OS has translated the mouse input into a touch input. At the moment it is using both, which means it is actually interpreting the same touch input twice! They should also have not split the input group into two separate teams. Big error.
/