I do the "if anything updated" check in the game logic thread. If something is changed, I post the requestRender() to the renderer. For continuous-mode rendering, that shouldn't have any effect, as the renderer will update regardless.
And as I explained in the original post, it is not the full scene that flickers, only the last item(s) in the display list. I appreciate all the random thoughts and suggestions, though! Jeremy On Oct 5, 2:25 pm, Robert Green <[email protected]> wrote: > Jeremy, > > I just gotta ask. Is there any possibility that through an > optimization or any other way, there is a case where you're not > clearing and not drawing sometimes when a frame is drawn? I'm just > imagining a piece of code that says, "Did anything change? No? Then > just return." That would causeflicker. > > On Oct 5, 3:17 pm, Jeremy Slade <[email protected]> wrote: > > > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > > > > > > The G1 reports 65536 for that parameter. > > > > > > On Oct 4, 7:06 am, RichardC <[email protected]> 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 <[email protected]> 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 <[email protected]> > > > > > > > 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 <[email protected]> > > > > > > > > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
