He removed reliance on GC in the game-loop altogether _completely_. Then added and improved view-frustum culling, and usage of 16.16 fixed-point. Texture complexity was no issue, so went back to using crisp huge textures.
Framerate initially was like 13fps, now never falls under 33fps, is 50 at many places, and 75 at some places.
Info about framerate is sent via USB to Eclipse, and is consistent with observation (by my trained eyes ^^ ).
Float-to-string code was supplied, so that he could write framerate info to a char[] and send over USB.

Objects rendered are about 12. Qualcomm are not expected to release info on their JNI-using Neocore demo.

In my own code, I'm rendering all my geometry into dynamic vertex arrays, but limited only to floats so far - which is the limiting factor in my case (IntBuffer's fix will come with next FW update). Apart from fillrate limits when blending.

not sure if it's genuine but here it says otherwise

http://en.androidwiki.com/wiki/Neocore

'Parts of the source may be released once we've uploaded some games that will be based on this tech. Nov 19 08'

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using java Syntax Highlighting

1.        
2. public void draw(View view)
3.         {
4.                 if(my_texture != null)
5.                 {
6.                         flushVertexBuffer();
7.                        
8.                         view.bindTexture(my_texture.my_texture);
9.                        
10.                         view.my_gl10.glVertexPointer(3, GL10.GL_FLOAT, 0, vertexBuffer);
11.                        
12.                         view.my_gl10.glTexCoordPointer(2, GL10.GL_FLOAT, 0, textureBuffer);
13.                        
14.                         view.my_gl10.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 0, 4);
15.                 }
16.         }
17.  

Parsed in 0.031 seconds, using GeSHi 1.0.8.4

To even go faster use Vertex Buffer Objects (VBO) to store your vertices and texture coordinate points in GPU memory. This saves the time it takes to copy the vertices and texture coordinate points across the GPU bus.

When creating my own game Puzzle Blox for Android I also started to use canvas API instead of OpenGL. Today I must admit that this was not the brightest idea

However, it turned out that even if using the canvas API you can get significant (!) performance increased when using ARGB_4444 instead of ARGB_8888 color depth for your sprites. Though the emulator will most likely be a bit slower the real T-Mobile G1 device gets a very nice speed boost. In this case OpenGL might not even be needed anymore.

BubbleZap wrote:

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using java Syntax Highlighting

1.        
2. public void draw(View view)
3.         {
4.                 if(my_texture != null)
5.                 {
6.                         flushVertexBuffer();
7.                        
8.                         view.bindTexture(my_texture.my_texture);
9.                        
10.                         view.my_gl10.glVertexPointer(3, GL10.GL_FLOAT, 0, vertexBuffer);
11.                        
12.                         view.my_gl10.glTexCoordPointer(2, GL10.GL_FLOAT, 0, textureBuffer);
13.                        
14.                         view.my_gl10.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 0, 4);
15.                 }
16.         }
17.  

Parsed in 0.035 seconds, using GeSHi 1.0.8.4

To even go faster use Vertex Buffer Objects (VBO) to store your vertices and texture coordinate points in GPU memory. This saves the time it takes to copy the vertices and texture coordinate points across the GPU bus.

Syntax: [ Download ] [ Hide ]

Syntax: [ Download ] [ Show ]

Using java Syntax Highlighting

1.        
2. public void draw(View view)
3.         {
4.                 if(my_texture != null)
5.                 {
6.                         flushVertexBuffer();
7.                        
8.                         view.bindTexture(my_texture.my_texture);
9.                        
10.                         view.my_gl10.glBindBuffer(GL10.GL_ARRAY_BUFFER, TexCoordHandle[0] );
11.  
12.                         view.my_gl10.glTexCoordPointer(2, GL10.GL_FLOAT, 0, 0 );
13.  
14.                         view.my_gl10.glBindBuffer(GL10.GL_ARRAY_BUFFER, VertexHandle[0]);
15.  
16.                         view.my_gl10.glDrawArrays(GL10.GL_TRIANGLE_STRIP, 0, 4);
17.                 }
18.         }
19.  

Parsed in 0.035 seconds, using GeSHi 1.0.8.4

VBO related question :
Is there some benefits to expect from VBO, when there is no hardware GPU support (HTC Hero case ? ) ?

I mean : such platforms may be the targets for those expecting their app to run on a wide majority of platfoms
(As they are weakest ones considering graphic power). If there is no gain expected for them, "the game might not worth the candle".

( Sorry if it has been answered somewhere around there )

I would like to dedicate this thread to OpenGL ES and android rendering optimization techniques. Finally we have a platform were we can micro optimize and feel good about it. This is the search for the need for speed
Chris Pruit talked about texture2D extension as the fastes sprite rendering method:
http://code.google.com/intl/da-DK/event ... droid.html

In the spriteMethodTest code he uses the drawTexture2D extension, but his class does not use vertexArrays or VBO's, he uses float vertices insted of fixed for positioning, so you dont really have to think that hard to optimize further.

Please lets share our thoughts regarding graphics optimizations here.

I've recently ported my Canvas based 2D game over to OpenGL and could really need some help getting things up to speed. Until now I draw all sprites using the drawTexture2D extension as recommended in the famous Google IO video.

Now this method doesn't support rotating a sprite. Also like mentioned in the Google video, font rendering using drawTexture2D is real slow when you have your whole font in a single texture and crop this texture for each character.

So until now I've tried (on a G2/Magic):

drawing a highscore table consisting of about 80 characters:

- using drawTexture2D and texture cropping => 12-14fps
- filling a standard vertex array (not a VBO) for each character and then immediately drawing it => 7fps ?!?!

So using standard arrays was even way slower then using texture cropping.
Okay, I guess the overhead of all the openGL calls when drawing each character seperately is just too much for the little G2.

My question is, where to go from here?
For 80 rather small sprites, judging from the chart in the Google video, one should be able to attain ~60fps.

If I combine all the characters and other sprites over the course of a frame and then at the end of the frame render them sortet by texture, resulting in only a few draw calls instead of 80+, should that alone give me such a dramatic performance increase (from 7 to 60)?

How have you gies solved this?

To be honest not being able to make 80 draw calls per frame was a bit shocking to me.

Any input is appreciated.

PS: I'm using the application, activity and OpenGLES setup code from a google example, so I guess that shouldn't be the problem.