So I recently created a game with several activities. On my HTC Thunderbolt, all parts of the game seem to be running very fast; however, on my Galaxy 10.1, two of my five activities are running extremely slow (i.e. screen fading is slow, enemies and cursor are moving slow as well). I don't know what is wrong. The other activities are running at or at least near the speed my thunderbolt was running at. Can someone please help me?
Try enabling hardware accelerated graphics, which is available on Android 3.0+.
Or, if you are serious about game performance, use OpenGL instead.
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'm intermittently observing strange graphics artefacts in my app, as shown below. This is a screengrab from a Samsung Galaxy S3. I have only observed it on this particular phone. I have run the app on a Samsung Galaxy Tab S4 and an HTC One, and never observed this issue on either - although admittedly I do mainly use the S3 for development.
I considered that the issue might be some sort of concurrency clash in drawing to the Canvas (I'm using the basic Android rendering methods, no OpenGL or anything), since I can clearly recognise the repeating units of other UI elements, so I synchronized all the code which draws to or interacts with the Canvas and I'm still observing it happen.
It does clear itself up after around 30-90 seconds, which may be due to a regular scheduled memory cleanup operation it performs - so perhaps this is a manifestation of low available mem?
If I had enough rep I would stick a pretty big bounty on this. Any help appreciated. Hopefully someone recognises this particular problem.
Apply hardware layers:
setLayerType(View.LAYER_TYPE_HARDWARE, null);
I've made a simple, 3 frame, animation of a character walking to wherever you click on screen using Haxe+ Haxepunk... Well I copy/pasted code from online tutorials just to test Haxe out.
This runs great in flash, iOS simulator and on a Samsung Galaxy 3... But on my HTC desire it runs at less than 1 frame per second. While I know the desire is no spring chicken this is a massive performance gap, more so than I've seen on any app re: Galaxy vs. Desire...
Is this a Haxe problem or something I have done wrong (wrong NDK, wrong compile flags, OS too old, etc)?
Go into Engine.hx, the render() function, and comment out HXP.screen.refresh(). This line is absolutely killing performance on OUYA (an android gaming console) so it might be killing you too. Since you're not clearing the screen every frame anymore you'll want to draw a background every update by adding a Backdrop instance to your world. My game goes from 7 fps to 52 fps with these changes alone at 1080p resolution and ~80 entities.
Also try grabbing the latest HaxePunk from github and running ant to install it, the devs have been working on android performance lately and there's some good unreleased fixes which will be cream on top of the above fix.
I'm currently developing an Android game using the SDK GLES10 and I'm experiencing some performace issues with it on not so good phones like the Samsung Galaxy Ace. So I've thought about porting it to the NDK and maybe also make it use GLES20, at least the rendering part which comsumes the most CPU time.
(on the Galaxy S2 it runs with constant 61 FPS, on the Galaxy Ace it varies between 90 and 20 FPS and is stuttering most of the time)
most CPU time consumnig methods on both Galaxy S2 and Galaxy Ace are GLES10.glDrawElements(), GLES10.glVertexPointer() and GLES10.TexCoordPointer(). like 85% of overall CPU time used on the Ace and 82% on the S2.
Would it drastically increase the performance to 1. use the NDK for rendering and 2. port it to GLES20?
It really probably just depends on what you're already doing.
I'd look at finding specific bottlenecks. Saying that "rendering" is a bottleneck is way too vague to be useful.
What is holding you back exactly?
SwapBuffers call time?
too many OpenGL state changes?
GPU vertex bound?
GPU fill-rate bound?
Depending on the answer to this using NDK may help, or it may not help at all, depending on if your GPU is the limiting factor.
NDK might help you get calls to the GPU with less overhead, but you don't know if that's whats actually holding you back.
Try using the DDMS traceview if you haven't yet, and see where most of your time is going, then you can make an informed decision before you go through the trouble of a major rewrite.
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?