At glowscript.org are various demo programs written in JavaScript or CoffeeScript that involve little code.
For example, the one-line program box() creates a 3D cube that can be rotated and zoomed, thanks to many defaults (which can be overridden), including basic lighting (two distant lights and some ambient lighting).
Problem:
These programs run fine in many browsers on Windows, Mac, and Linux, but in Firefox on the Samsung Galaxy S3 they are very dark. The appearance indicates that ambient light works (increasing it makes the scene bright) but the distant lights don't work (no difference with them on or off). I've tried running some WebGL demos found on the web and they look fine.
Can anyone think of where I should look for the problem? Why should the behavior be so different between desktop/laptop behavior and what happens on the Galaxy S3?
I fixed the problem on the Galaxy smartphone and added the following to the GlowScript help:
"Most tablets and smart phones do not yet support WebGL, though this is likely to change. On the Samsung Galaxy S3 smartphone, Firefox and Opera do run GlowScript programs, though animations are slow, transparency is buggy, and currently there is no way to zoom and rotate. There are reports that GlowScript also works on the Sony Experia smartphone."
The problem was that the Galaxy shader compiler does not handle for loops correctly. In the fragment shader there was a for loop over the various lights (up to 8 lights). Variables set in the for loop were often set to zero instead of to the specified value. The solution consisted of replacing the loop with a straight-line structure like this, where LP(i) and LC(i) are light positions and colors:
if (light_count == 0) return;
calc_color(LP(0), LC(0));
if (light_count == 1) return;
calc_color(LP(1), LC(1));
if (light_count == 2) return;
etc.
Yuck. Fortunately we only have to support a finite number of lights.
Related
Launching GVRDemo scene using Unity5.4.2f2-GVR13 installation package I'm experiencing unsteady tracking on my Samsung Galaxy S7. As you can see on an attached video it's not caused by low frame rate nor any of my code since the only thing I've changed in the scene is switching the cubeRoom object with a textured sphere object which better visualises the issue:
https://youtu.be/_NRQNbtdpuI
It doesn't matter if I change the quality setting from Fantastic to Fastest.
As you can see the frame rate doesn't drop around the stuttering moments, so it's not about the CPU/GPU performance
As I test the Google Street View app for example, there's no such issue – is it because it's been written natively for Android?
On the other hand I've noticed games like VR Fantasy with tracking system behaving differently – more smoothly due to the delay in the reaction time regarding the device's movement (looks nice, but causes nausea after 5 seconds). This makes me believe there is an issue with Google VR tracking.
Is anyone experiencing the same thing? What might be the reason for it?
I am also testing a simple VR app made with Unity (5.6b9), and i'm finding that Android performance is rather poor. This is the case on cheap phones (Moto G, $150) as well as fancy phones (Nexus 5X, Asus ZenFone 3) and even expensive phones (Samsung S6).
I'm particularly puzzled by how poor the performance of a VERY simple VR app made with unity is (empty scene, a cube and a sphere, no special lighting, single pass rendering...). The Samsung S6 performes very well with native GearVR apps, or photos/videos. All the phones perform very well with things like street view or youtube.
The same unity app running on iOS outperformer all the androids by a wide margin.
Are there some tricks we're not aware of for getting performance out of android?
I'm using Unity5.4.2f2-GVR13 too, and I think it's just random.
Charging up your phone and controller, and rebooting the phone seems to help a lot.
I've been looking for a way to detect the finger orientation together with a simplification of the touch area in the form of an ellipse, when using a mobile touch device. I choose Android rather than iOS since I found three usefull methods (getTouchMajor(), getTouchMinor(), and getOrientation()) in the Android reference for the MotionEvent class.
But I've tried to implement these three methods in my app, and sadly they does not return the wanted values. The orientation stays at 0, no matter what, while the getTouchMajor and getTouchMinor is exactly the same each time.
So my question is: Am I doing somethign wrong or is these methods just not implemented yet?
(I've tried the functions on several different devices including: Nexus 5, Nexus 7, and HTC One)
As we work together I know you know this answer, but I just wanted to put it up such that fellow users of Stackoverflow can have it as well.
We have found suggestive comments that maybe the touch screen drivers for most devices do not provide this data to the system.
We originally tested: Samsung Galaxy S2, HTC One, Nexus 5 (by LG) and Nexus 7 (by Asus), Samsung Galaxy Tap 3.
As opposed to the others the Samsung Galaxy Tap 3, gave different values for getTouchMajor() and getTouchMinor(), but this relationship was seen getTouchMajor() = getTouchMinor() * 3, and getOrientation() was always 0, as with all the other devices.
About 2 months later we discovered that the Google Nexus 10 can show an ellipse with a direction line, when you activate Input: Pointer Location under developer settings.
The initial conclusion was that most devices do not support, getTouchMajor(), getTouchMinor(). or getOrientation(), Which could be a limitation of the capacitative touch screens.
But seeing the Nexus 10, and the tracking of the ellipse and orientation gives hope for new interaction design.
It indicates to me that some devices do deliver on getTouchMinor and getTouchMajor as well as orientation. (or historical versions of the same functions).
I have not had the chance to code anything for the device myself but it seems plausible.
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.
I have an application which uses Android ViewPager (7 views, pretty complex with images and animations). This application runs fantastically on my Asus Eee Pad. It is just gorgeous.
I also have a Galaxy Tab 2 10.1 which almost can not run the app... despite it's brand new and theoretically more powerfull than my EEE Pad. I would like to mention both terminals run Android 4.0.3 and their screen size is identical (1280x800). Application runs in landscape mode.
The application does not use sql, or internet access, just animations on different views and the swipe effect of the ViewPager.
I checked I think everything, from heap, from lint, from basically all the available tools for profiling but nothing seems to improve my UI performance on the Galaxy Tab 2... I wonder if there isn't some difference in the hardware finally, where the ASUS will use GPU to render the UI and the Galaxy Tab 2 its CPU...
I was wondering finally, if any of you, noticed some similar issues on Galaxy Tab or other tablets when comparing your app behaviors on multiple targets...
Cheers!
Paul
--- added September 6th ---
Well, it seems that, despite the Galaxy tablet should use hardware acceleration, it does not. When I am forcing each xml layout with android:layerType="hardware" and
v.setLayerType(View.LAYER_TYPE_HARDWARE, null);
ObjectAnimator oaAlpha = ObjectAnimator.ofFloat(v, "alpha",0f, 1f);
it works finally better... even if it is not as smooth as on the Asus one
Finally, I discovered - and this is really odd - that the performance issue was created by the fact that the font size was too high !?!
It was a sad experience... but for some stupid reason the Galaxy Tab 2.0 was having major issues rendering texts written with big sized letters. And it is related to the Galaxy Tabs (so I imagine hardware) because I tried with So just redesign your app with smaller fonts and don't forget to complain to Samsung.
First to thank you all for your great help, I have finally published my game puzzle, both full and free version. Not sure how would I do it without Stackoverflow.
I also learned a lot by helping others.
The issue I am having is that when I start applications I have developed, on Samsung Galaxy Tab, animations are jerky at first 10 seconds or so, then they become smooth. This is not the case on HTC desire or Samsung Europe mobile.
It does not matter whether the animation is a frame by frame canvas drawing or built in android view animations.
I wonder if there is something I can do to prevent this slow down; is it something to do the way Galaxy Tab buffers when loading an application and optimising the resources? Or is this to do with the fact that it has a higher resolution screen… or both.
One way to deal with this could be to create some kind of animated intro in the same activity which would preload/optimise Galaxy Tab for the game.
EDIT after few months of development:
When testing an app on Galaxy Tab it starts slow and the animation is jerky, but if I restart the app and/or unplug the USB link, then it run fast as it should.
It's hard to say without seeing any of you're code. I couldn't say if it's a general problem with your code that only becomes apparent on slower devices, or if it is actually an issue with the Tab.
When testing my applications on the Galaxy Tab the general user interface is slower than on a Galaxy S (2.2), Nexus S or HTC Hero (2.1) but there are reasons for this:
Nexus S has a better GPU and Android version
Samsung have enabled some hardware-acceleration wizardry in their later Galaxy S builds
The resolution of the Galaxy Tab is higher
My main experience has been that the effect of the garbage collector (GC) is much more prominent on the Tab, therefore it could be something to do with your memory management -- are you creating objects in your onDraw method?