I released Android game and some players report a rendering issue.
Some polygons of my 3d objects are missing and black squares are visible.
Note, squares are not visible instead of missing parts of models.
It could be reproduced only few devices. The only general thing I find - all the users with the problem have Xiaomi.
I have no clue what could cause the problem.
Please, see screenshots:
https://i.imgur.com/1R6arYK.jpg
https://i.imgur.com/YKN7KiX.jpg
https://i.imgur.com/6ZpDdrQ.png
https://i.imgur.com/ktpTjzH.png
I finally fix the issue.
The problem was caused by the driver issue on some Android devices (with Adreno GPU) if GPU instancing is enabled for material.
Related
I have found two issues with SKMaps 3.0.0 with two of my Android devices, although they seem to not be issues on other devices (such as my tablet).
Devices include:
Samsung S6 Edge+ Android:6.0.1
Nexus 6 Android:5.1.1
EDIT:STILL BROKEN WITH 3.0.1 SKPolyline.setOutlineSize() seems to have a maximum size around 10. Setting it any higher does not affect the line size. I reported this to the skobbler team already and nothing has been done about it.
EDIT:FIXED WITH 3.0.1 SKMapSurfaceView.animateToLocation() seems to animate the location to the location to the bottom of the map, so that the center of the map is exactly half way above the spot I would have liked to animate to. Sometimes it works correctly, but this is rare.
If anyone has encountered these issues and has solutions please let me know...
The issued has been fixed with in our 3.0.2 release, now the line width and the outline width of the polyline can be set to any value between 0 and 100.
You can find the links for the 3.0.2 release candidate builds in our forum:
http://forum.skobbler.com/showthread.php/14515-3-0-2-release-candidate-builds
Regarding the first problem reported, it seems there's a bug in the SDK. Our dev team is handling the issue. The feature will be available in a future version of our SDK.
I have an android app, with a view where I show a map. This map is built using this library.
I have just found a fix to the map being laggy (inside a RelativeLayout around the map):
- android:background="#drawable/background_flare"
Yes, that is a one-line commit to solve a performance issue. The background_flare image is 102KB.
Now my question is why this solved the problem. Is there a known problem with backgrounds on RelativeLayouts, or is there a bug with the library so that it takes the image around when you pan the map?
Also worth noting, this bug only shows on a Samsung Galaxy S4 mini (GT-I9195I), running Android 4.4.4.
Any ideas?
Just wanted to share an experience I had to see if anyone came across such issue, if they found the cause and more importantly how they fixed it.
The problem is pretty simple: while debugging native code on a Nexus 6, which as the Adreno 420 GPU, eglSwapBuffer could crash under certain circumstances when using Android 5.1 (5.0 worked perfectly).
Since I could not repro it I am unable to tell you what went wrong. According to the documentation, elgSwapBuffer calls internally glFlush; and so if I call glFlush before calling eglSwapBuffer all of a sudden it works perfectly.
My guess is that the driver does not flush properly thus crashing when swaping the buffers.
Any comments on this?
Cheers,
D
I'm having the same problem and I can reproduce it. It happens obviously because it runs out of stack memory due to deep nested loops in the rendering process.
Android Lollipop 5.1: Fatal signal 11 (SIGSEGV), code 2, fault addr 0x9e985ff8 in tid 4093 (RenderThread) / when using lot of nine patch graphics
I've already reported it to the google issue tracker:
https://code.google.com/p/android/issues/detail?id=163100
Update: Meanwhile I found a way to work around this issue. It's definitely not a long time solution, but for the moment, it's just the best available to stop my apps from crashing.
I disabled GPU rendering for particular graphic layers. It slows the drawing down a bit, but not significant.
So the nightmare is over for now, but I still think, this issue must be fixed on the driver itself. It cannot be that something that worked perfect with 5.0.2 and below, immediately stops to work with 5.1.
I have seen some weird behavior on the N6 as well, and while I cannot rule out app bugs, it looks to me like the Adreno driver is to blame.
Specifically, in landscape mode, our GLSurfaceView only renders one half of it's content, but occasionally flickers all of it. And with certain scenes being rendered there is intermittent flickering. In a case of extra weirdness, I have seen one half of the screen completely freeze, stuck on app content, even after returning to the launcher via the home button. It appears kind of like it would if it used multi stream transport and one of the streams was getting lost.
Im testing my new game prior to release and i have found that on some devices the Z positions seemed to be mixed up in some cases and objects that should appear on top were appearing underneath.
I'm running opengl es 1 and it runs perfectly on my Samsung Galaxy S2 (and all the samsung devices i tested on) but went wrong on a HTC Desire.
Does anyone have any ideas?
Can you provide us with some pictures and source code? Common depth buffer problems cause some banding problems but your problem seems more related to some default driver state that is set differently value depending on which hardware are you running on.
I suggest you to generate a very simple example and start from the scratch until you find where is the problem, I don't think we can help you with so little information.
Hope that helps.
Has anyone experienced a change in depth sort behaviour after upgrading a galaxy s to android 2.3.3 ?
I am finding that the depth sort fails to work once a certain polycount threshold has been reached.
Scenes that worked fine on 2.2 now are failing to sort.
Anyone have any info on this? Nothing comes up when I google.
Could be, I'm having an issue with the depth buffer on S2 (running Gingerbread) whereas I don't have any issues on 2.2.
EDIT: Solved the problem, it turns out that for some reason 2.2+ do not like -ve depth buffer near values. Try keeping it all positive and it should resolve itself.