I'm trying to convert from using RENDERMODE_CONTINUOUSLY to RENDERMODE_WHEN_DIRTY, to reduce overall system load -- the game view is static a fair % of the time. It hasn't been working reliably, probably for the reasons you describe in that post.
My input handling is essentially the same as what you describe as an input pipeline, except for the mutex object -- it makes sense to use a more specific mutex rather than the whole game loop. I will give that a try -- I However, I don't think that helps much to explain the flickering. But I'll reserve judgement until I have a chance to try it :) Jeremy On Oct 5, 1:10 pm, Robert Green <rbgrn....@gmail.com> wrote: > 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 theflicker. > > > 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 theOpenGLcommand 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 whereOpenGLis 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 theOpenGL > > > > > 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 correctlyOpenGLinternally 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 toflicker-- 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 seeingflicker? 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 -~----------~----~----~----~------~----~------~--~---
