I've been developing a game for Android for the past few months, and it's just about finished. I recently acquired a Motorola Droid for testing purposes, as I developed the game using a HTC Incredible. On my Incredible I can get a pretty solid 59 fps throughout the game. On the Droid, the game becomes very choppy with an average of about 40 fps. Both phones are running Android 2.2.
I looked up the tech specs are here are the only differences I noted that might affect gameplay: 1 GHz processor vs 550 MHz and 512 MB RAM vs 256 MB RAM.
Just for giggles, I thought I would strip down the game to a very minimal state to see if it was my coding to blame. I stripped it down to the point where the only thing being down was drawing the main menu and moving various bitmaps around the screen. Not a hair over 45 fps.
So, is this the approximate cap for the Motorola Droid? If so...my game is pretty simple and non-CPU intensive, so what can I do? There are thousands of other Android games that are much more demanding than my own, yet they seem to run very smoothly.
Is it the fact that I'm using Android's built-in Canvas and not Open-GL or some other alternative? Would anybody recommend doing that?
Could somebody enlighten me to what might be my problem here?
Thanks in advance.
OpenGL ES is the way to go. Canvas is most likely implemented on top of OpenGL ES anyway, and not very efficiently by the sounds of it.
40fps is pretty good, the human eye can only detect jerkiness when the framerate falls below 25fps. Anything above 15fps is considered 'full motion'.
If you can see jitter then it may be the game pausing while the garbage collector kicks in - you can reduce this by reducing the number of objects that you create and you should be able to see it happening by using ddms.
Other than that perhaps there is a glitch calculating the frame rate?
Related
I am experimenting with the Camera to MP4 example here:
https://bigflake.com/mediacodec/CameraToMpegTest.java.txt
My test app uses roughly the same code, and when I record at 1280x720 then everything is fine.
But for some reason switching to use 1920x1080 then the FPS drops and CPU usage increases.
Profiling CPU usage the problem seems to be the GLES20.glDrawArrays call.
It goes from using about 2% of CPU cycles to almost 40%. The only thing that's different is the camera preview resolution.
It seems to be crossing some sort of cache or memory re-allocation boundary. I don't have much OpenGL experience, and am not sure how I could debug this. Any advice on what I could look for?
EDIT:
Enabling Androids GPU usage overlay indicates no noticeable difference.
I am developing a simple player shooting game. It worked fine for me. But when I tried deploying it on the device the FPS reduced to almost 3-4FPS.
Can anyone list out what are the factors that reduces the FPS in unity game.
Minimize the Draw calls, optimize the shaders and Reduce the number of vertices.
Graphic Optimization
iOS specific Optimiztion
This article may help
And try deep profiling of game using Unity Profiler to find the memory overhead.
I am constantly getting 60 frames per second and doing no CPU intensive operations on a simple application displaying a single rotating triangle. Unfortunately, when using OpenGL ES 2.0 on a Samsung Galaxy Express I am recieving slight hiccups in the rendering, as if some frames are not being drawn.
The funny thing is that with OpenGL ES 1.0 there is no such hiccup, so I know it does not have to do with the rotation method or the use of System.nanoTime () as a measure of the elapsed time between frames. I use the exact same method I both, and as per my research here and with "fixing your timestep" have smoothed the game loop. I get the same results.
To make matters even funnier, the spinning triangle example from Google's own developer.android.com introduction to OpenGL has the same issue, as well as the Play Store examples from the website 'learnopengles' both of which are rendering a simple spinning triangle.
As per research into similar threads here, I have tried continuous rendering as well as dirty rendering. The slight flicker remains.
After 3 days I am wondering whether it is my device, or whether all OpenGL ES 2.0 applications have a slight stutter that is more easily noticeable on a single spinning triangle.
I have no other test device and no money for one, so I cannot say whether it is a problem with my device, or the Samsung Galaxy Express in general, or something else.
Is there anything else I can do to fix this issue?
Is this slight stutter normal behavior?
Are there any examples of code I can test myself that does not exhibit this behavior?
Does the Samsung Galaxy express have a known issue with OpenGL 2?
Thank you for reading.
It's my first question, I searched on google as always, round two was searching directly on SO, but still I couldn't get the exact answer.
I'm going to write 3D graphics engine for games I want to make in the future for Android platform. I played Doom recently on my mobile, on break in high-school, and when I lifted my head after being killed by Baron of Hell I saw more that twenty people struggling to see me playing, followed by loud "AAAAAAAW!" when they saw me dead. My jaw went down to the floor. None of them suspected that it was game from 1993.
But let's get back to the point. If you wanted to write "find it by yourself" you can stop typing now. I can't check this on my own, for different reasons. At first I own only one mid-cost device (HTC Wildfire) I can test my engine on. The second and more important reason is time. I don't have time to write whole OpenGL-ES 2.0 graphics engine and realize that my Wildfire can't even run it. Or it gets around 1FPS when walking.
For raycasting to be more realistic it needs few calculations, which are not important for me in OpenGL because I just set vertices & indices and it goes. I love the way that Doom levels are designed but I wanted to add ability to move your head up and down (rotation on X-axis) to look around and shoot more precisely, and the complexity of calculations in raycasting are growing (not for me, for CPU). I know Wildfire doesn't have any GPU and anything based on OGL (even 2D) is lagging as hell even if I overclock my CPU to #748 with PERFORMANCE governor (it turns off on higher values, and I got to move it from my Casemate to stop it from overheating). But Doom is running perfectly without any lag even if I underclock it to #448. Is this only because of lo-res textures and non-complex levels or because of raycasting?
And please don't flame for going back to such old thing like raycasting engine. Actual mobile devices, or smartphones - call them like you want - that doesn't cost $1k are in stage that computers was 18 (Doom release) years ago. There will always be a group of such devices. And even if I don't make my billion on this - I will have something to play on travel.
I've got some pretty nice ideas for games like this, and I want to hit the low cost devices as they don't have anything more spectacular than simple logic games. As this is my first question please correct anything I wrote wrong, poorly or just bad - I'll rewrite it.
We are currently developing an Android Game using opengles. We are now trying to support different resolutions, however, when allowing for large resolutions, the moto droid we are testing on seems to lag at it's native resolution (800x400). We have the frames locked at 30 fps, and when we check, our game only takes about 15-20 ms to do it's updating and drawing on the droid, however, there is sometimes 30-60 ms that elapses between calls to ondrawframe. My Galaxy S device doesn't have this problem, and when we put the resolution down on the motorola droid it seems perfectly fine.
We've investigated the issue and have found people with what seems to have been the exact same issue but no one could offer a solution. Other games on the market that seem to use opengles run fine on the moto droid.
Is there something we're missing? Something we need to call or do to? There seems like there should be no reason for there to be 30-60 ms between calls to ondrawframe, especially when the native resolution (800x400) isn't leaps and bounds larger than the default of 533x320, or whatever it is that it goes to when not allowing for large screens, so it seems ridiculous for it to be because of a buffer swap. The lag even happens when near nothing is being drawn to screen, so it's not because we're drawing too much.
Any enlightenment or help as to how to fix this would be great.
You have to give more information. If its not because of drawing, then it should be because of any calculation or object allocation code. Allocating Objects often during a game, invokes the GC, which is bad for games.
Things about performance and allocating memory for Android games is explained in the links below.
I suggest you watch these 2 videos done by Google Android Group.
http://www.youtube.com/watch?v=U4Bk5rmIpic&feature=player_embedded
http://www.youtube.com/watch?v=7-62tRHLcHk&feature=player_embedded
Hope that helps in optimizing.