David, Thanks for the explanation. I think I just took fairness for granted and didn't realize that it was not guaranteed. I like the acquire()/ release() of semaphore. It's simple and sweet. I already do that with my world to synchronize the logic and renderer but stuck to a small synchronized block for input because it works fine in that area.
Jeremy, Sorry, I didn't realize that it was only the last few objects in your display list. Can you do a test if you haven't already? Can you cut out all but 1 or so of the cows in the display list and see if it still flickers? Basically mess with what you're drawing until you start to see where problems occur? On Oct 5, 5:05 pm, David Minor <davemi...@gmail.com> wrote: > I notice in your article the issue you describe seems to be > synchronization "fairness", i.e. Java doesn't make any fairness > guarantees about serving threads in the order they are waiting (though > I believe many Java implementations do). Have you tried the Semaphore > class? It allows you to specify whether it's fair or not in the > constructor. > > On Oct 5, 12:10 pm, Robert Green <rbgrn....@gmail.com> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
