On Sep 2, 7:39 am, Sockmonster wrote:
> The stutters seem to match up with the GC. However, I tried Dmitry's
> non-direct ByteBuffer code in the hope that it would calm the GC down,
> but it has no effect! I find it hard to believe that my app is
> creating 13k object every 140ms! What do you thi
Hi All,
I've been playing around with OpenGL ES on my phone and have hit a
strange bug that looks like it may be caused by the GC problem
discussed in this post. Basically I'm drawing a single quad (actually
2 triangles) in glOrtho and rotating it around the z-axis, but the app
stutters every cou
I had this problem, and moved to using a vector-buffer-object, which
fixed it.
in constructor:
gl.glGenBuffers(NUM_BUFFERS, buffers, 0);
vertex_object = buffers[0];
index_object = buffers[1];
final float vertices[] = { // Z = V | Y = L | X = W | TX | TY
OK, you've made it absolutely clear that non-direct buffers are
definately a no-no :)
Anyway, I will stick to VBOs (which, as Jack explained, do not need
direct buffers at all).
I hope this thread will be helpful to others as much as it was for me.
Dmitry
On 7 авг, 01:07, fadden wrote:
> On Au
On Aug 5, 8:17 pm, "Dmitry.Skiba" wrote:
> By the way, to guarantee that non-direct buffer will not be moved be
> GC one can hack up a JNI lib wich will 'pin' needed buffers for the
> lifetime of an application :)
Actually, you can't. The VM has the option to pin or copy the data in
the virtual
You don't need to use a direct buffer with VBOs, because VBO APIs like
glSetBufferData don't hold onto their own pointers to the buffer data.
They make a copy of the data when you call them.
The problem you're seeing with glDrawArrays count argument sounds like
a bug. If you get a chance, please
We considered doing that, but were worried about possible DalvikVM
problems with leaving large amounts of memory pinned for long time
periods. We decided it was better not to do that.
On Aug 5, 8:17 pm, "Dmitry.Skiba" wrote:
> By the way, to guarantee that non-direct buffer will not be moved be
Woops -- I left out a very important detail: Direct Buffers are only
required for OpenGL ES APIs that hold onto the pointer that you pass
into the API. APIs that operate on buffers immediately can take either
direct or indirect buffers.
So, for example glVertexPointer requires a Direct buffer bec
By the way, to guarantee that non-direct buffer will not be moved be
GC one can hack up a JNI lib wich will 'pin' needed buffers for the
lifetime of an application :)
On 6 авг, 10:07, "Dmitry.Skiba" wrote:
> Thank you Jack for your explanation.
>
> I am using VBOs now, so I can easily switch to
Thank you Jack for your explanation.
I am using VBOs now, so I can easily switch to direct buffers. By the
way, what is the limit for VBO buffers? (if there is one)
And one more thing. In my code I am drawing a 1008-vertex geometry
using glDrawArrays(GL_TRIANGLES). Weird thing is that it draws m
Hi -- I work on the Java Open GL ES bindings for Android. Fadden asked
me to chime in here.
Please don't use indirect buffers with OpenGL ES -- indirect buffers
are not supported, and your code will break, both on current and
especially on future versions of Android.
Let me see if I can explain
On Aug 4, 11:09 pm, "Dmitry.Skiba" wrote:
> I've found a way to get rid of garbage collection!
> The receipt is simple (and ironic): do not use allocateDirect(), use
> allocate(). And use only ByteBuffer, not FloatBuffer, IntBuffer, etc.
> - using asFloatBuffer() on non-direct ByteBuffer will res
Paul, I forgot the assignment, mVertexBuffer=vbb; :)
Yes, it crashes because as I suspect, GL's JNI code can't deal with
XXXBuffer wrapping non-direct ByteBuffer. Thats why you should avoid
using anything except ByteBuffer when you use allocate(). Luckily
ByteBuffer has all the needed methods, put
Dimitry,
2009/8/5 Dmitry.Skiba :
>
> should be
>
> ByteBuffer vbb = ByteBuffer.allocate(vertices.length*4);
> vbb.order(ByteOrder.nativeOrder());
> for (int vertex: vertices) {
> mVertexBuffer.putInt(vertex);
> }
> mVertexBuffer.position(0);
Wher
Good news, gyus!
I've found a way to get rid of garbage collection!
The receipt is simple (and ironic): do not use allocateDirect(), use
allocate(). And use only ByteBuffer, not FloatBuffer, IntBuffer, etc.
- using asFloatBuffer() on non-direct ByteBuffer will result in crash
in libhgl. (I'm too
Yes, and this is because they do not use any GL10 methods.
All game is one big jni lib with tiny wrapper of java classes ontop.
The only question is: how did they manage to access gl from jni?
Dmitry
On 1 авг, 00:15, Nightwolf wrote:
> I think things aren't that bad. Take a look at Armadillo R
I think things aren't that bad. Take a look at Armadillo Roll.
Checking DDMS showed that GC was't invoked during watching demo flyby
and playing the game for 3-4 minutes.
On Jul 29, 12:57 pm, Paul Thomas
wrote:
> Thanks for your helpful comments, everybody.
>
> 2009/7/28 smartpixgames :
>
> > In
Thanks for your helpful comments, everybody.
2009/7/28 smartpixgames :
> In general, it's very frustrating that we have a good hardware useful
> for gaming, but a bad realization of very critical things for
> 3D-gaming and now it's almost impossible to develop quality 3D-games
> for Android...
Y
Definitely, without any processing, it looks like function calls
gl.glVertexPointer(2, GL10.GL_FLOAT, 0, vBuffer);
gl.glDrawElements(GL10.GL_TRIANGLES, 3, GL10.GL_UNSIGNED_SHORT,
iBuffer);
causes intenal memory allocations. Switching to GL_FIXED instead of
GL_FLOAT doesn't help.
This issue
I had a similar problem with my Gears4Android demo (http://
www.jeffboody.net/gears4android.php) but in my case I was using the
buffer "wrap" methods in the rendering loop. My code is available on
my website if it helps. When I removed the buffer "wrap" methods, I
was able to completely get rid of
On Jul 16, 7:33 am, PaulT
wrote:
> It's pretty simple stuff just to get an idea of the device
> performance. Note that I am not leaking any garbage in this method.
I believe this is a known issue. An external developer provided a
patch:
https://review.source.android.com/#change,8767
A modi
I had a similar problem which appeared to be related to my use of
texturing with glTexturePointer() but maybe it's something to do with
using GL_FLOAT.
It's entirely speculation on my part though...
On Jul 16, 3:33 pm, PaulT
wrote:
> Hello everybody,
>
> I've created a simple OpenGL app and crea
22 matches
Mail list logo
