I just thought of something. You said your logic thread sleeps? Are you using RENDERMODE_CONTINUOUSLY?
Here's a shot in the dark. I feel like your renderer isn't clearing the color buffer and isn't drawing anything, and that maybe happens when there's a certain state of the logic thread somehow. Drawing a frame without clearing the color buffer and without drawing anything will make for some wild flickering but the image will still be there, just flickery. I noticed that when I was messing with skyboxes and had my clear command off. By the way, I don't recommend handling input the way you are. I switched all my games to use input pipelines and they have saved me a load of trouble. I get super fast response and don't have to synchronize with a common thread mutex, which I have always had issues with it not giving up the lock to another thread. I wrote an article just now that you can take a look at if you're interested in switching - http://www.rbgrn.net/content/342-using-input-pipelines-your-android-game On Oct 5, 9:27 am, Jeremy Slade <jeremy.g.sl...@gmail.com> wrote: > I'm definitely not getting anywhere close to that limit > (GL_MAX_ELEMENTS_VERTICES). > > I'm pretty close to a root cause for at least a large percentage of > the flickering events... It has something to do with my thread > synchronization, but it's not obvious to me how it causes the flicker. > > I have three threads: > * main / UI thread > * logic thread > * rendering thread (created by GLSurfaceView) > > The majority of the flickering happens when I do something to generate > UI events (touch the screen, move the trackball, etc). I end up > passing a message to the logic thread, which may be sleeping: > > public void queueGameEvent(GameEvent ev) { > synchronized(mGameLoop) { > if ( first_event != null ) first_event.next_event = ev; > else first_event = ev; > ev.next_event = null; > //mGameLoop.notifyAll(); // wake sleeping threads > } > } > > When I have the notfyAll() call enabled, it flickers badly. Without > it, I rarely see flickers (still some, though). That method is called > from the UI thread, and should result in waking up the logic thread. > Any ideas on how / why that affects the rendering? > > Thanks, > Jeremy > > On Oct 4, 6:05 pm, Robert Green <rbgrn....@gmail.com> wrote: > > > The G1 reports 65536 for that parameter. > > > On Oct 4, 7:06 am, RichardC <richard.crit...@googlemail.com> wrote: > > > > You could try > > > > glGetIntegerv(GL_MAX_ELEMENTS_VERTICES, &value); > > > > Have not tried this myself but found it in > > > >http://gpwiki.org/forums/viewtopic.php?t=8839 > > > > On Oct 4, 7:36 am, Jeremy Slade <jeremy.g.sl...@gmail.com> wrote: > > > > > I did wonder about the OpenGL command buffer limit -- any way to > > > > verify for sure that I am hitting it? > > > > > I would be surprised if that's the case, though -- it's not a real > > > > complex scene, maybe 3000-4000 textured triangles. But I'll admit to > > > > being almost a complete novice where OpenGL is concerned... > > > > > The various meshes are all done with glDrawElements(). 95% of this is > > > > in the cow mesh -- same mesh drawn w/ different transforms, and > > > > different textures bound each time. The mesh itself uses ~54k of > > > > memory for vertices + normals + tex coords. How big is the OpenGL > > > > buffer? seems like it's got to be significantly larger than that. > > > > > On Oct 3, 1:29 pm, RichardC <richard.crit...@googlemail.com> wrote: > > > > > > If I remember correctly OpenGL internally has a limit to the number of > > > > > items it can hold in it's display list. When the list gets full it's > > > > > starts drawing rather than dropping your items. To achieve this it > > > > > flips the buffers and draws the remaining items on the live screen. > > > > > > If I am remembering correcly this could explain what you are seeing. > > > > > > -- > > > > > Ruchard > > > > > > On Oct 3, 8:08 pm, Jeremy Slade <jeremy.g.sl...@gmail.com> wrote: > > > > > > > I'm trying to clean up some rendering issues for a 3D game -- > > > > > > CowPotato (http://www.cyrket.com/package/ > > > > > > com.froogloid.android.cowpotato). I could use some help on one > > > > > > issue. > > > > > > > Basically I'm seeing some flickering, like the next frame is getting > > > > > > flushed before everything is drawn. It is definitely the last few > > > > > > items in my display list that seem to flicker -- if I reorder the > > > > > > list, it's always the last part of the list that flickers. > > > > > > > I understand that the GLSurfaceView automatically provides double- > > > > > > buffering -- it certainly appears to be the case looking at the > > > > > > source. So any suggestions as to why I might be seeing flicker? I > > > > > > put counters into the drawing methods to make sure that all the > > > > > > objects are called each frame, they just don't show up on screen all > > > > > > the time. > > > > > > > Any insight would be appreciated. > > > > > > > Jeremy > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
