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 <[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 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 <[email protected]> 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 <[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 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 [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
-~----------~----~----~----~------~----~------~--~---
