[android-developers] Re: Performance comparison NDK vs SDK

2010-04-21 Thread Lance Nanek
most sprites are rendered via the draw_texture extension For very large numbers of sprites I've found that the standard draw arrays/elements methods are much faster than the draw_texture extension in cases where you can arrange to draw multiple sprites per draw call. That's impossible with the

Re: [android-developers] Re: Performance comparison NDK vs SDK

2010-04-18 Thread Ralf Schneider
Pre-scale the background image to match the device resolution. Split the background image in texture tiles like 256x256, 128x128, Blitt the tiles separately. 2010/4/8 lixin China smallli...@gmail.com Hi Schneider: As you said avoid scale the texture. Could you tell me the solution how

[android-developers] Re: Performance comparison NDK vs SDK

2010-04-13 Thread lixin China
Hi Schneider: As you said avoid scale the texture. Could you tell me the solution how to render background texture(480x320 to full screen) without scale. On Apr 7, 5:28 am, Ralf Schneider li...@gestaltgeber.com wrote: If your performance problem is only related to putting sprites on the screen,

Re: [android-developers] Re: Performance comparison NDK vs SDK

2010-04-08 Thread Ralf Schneider
You are benchmarking some math functions. If you compile the C Code with the default setting from the NDK all floating point operations are emulated. The Java version executed on the Dalvik VM will hopefully use real floating point instructions - if the CPU supports it. So, as all benchmarks

[android-developers] Re: Performance comparison NDK vs SDK

2010-04-07 Thread MrChaz
100 is a low estimate but it's around that point that the frame-rate seems to get into the sub 30's. I'm already doing pretty much everything you've mentioned except using VBOs - most sprites are rendered via the draw_texture extension. Unfortunately pretty much all the sprites have some

Re: [android-developers] Re: Performance comparison NDK vs SDK

2010-04-07 Thread Ralf Schneider
There exists (GL_UNSIGNED_SHORT_4_4_4_4) Textures. May be this helps a litle bit. I'm not sure but switching to VBOs might not bring an improvement. My observation on a Nexus One is: VBOs are great if there are many tris (250) to render per call. For billboards it really doesn't matter that

[android-developers] Re: Performance comparison NDK vs SDK

2010-04-07 Thread Menion
I'm doing some little research school project, together with learning basics of C++ (thanks to JNI) and here is some simple example ... Java function: --- public double doClickAction04J() { double x = 45.0 / (180.0 / Math.PI); double result = 0.5; for

[android-developers] Re: Performance comparison NDK vs SDK

2010-04-06 Thread MrChaz
I was hoping that someone had tried a little test app with a simple scene. I think I've pretty much reached the limits in terms of get sprites on the screen at an acceptable frame rate (at least on G1 type hardware). It seems, at least for what I'm doing, the limit is about 100 sprites but for my

Re: [android-developers] Re: Performance comparison NDK vs SDK

2010-04-06 Thread Ralf Schneider
If your performance problem is only related to putting sprites on the screen, don't expect an improvement by witching to the NDK. I don't know how you are currently doint it, but these are some general remarks: Use OpenGL ES to draw the sprites. Limit your textures to 256x256. 512x512 seems to