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
Have you tried adding sleep(32) (or sleep(16), you need to experiment
with the values) to your on onTouchEvent handler? There is a known
issue with the GUI thread being bombarded with touch events when the
user touches the screen. The effect of these events can be to starve
your other threads
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
I just read your post. Looks like I hit the same problem about 6 months ago.
I even managed to create a mostly-reproducible test case so that I could
file an issue:
http://code.google.com/p/android/issues/detail?id=1956
(I can only think that it's some sort of fairness issue with monitors)
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
The issue you filed focuses on touch event handling, but I see
flickering just as much with trackball events. If it is a fundamental
thread scheduling issue, I guess it wouldn't matter the type or even
frequency of events being generated.
On Oct 5, 2:01 pm, Tom Gibara m...@tomgibara.com 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
Warning, pure speculation follows:
Touching the screen generates events very rapidly, and using the trackball
probably does too. Anecdotally, I encountered the bug with increasing
frequency as the work done within the synchronized block lengthened (I think
- it was a while ago and I can't recall
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
I do sleep between touch events in the UI thread, after posting the
event to the logic thread.
On Oct 5, 10:19 am, RichardC richard.crit...@googlemail.com wrote:
Have you tried adding sleep(32) (or sleep(16), you need to experiment
with the values) to your on onTouchEvent handler? There is a
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
Is there any synchronization between the rendering thread and the game
logic thread?
On Oct 5, 7: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
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
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
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
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
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
17 matches
Mail list logo
