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.
Related
I'm developing an app that renders the camera preview straight to a custom GlSurfaceView I have created.
It's pretty basic for someone who uses OpenGL on regular base.
The problem I'm experiencing is a low fps on some of the devices and I came with a solution - to choose which shader to apply on runtime. Now, I don't want to load a OpenGl program, measure the fps and than change the program to a lighter shader because it would create definite lags.
What I would like to do is somehow determine the GPU strength before I'm linking the GL program(Right after I'm creating the openGL context).
After some hours of investigation I pretty much understood that it won't gonna be very easy - mostly because the rendering time depends on hidden dev elements like - device gpu memory, openGL pipeline which might be implemented differently for different devices.
As I see it I have only 1 or 2 options, render a texture off-screen and measure its rendering time - if its takes longer that 16 millis(recommended fps time by Romain Guy from this post) I'll use the lighter shader.
Or - checking OS version and available RAM (though it really inaccurate).
I really hope for a more elegant and accurate solution.
I'm writing an OpenGL ES 2.0 game in C++ running on multiple (mobile) platforms.
On IOS,Android,.. basically everything runs fine, except one device:
The computation for one frame in a specific scene take about 8ms on an HTC Desire.
Another device, a Samsung Galaxy Nexus, which is much newer takes 18-20ms.
I digged into the problem and found out that it is related to enable/disable of GL_DEPTH_TEST.
if I comment out all glEnable(GL_DEPTH_TEST)/glDisable(GL_DEPTH_TEST) calls the time needed for one frame drops to 1-2ms on the Nexus.
so I optimized the glEnable()/glDisable() calls to occur only when absolutely needed. I have 3d and 2d parts in my scene and therefore need to render 2d without depth_test and 3d with depth test.
currently I enable depth test, draw 3d, disable depth test, draw 2d
but still the computation takes 18-20ms on the nexus
I also checked if the depth buffer is cleared more than needed. But it is just cleared at the start of the frame.
Is it possible that the switch of the depth test takes that much time?
Does anyone have other ideas what can be checked?
UPDATE
I found out that the 3d object I render is somehow responsible for the slow computation.
If I remove the 3d object the performance is good
but the same 3d object is used in another scene without causing such trouble
and the weirdest thing: the Nexus runs Android 4.2 and it has an option in the developer options to visualize the cpu load as an overlay. If I enable this setting and start the game, the computation time is 5-6ms instead of 18-20ms. How can this be related?
Our Android game has an issue which appears unique to the Galaxy S2.
Occasionally the render will stutter. By this I mean it basically seems to render the last two frames (as though its swapping the last two render buffers without updating either).
What's really odd about this is that the game continues to update, so say the stutter lasts for 2 seconds, the game will have progressed 2 seconds behind the scenes.
This is odd because our code is basically like this:
function Update()
DoGameLogic()
DoRender()
So this means that if our the game has updated, the game has also rendered. The maximum delta time is capped to 1 frame so there must have been more than one Update and thus multiple renders during the stutter.
My current theory is that on most devices the game lags during render, but on the S2 the render calls are executed but they "fall through" without updating the render buffer.
Has anyone run into this problem? I would really appreciate any suggestions about what this could be.
We found out what the problem is.
The Galaxy S 2 was for some reason running out of GL memory. This wasn't apparent on the devices we were testing with, but on other devices it would crash on some Open GL call - not the offending call mind you.
Eventually we tracked it down to using Point sprite VBO's. As the S 2 is a powerful device, we replaced Point sprites with Quad's mimicking point sprites as a workaround.
Incidentally, SoundPool would also run out of memory on this device, requiring another workaround.
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?
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.