glFlush or glFinish might allow something like that: http://java.sun.com/javame/reference/apis/jsr239/javax/microedition/khronos/opengles/GL10.html#glFinish() http://java.sun.com/javame/reference/apis/jsr239/javax/microedition/khronos/opengles/GL10.html#glFlush()
I've never had to use or look into them myself. Maybe because GLSurfaceView calls eglSwapBuffers between onDrawFrame calls, which does an implicit flush anyway, and I only modify the buffers pointed to by the pointer methods in those onDrawFrame calls right before use. Re the Android 1.5 issue, I was referring to this method: http://developer.android.com/intl/fr/reference/java/nio/IntBuffer.html#put%28int[],%20int,%20int%29 I use methods like that a lot because I benchmarked that it was faster to update the vales in an array and then put the array into a buffer than it was to put a lot of values into a buffer one by one. So, for example, I have an atlas texture generation script that also generates an array of all the texture coordinates my sprites might ever want. I tend to arraycopy whole sections of that array into other arrays or put them into the single shared texture buffer I use. Similarly, in the latest game I'm working on, all the positions for all the near screen sprites get set in one array which only gets put into the single shared vertex buffer they all use right before use in onDrawFrame. Using the same buffer for multiple entities allows you to use one draw command for each group of them that needs various state, like different blending functions, rather than one draw command for each of them. On Feb 13, 2:08 pm, Clankrieger <tob...@googlemail.com> wrote: > Thank you for your hints. > > I already reposition to 0 in my getBuffer methods similar to this: > > public Buffer getBufferVtx() { > m_VtxBuffer.position(0); > return m_VtxBuffer; > > } > > Also, the buffers do not get recycled between glDrawElements calls. > What did you mean with this : > > > Another rough one was that in Android 1.5 putting an array into a > > buffer using a non-zero offset into the array to start from doesn't > > work. Works in later versions of Android, however. > > I am not using multiplexed arrays, thus each array starts at index 0 > (for color, vertices and texcoords). The data it self is absolutely > fine - I validated this in my PC version. > > Is there any way to force that the GL interface on Android has > rendered all data provided during the OnDraw event of the render? How > bad/important are the clientstates (glEnableClientState) on Android? > Can I recycle the ByteBuffers every frame or should I have several > that get swapped each frame - I`ve read somewhere that GlSurfaceView > gets double-buffered - maybe I simply change the bytebuffers in an > OnDraw call where it gets used by a native render call? > > On 13 Feb., 07:24, Lance Nanek <lna...@gmail.com> wrote: > > > I haven't run into anything like that myself. I do often run into > > issues that can cause the data to be incorrectly offset or otherwise > > messed up, however, which might look similar. > > > The position of the buffer is important when you call glVertexPointer, > > for example. So if the way you filled the buffer changed the position, > > it has to be rewound or otherwise set back to where you want it before > > you call glVertexPointer. > > > Another rough one was that in Android 1.5 putting an array into a > > buffer using a non-zero offset into the array to start from doesn't > > work. Works in later versions of Android, however. > > > Another issue is that the way the glVertexPointer call works is that > > it doesn't consume the actual data. It is just setting the pointer to > > the data. So changing the data before your other calls actually cause > > it be used later on would cause trouble. > > > On Feb 12, 5:02 am, Clankrieger <tob...@googlemail.com> wrote: > > > > Hi, > > > > I got an issue while rendering a number of meshes on aGlSurfaceView > > > renderer: The meshes are sometimes broken or are not updated on screen > > > during my render call. The whole 1.6 application is running single > > > threaded, rendering is done with vertexpointers like this: > > > > glVertexPointer(3, GL10.GL_FIXED, 0, > > > (IntBuffer)_pMesh.getBufferVtx()); > > > > It looks a bit like the native interfaced get spammed by my render > > > calls and do not get enough time to natively actually draw the data? > > > It behaves completely the same on emulator and an actual phone. I am > > > using the rendering pipeline on a PC project as well were is works > > > absolutely fine. > > > > I begun feeling really desperate and dumb because I can't get this > > > working properly since days. :( > > > > Thank you! > > -- 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
