I'm just starting to learn OpenGL ES2 for Android, and have come across a weird problem where sometimes a weird jut will be rendered from my objects (see pic). This doesn't always happen, which is strange, so I'm wondering if anyone has any experience with this sort of thing and how to fix it.
http://img717.imageshack.us/i/device2h.png/
The problem here was that I was calling GLES20.glDrawArrays(type, first, count) with an incorrect count. Setting the variable correctly fixed it.
Related
I'm developing a game using andengine. On my scene i have only 3 sprites moving in the same direction. So the problem is that it sometimes hangs after less than a second and sometimes not. Interface does not respond. Logcat shows no problems at all. It looks like it hangs somewhere inside andengine, but I can't figure it out. I just managed to track it down using step over in OnManagedUpdate method of Entity class on line
entities.get(i).onUpdate(pSecondsElapsed);
When i step over it just hangs and I can't step into it.
Did anybody face such problems? What it could be?
I found the bug - the sprites animation rate was generated randomly and sometimes it got negative value. I'm realy sorry for such a vague question, it's just the project is large enough to take a lot of time to isolate the problem code part.
GC Malloc is called on every frame when Camera.preview callback is running. I'm assuming that this adds to to slowness of myframe rate.
Does anybody have any advice on ways to reduce these calls. I've tried searching on google groups and there does not seem to be many response, so I wanted to get information from people who are building and using camera preview in their applications.
As GC Malloc is being called it seems a new piece of data is being used each time to hold a frame. Can this be predefined? - Is this what callbackwithBuffer does? Ive had trouble getting my head around this and have been unable to implement the callback with buffer properly so any help on how to do this would be appreciated.
Also could someone fully explain what is happen in memory with the frames when camera preview running.
Thanks in advanced.
The problem you are having is an issue in older versions of android where memory is allocated and garbage collected in short span of time causing performance bottlenecks .
Explanation can be found here: http://code.google.com/p/android/issues/detail?id=2794
Your issue can be fixed by using some hidden methods. However you need to expose them by using reflection (the bug link has further examples).
If I recall correctly this issue has been fixed in Froyo.
I have an Android application and, under certain situations, some, but not all, of our textures seem to become unbound. (That is, when I use glBindTexture and draw it, it is rendered as a blank texture)
I've tried looking for an error from glBindTexture, and tried using glGet with GL_TEXTURE_BINDING_2D, but nothing has helped thus far.
Is there any way to discover if a texture name is still valid/pointing to valid data?
My last resort is to save some small amount of pixel data and then, when these events happen, bind and use glReadPixels and see if they're still there... But that seems really... non-optimal...
This is OpenGL ES 1.0/1.1.
Sounds like glIsTexture is what you're looking for.
glIsTexture is not valid reply to this question. glIsTexture is returning true even if the texture name is not valid. This is a problem of Android implementation of OpenGL. I have no solution to this.
I'm trying to put a particle system together in Android, using OpenGL. I want a few thousand particles, most of which will probably be offscreen at any given time. They're fairly simple particles visually, and my world is 2D, but they will be moving, changing colour (not size - they're 2x2), and I need to be able to add and remove then.
I currently have an array which I iterate through, handling velocity changes, managing lifecyling (killing old ones, adding new ones), and plotting them, using glDrawArrays. What OpenGl is pointing at, though, for this call, is a single vertex; I glTranslatex it to the relevant co-ords for each particle I want to plot, one at a time, set the colour with glColor4x then glDrawArrays it. It works, but it's a bit slow and only works for a few hundred particles. I'm handling the clipping myself.
I've written a system to support static particles which I have loaded into a vertex/colourarray and plot using glDrawArrays, but this approach only seems suitable for particles which will never change relative location (ie I move all of them using glTranslate), colour and where I don't need to add/remove particles. A few tests on my phone (HTC Desire) suggest that trying to alter the contents of those arrays (which are ByteBuffers, pointed to by OpenGL) is extremely slow.
Perhaps there's some way of manually writing the screen myself with the CPU. If I'm just plotting 1x1/2x2 dots on the screen, and I'm purely interested in writing and not doing any blending/antialiasing, is this an option? Would it be quicker than whatever OpenGl is doing?
(200 or so particles on a 1ghz machine with megs of ram. This is way slower than I was getting 20 years ago on a 7mhz machine with <500k of ram! I appreciate I'm using Java here, but surely there must be a better solution. Do I have to use the NDK to get the power of C++, or is what I'm after possible)
I've been hoping somebody might answer this definitively, as I'll be needing particles on Android myself. (I'm working in C++, though -- Currently using glDrawArrays(), but haven't pushed particles to the limit yet.)
I found this thread on gamedev.stackexchange.com (not Android-specific), and nobody can agree on the best approach there, but you might want to try a few things out and see for yourself.
I was going to suggest glDrawArrays(GL_POINTS, ...) with glPointSize(), but the guy asking the question there seemed unhappy with it.
Let us know if you find a good solution!
I'm writing a graphically intense game for the Nexus One, using the NDK (revision 4) and OpenGL ES 2.0. We're really pushing the hardware here, and for the most part it works well, except every once in a while I get a serious crash with this log message:
W/SharedBufferStack( 398): waitForCondition(LockCondition) timed out
(identity=9, status=0). CPU may be pegged. trying again.
The entire system locks up, repeats this message over and over, and will either restart after a couple minutes or we have to reboot it manually. We're using Android OS 2.1, update 1.
I know a few other people out there have seen this bug, sometimes in relation to audio. In my case it's caused by the SharedBufferStack, so I'm guessing it's an OpenGL issue. Has anyone encountered this, and better yet fixed it? Or does anyone know what's going on with the SharedBufferStack to help me narrow things down?
I don't believe such error can occur in audio code, SharedBufferStack is only used in Surface libraries. Most probably this is a bug in EGL swapBuffers or SurfaceFlinger implementation, and you should file it to the bug tracker.
I got CPU may be pegged messages on LogCat because I had a ArrayBlockingQueue in my code. If you have any blocking queue (as seems to be the case with audio buffers), be sure to BlockingQueue.put() only if you have timing control enough to properly BlockingQueue.take() elements to make room for it. Or else, have a look on using BlockingQueue.offer().
The waitForCondition() causes the lockup (system-freeze).
But it is not the root-cause. This seems to be a issue with
The audio-framework (ur game has sounds?)
-or-
The GL rendering-subsystem.
Any "CPU-pegged" messages in the log?
You might want to take a look at this:
http://soledadpenades.com/2009/08/25/is-the-cpu-pegged-and-friends/
There seems to be a driver problem with eglSwapBuffers():
http://code.google.com/p/android/issues/detail?id=20833&q=cpu%20may%20be%20pegged&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars
One workaround is to call glFinish() preceding your call to eglSwapBuffers(), however this will induce a performance hit.
FWIW, I hit this issue recently while developing on Android 2.3.4 using GL ES 2 on a Samsung Galaxy S.
The issue for me was a bug in my glDrawArrays call - I was rendering past the end of the buffer, i.e. the "count" I was passing in was greater than the actual count. Interestingly, that call did not throw an exception, but it would intermittently result in the issue you described. Also, the buffer I ended up rendering looked wrong so I knew something was off. The "CPU may be pegged" thing just made it more annoying to track down the real issue.