I did a search and found no information about the new android tablet software. Anyone know if and when Honecomb will be supported by unity?
Not ETA mentioned yet.
Its also not released yet, I think it was mentioned for march / april, so having something ready for it is impossible.
Not even Android 2.3 has really landed yet (only Googles Nexus One has it at all)
Honeycomb will be supported (when Honeycomb is released).
honeycomb: Failure to Initialize! Your hardware does not support this application, sorry!
hi
i tried to load an app on a xoom tablet and it tell me it is not supported.
any help or info?
thanks
bump…
Honeycomb and Motorola Xoom should work fine with Unity 3.3; there are multiple developers already targeting the Xoom. There has been one reported issue when using GLES 1.1 mode on Tegra2 based devices, but otherwise no reported bugs.
I’m not really sure what is causing the problems you are seeing, but I encourage you to report a bug on it. Be sure to include as much info as possible (logcat output, repro project, built .apk file).
so far the Android basic dev build for a simple demo works with
Acer Iconia A500 / Android 3.0.1
still i saw no improvement choosing mobile shader for transparency and
solid diffuse shader behind transparent ones are not quite well refreshed.
with the remote:
-no visible feedback but a black white flicker screen
-the pad touches [10] are well detected
-the touch pad resolution grid seems limited to a 500x500 …
malcolm_H, can you please eloborate on the object position and the shaders you’re using in the scene?
I tried to recreate the project after your description and to run it on Xoom, but I did not notice any issues.
Or even better please report a but on it and we’ll fix it (if this is a bug indeed).
malcolm_H, now let’s do it like this.
I’ll spend 20-30 minutes to try to understand the picture and experiment with shaders and stuff to get the bug reproducible.
And at the time you spend 5 minutes to attach your stair shaped lag to the bugreporter and report it.
So after I come back to the forum topic in 40 minutes trying to say “sorry malcolm_H, I wasn’t able to repro it”, you will say “sorry Oleg, here’s the bugreport, and it’s reproducible”.
Deal?
Any idea about the possible cause of the problems with Unity Remote on Iconia A500 or how to fix them? I just bought one to start Unity development for Android devices. My symptoms are distorted image with random tiles of original image on grey background and input switching on and off several times a second.
anttonij, can you please report a bug on it with the attached screenshot? We’d work with you from there.
thanks
I also have a Acer Iconia A500 Using the Android Remote application. I get Distorted Images and sometimes only the upper half of the screen is visible and the rotation system is off. To replicate this All you have to do is Start a New Project with all the assest in it available even pro and mobile then change to android plateform and play through the mobil control setup scenes. FYI I’m only on the Demo android pro but i own the license for Unity Pro standard. Not sure if being in android trial effects it. It dosen’t do it every time so just keep playing and stopping and after awhile it will start glitching on the device and sometimes become non responsive to your input.
Unity apps work on Honeycomb - there is just no support yet for accessing the device menu since honeycomb tablets only have an onscreen menu
Interesting thread as I started porting my game to a Viewsonic gTablet on Monday. After a frustrating first day which reminded me of trying to get Linux up and running about 10 years ago, I got Gingerbread installed on the tablet finally, although this is definitely not something I would expect the average person to do.
My game worked right away, which was encouraging, but I did notice some artifacts with alpha shaders. Initially, I thought this was a rendering queue problem, but I am not sure now. First of all, the artifacts are depth dependent. When the camera is further away from an object that has an alpha or transparent shader, the transparent object “bleeds through” the opaque objects in front of it. More accurately, it seems that alternating strips of underlying transparent object are rendered after the opaque objects that are closer to the camera. Since the transparent objects are rendered after the opaque, I can see this happening.
As the camera gets closer to the opaque objects, the artifacts disappear. I tried numerous alpha/transparent shaders that are available and even tweaked a few myself to no avail. At this point, I need help with the shaders, which is not my strongest point. Any guidance would be helpful.
–Steve
Potentially the depth buffer just is limited to 16bit and you need to drastically limit the camera near to camera far clip distance ratio.
on desktop you can go with far / near of up to 30k, on this tablet, if its really only 16bit, you have to go with a ratio of 1000-5000 and less, so if near is 0.1, far should not exceed 500. Try to see if that helps
It sounds like some kind of z-fighting; the depth buffer usually has higher accuracy closer to the camera, which then could explain why the problem disappears when moving closer…
Edit: ah, dreamora was faster 
Thank you both for your replies. That was exactly the problem. I had changed the near to far plane ratio from 1000:1 to 600:1, but it needed to be about 150:1 to get the rendering to work properly. One other thing to note is that the iPhone shaders appear to work properly on Android as well. I did not do a thorough investigation, but the shaders were not the problem I was having.
–Steve
Urgs 150?
Thats a new record, not even the original iTouch 1st Gen and iPhone 2G were that extreme (on the other hand, PowerVR hardware which is used on all iOS is the by far most advanced hardware when it comes to efficient using of render pipeline and pixel discarding, so that might have had a beneficial impact for them)
But glad that helped, hope you can work with this limitations just fine.
Shaders, given they are just shaderlab instructions not cgprogram / glslprogram normally should go through fine yeah, thats the good thing on standards that are (more or less ;)) followed on both sides 