So, I'm writing a game engine.
I have a little example (see http://qrcode.kaywa.com/img.php?s=8&d=http://rokonandroid.com/rd.apk), that seems to work fine on every device except Droid / Milestone.
It displays a blue screen (due to glClearColor being set to blue), and nothing more.
I have tried with/without textures, and with/without VBOs. Yet still all blue screens on Droid.
What is unique about Droid and how it handles OpenGL, and why is it doing this?
Are you using OpenGL ES 2.x perchance? The droid can't support it. Alas there is precious little we can do but guess without seeing some source code!
Related
I'm working with the opengl es 3.0 api for android. I'm writing functionality for a bitmap text renderer, and, well, it works flawlessly on two of my devices, both samsung. but on my kindle fire 10 HD (7th generation) tablet, it's all messed up. it's sampling from wrong portions of the texture atlas, displaying wrong glyphs, and it won't display the entire message sometimes, and sometimes when i go to switch messages, via mapped buffers, it briefly displays the entire message at once before starting the animation of it. Anyhow, I seem to think it's related to degenerate triangle strips that I'm using, so I ask, is support for them not ubiquitous across all android devices supporting opengl es 3.0? I've had trouble before with the kindle fire, in shader-related stuff. It won't work at all if I don't specify a precision, both for floats, and for sampler2DArray, that I've discovered thus far.
A degenerate triangle "should just work"; there is no feature here in the API for the hardware not to support. They are just triangles which happen to have zero area because of two coincident vertices.
They have historically be really common for any content using triangle strips, so to be honest I'd be surprised if they are broken.
It won't work at all if I don't specify a precision, both for floats, and for sampler2DArray, that I've discovered thus far.
That's not a bug; that's what the the specification requires you to do. See "4.7.4. Default Precision Qualifiers" in the OpenGL ES 3.2 shader language specification.
I'm developing a game in Unity 5.2.2f1 and I'm using the canvas and image masking elements then building an .apk for Android. On most Android devices this works fine, but on the Galaxy Note 5 and the Kindle Fire HD, the masking doesn't take.
What's also interesting is that it DOES work on Galaxy Note and Kindle Fire HD when I use the default provided asset that is part of the unity_builtin_extra resource, but not when I use a .gif or a .png for the image asset.
Mask Works on all Android devices:
Mask only works on some Android devices:
I've also tried updating various setting like setting the cameras to forward rendering and enabling 32-bit Display Buffer (as other posts have suggested), but nothing so far has worked.
Any leads or thoughts on this would be greatly appriciated!
In the past, I encounter similar problem with the UI Mask on Linux, there is a bug reported on it.
Since they haven't fixed it, I would not be surprise if some other devices have the same problem.
If the Mask purpose is for UI, then you could use the 2D Rect Mask instead which is way more efficient, but only made for UI and has some limitation.
As you can read in the doc :
The limitations of RectMask2D control are:
It only works in 2D space
It will not properly mask elements that are not coplanar
The advantages of RectMask2D are:
It does not use the stencil buffer
No extra draw calls
No material changes
Fast performance
Either way, I'd report your issue with a small test-bed project so they can test it out and eventually write a fix for it.
In the meantime, hopefully the 2DRectMask can be a workaround!
I am currently working on an android game in Unity. In the editor everything looks great, actor moves smoothly, generated dungeon looks nice. After building the game and start it on my smartphone the whole dungeon looks different and when moving my actor I can notice strange vibration that has never appeared before. While vibration my be caused by "wrong" implementation(I am working on very powerful Desktop so the code may be not optimal), the strange arrangement of dungeon is not about implementation at all. I tried building same version on web player and it looks jut as in editor. Look at the differences between Android-Standalone builds.
Android: http://imageshack.com/a/img901/5057/7REtUn.png
Standalone: http://imageshack.com/a/img661/2618/2Em05d.png
As you can see standalone build is just as expected, nice corridors and chambers, while on android... chaos?
EDIT: While using Unity Remote everything looks fine. Well movement isn't okay but as I said am sure now it is caused by implementation. But generated dungeon keeps unsolved.
Have you tried adjusting your targeted frame rate? Maybe your targeted frame rate is set improperly for your specific device. You may also want to try lowering the native resolution . If your resolution is really high it will cause choppiness and lag. Another item I also had to tweak to get my game to run well is the Lighting Options. From forward lighting you can change to vertex lit and it substantially speeds things up.
You may also want to mess with your shaders a bit, and see what mobile options you can go for. Various shaders have different outcomes, also rendering paths effect how things look. Are you using OpenGLS 2.0, 3.0, specifically look the settings from standalone to mobile in Player Settings.
Also make sure you're using the new Unity Remote as opposed to the old version. The old version works through wifi which is slow, the new one uses tethered USB and is relatively well.
To adjust the screen resolution as I mentioned above I had to:
75% resolution (landscape):
Screen.SetResolution (Screen.width * 0.75f, Screen.height * 0.75f, true);
To adjust target framerate as mentioned above:
Application.targetFrameRate = 60; //sets framerate to 60.
We are a team of developers working on a terrain visualization software over a virtual 3D globe. The project is aimed at mobile devices running android, mainly tablets and mobile phones. We have tested this in several devices and, while mobile phones seem to run the application fine (we haven't detected any issues on any of them), some tablets seem to have problems when drawing the textures in the screen.
For clarity purposes, im attaching a video that displays the problem, since its a little difficult to explain with words. This example shows a sphere divided in 200 sectors, each one with a different texture.
Texture problem video
As you can see, sometimes it looks like it is trying to draw two different textures in the same sector at the same time.
We have tested this in these devices:
Samsung Galaxy S SLC (ok)
HTC Desire (ok)
Nook Ebook Reader (ok)
Samsung Galaxy Tab 10.1 (doesnt work propperly)
Sony Tablet S (doesnt work either)
Samsung Galaxy Tab 7.0 (ok)
Im posting the critical code that may be involved in this. First the fragment shader that is used to draw the textures:
varying mediump vec2 TextureCoordOut;
uniform sampler2D Sampler;
....
gl_FragColor = texture2D (Sampler, TextureCoordOut);
Next, im posting the key instructions that are executed in OpenGL, since the code is spared in several big functions:
GLES20.glGenTextures(num, idTextures, 1); //declare 200 textures
...
GLES20.glBindTexture(GLES20.GL_TEXTURE_2D, idTextures[texture]); //texture binding
...
GLES20.glVertexAttribPointer(Attributes.Position, size, GLES20.GL_FLOAT, false, stride, fb);
...
GLES20.glVertexAttribPointer(Attributes.TextureCoord, size, GLES20.GL_FLOAT, false, stride, fb);
...
GLES20.glDrawArrays(GLES20.GL_TRIANGLE_STRIP, first, count);
Im sorry not to be able to provide more details, but after several weeks of debugging, we have no clue at all of what could be causing this. Im turning to you hoping for any leads, since we are completely lost right now. Thanks in advance.
I think I might know what causes you difficulties. The only devices where it doesn't work for you are Tegra 2 devices. I recently started working with a Tegra 2 device and noticed certain differences. Compared to other devices Nvidia seems to have introduced certain kinds of rounding errors where some things can behave differently from other GPUs. I had to go to extreme lengths and use workarounds to get it working the way I want with my complex shaders.
And what I could see on your video looks sort of like the z-buffer might not have enough resolution and that causes some kind of z-fighting: http://en.wikipedia.org/wiki/Z-fighting. I am not sure because I don't really see from your code/description if you are drawing triangles that are very close together and can cause this kind of behaviour in the z-buffer.
But maybe you can try to scale the vertices (x,y,z) somewhat up or down and see what happens to the flickering. If it changes it probably has something to do with that, if not, the problem might have another reason, but then a little more code would be nice.
It would also be interesting to try to narrow it down by not painting the whole sphere but just one or two triangles where the problem occurs and see if it still happens.
PS: A longer video would have been better, short clips suck on vimeo.
My Android app has been out for several months and works fine on any number of WVGA phones like the Droid, Droid 2, Galaxy, etc.
On the Motorola Xoom, however, a small portion of the textures load with white boxes where the images should be.
Researching online the most usual cause for this appears to be not using power of two textures. This seems an unlikely explanation since they work fine on so many other devices. Also, I am using power of two textures. The one caveat there is that I'm loading a bunch of bitmaps into a 1024 by 1024 texture dynamically. The code I'm using is from a now defunct library called Rokon, the relevant texture atlas code is here: http://code.google.com/p/rokon/source/browse/trunk/src/com/stickycoding/rokon/TextureAtlas.java?r=260 -- Like I said, I'm skeptical this could be the cause since it works on so many other devices AND many of the textures I am loading this way do work fine.
But I'm not sure what else could be causing it. A memory issue seems unlikely given that amount of memory available on the Xoom compared to the other devices the app works on.
Right now I don't own a zoom, but I can replicate the issue via DeviceAnywhere (where I see white backgrounds).
Nothing of interest shows up in LogCat either.
I know this isn't much to go on, but I'm at a loss here, what kinds of potential causes should I be looking at here? Thanks in advance for any ideas.
Try using glGetError() to see if OpenGL throws any errors
Is your application 2D or 3D? When you're drawing your sprites on the screen; which method are you using?
If your texture is white during onDrawFrame that probably depends on:
An untextured quad (using VBO:s or standard Vertex Arrays) - probably not, because it works on other devices
Xoom lacks support of the draw_texture extension - if you're using 2D
Xoom lacks support of VBO:s (Vertex Buffer Objects) - probably not, almost every Android device out there supports VBO:s
Do you have any sort of texture compression implemented that Xoom doesn't support?
At runtime, use this code to get the extensions and check if they're available:
String extensions = gl.glGetString(GL10.GL_EXTENSIONS);
boolean supportsDrawTexture = extensions.contains("GL_OES_draw_texture");
// Continue here and sooner or later you should see where Xoom lacks support
// where other devices doesn't.
Is it possible that you're falling foul of Android's automatically-resize-bitmaps behaviour? Print out the bitmap sizes as they are loaded to check, or move them to res/drawable-nodpi to avoid the behaviour entirely.
Is it possible that your texture exceeds 2048 pixels width or height? That's the maximum allowed texture size on XOOM.