Good to know. At least it's good to know that i was not going crazy :- D I used the for-loop solution to get around this issue.
On Mar 30, 7:04 am, Daniel Johansson <[email protected]> wrote: > I'm experiencing the same behavior, and I'm pretty sure it's a bug. > > I have been testing this thoroughly and it simply does not work to put > an array och another IntBuffer into a "direct" IntBuffer. > > intBuffer.clear(); > intBuffer.put(otherIntBuffer); > > This does not work if "intBuffer" is a direct IntBuffer. It does work > for indirect IntBuffers and also for direct/indirect FloatBuffers. > The error shows itself through that the intBuffer.clear() operation > does not clear the buffer the second time i run this code. That means > the next put() will append the new information to the old and there is > a buffer overflow. > > The workaround is to create a for-loop that puts one element at a time > from "otherIntBuffer" into "intBuffer". Or to use FloatBuffers. > > On Feb 2, 4:24 pm, shaun <[email protected]> wrote: > > > > > I am trying to optimize the OpenGL ES rendering pipeline, along with > > general optimizations for a proof of concept. One thing I did was to > > take vertex and texture coordinate float[] data and FloatBuffer that > > are passed to gl*Pointer methods and convert them into int[] data > > andIntBufferobjects, because I am using GL_FIXED and fixed point math. > > > After initializing/allocateDirect()'ing the IntBuffers and put()'ing > > the int[] data in them for the first time, the render() method is > > called once per frame. After the rendering, the int[] data is updated > > for both vertex and texture data. Then, the following methods are > > called on theIntBufferobjects: > > -vertices_buffer.clear() > > -vertices_buffer.put(vertices) // vertices is a int [] > > -vertices_buffer.position(0) > > > This was not problem when using float[] and FloatBuffer, but a > > BufferOverflowException is being thrown on that call to put(). The > > API says this is only thrown when the remaining size of theIntBuffer > > is less than the length of the int[] passed in. Well, both of those > > values are output to the log on the line just prior to calling put() > > (intBuf.remaining() and intArr.length). They both output 600, and > > last I checked 600 is not less than 600! > > > I figure I am missing something simple. I checked the call made to > > allocateDirect() and it looks like this: > > -vertices_direct = ByteBuffer.allocateDirect (vertices.length * > > (Integer.SIZE >> 3)); > > -vertices_direct.order (ByteOrder.nativeOrder ()); > > -vertices_buffer = vertices_direct.asIntBuffer(); > > > The original code (using floating point math and Android SDK m3-rc37a) > > can be found > > here:http://www.enfis.it/wp-content/uploads/2008/01/tunnel3d.ziphttp://www... > > > Obviously, I had to convert the original code up to Android SDK 1.0 > > r2. I ended up using EGL as I did not see a way around it. Keep in > > mind I have little OpenGL experience, let alone ES 1.0 on Android.- Hide > > quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
