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 is not fixed in SDK 1.5 r3. Generally, most of techiques that works perfect on most platforms is UNUSABLE on Android! 1. Any dynamic vertex transforms like joint animation, particle systems processing (etc., where you're forced to update vertex buffer each frame) is unusable because FloatBuffer.put(float[]) leaks HORRIBLY! Also, gl.glVertexPointer(2, GL10.GL_FLOAT, 0, FloatBuffer) leaks again. So, it seems we must forget about any dynamics, only static geometry can be rendered. 2. Ok. But as we can see static geometry rendering using gl.glVertexPointer(,,,FloatBuffer) also leaks! How can it be avoided? Of course, using static buffers(VBO)! Note that as recommended in Android SDK, we use android.opengl.GLSurfaceView, ... surprise!!! calling function Gl11.glGenBuffers() failed with UnsupportedOperationException! Current standard OpenGL implementation does not support VBO! Looks like the end point of 3D game development for Android... How can these horrible things can be avoided? 1. Static VBOs Take a look to the SpriteMethodTest application. It uses VBO and it works! But it has its own realization of GLSurfaceView class, incompatible with current standard android.opengl.GLSurfaceView interface: http://code.google.com/p/apps-for-android/source/browse/trunk/SpriteMethodTest/src/com/android/spritemethodtest/GLSurfaceView.java?r=150 Note that it was written on Mar 28, 2009. But current release (SDK 1.5 r3) of android.opengl.GLSurfaceView still does not support VBO. Maybe, I misunderstood something, but now it seems the only way to use VBO is to realize my own GLSurfaceView class similar to SpriteMethodTest sample... 2. Particle systems, joint (skeletal) animation: I don't see any acceptable way to use skeletal animation because of leaks while working with FloatBuffer. As for particles, we can draw each particle as a separate sprite (it's significantly slower than drawing pre-transformed buffer) or draw using glDrawTexfOES() extension. In this case it's faster, but we cannot change premultilplied color, rotation angle of each particle etc, so it's a "lame" but acceptable realization. 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... Guys, if you have thoughts about avoiding bad places of Android OpenGL realization, please write to this thread. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
