Re: [android-developers] Re: Performance comparison NDK vs SDK
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 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, 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 be slower on some devices. Use texture atlases for smaller sprites - To avoid state changes in OpenGL Use VBOs Avoid textures with alpha channels on slower devices. Don't scale or rotate your sprites on slower devices. Slower devices often have a fast path for simple blitt operations. = Check if point sprites are available on the device. If yes, use them. Use 16 Bit (565) textures. Watch the video I have posted in the previous post. The speaker has some valuable tips for performance improvements. Anyway, 100 Sprites is not very much if you are already using OpenGL... So may be you are right and the only solution is to target high end devices for your next project. 2010/4/6 MrChaz mrchazmob...@googlemail.com 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 next project I'd like a bit more. Maybe I'll just stop making games for 'old' hardware and concentrate on the Droid and N1. I can't say I like the idea of ignoring half the market :( -- 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.comandroid-developers%2bunsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en To unsubscribe, reply using remove me as the subject. -- 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
Re: [android-developers] Re: Performance comparison NDK vs SDK
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 this isolated one has very little value.
Try some integer functions instead of doubles. The C version will be a lot
faster than the Java version (I estimate 10 timers faster than Java)
Enable hardware support for floats with a compiler switch. Again the C
version will be much faster again.
Try it with 32 Bit unsigned integers. The Java version will be a lot slower,
because there are no unsigned integers in Java...
Alloc (and free) lots of memory. The Java version will win (hopefully!).
...
2010/4/8 Menion menion.as...@gmail.com
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 (int i = 0; i 100; i++) {
result += Math.pow(Math.cos(x), 2.0);
result -= Math.pow(Math.sin(x), 2.0);
result = Math.log(result);
result = Math.exp(result);
}
return result;
}
and C code
JNIEXPORT jdouble JNICALL
Java_menion_android_jnitest_Main_doClickAction04C
(JNIEnv *env, jclass thiz) {
double x = 45.0 / (180.0 / M_PI);
double result = 0.5;
int i;
for (i = 0; i 100; i++) {
result += pow(cos(x), 2.0);
result -= pow(sin(x), 2.0);
result = log(result);
result = exp(result);
}
return result;
}
and the results?
Java: 5250ms
C : 1600ms
I then enabled experimental version of JIT compilator (in 2.1-r1
system) and new results
Java: 4700ms
C : 1600ms
so ... these are facts. I'm not really experienced with C, but this
seems for me as very objective test.
On Apr 7, 6:26 pm, Ralf Schneider li...@gestaltgeber.com wrote:
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
match.
But I don't have any hard numbers this is just an observation on a
specific
device.
Many have observed most devices are currently fill-rate-limited. So, if
you
have lots of overdraw it might be worth checking if you can reduce it.
2010/4/7 MrChaz mrchazmob...@googlemail.com
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 transparency so
I'm using ARGB_ for the texture atlas's.
--
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.comandroid-developers%2bunsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
To unsubscribe, reply using remove me as the subject.
--
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
Re: [android-developers] Re: Performance comparison NDK vs SDK
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 match. But I don't have any hard numbers this is just an observation on a specific device. Many have observed most devices are currently fill-rate-limited. So, if you have lots of overdraw it might be worth checking if you can reduce it. 2010/4/7 MrChaz mrchazmob...@googlemail.com 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 transparency so I'm using ARGB_ for the texture atlas's. -- 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 To unsubscribe, reply using remove me as the subject.
Re: [android-developers] Re: Performance comparison NDK vs SDK
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 be slower on some devices. Use texture atlases for smaller sprites - To avoid state changes in OpenGL Use VBOs Avoid textures with alpha channels on slower devices. Don't scale or rotate your sprites on slower devices. Slower devices often have a fast path for simple blitt operations. = Check if point sprites are available on the device. If yes, use them. Use 16 Bit (565) textures. Watch the video I have posted in the previous post. The speaker has some valuable tips for performance improvements. Anyway, 100 Sprites is not very much if you are already using OpenGL... So may be you are right and the only solution is to target high end devices for your next project. 2010/4/6 MrChaz mrchazmob...@googlemail.com 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 next project I'd like a bit more. Maybe I'll just stop making games for 'old' hardware and concentrate on the Droid and N1. I can't say I like the idea of ignoring half the market :( -- 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 To unsubscribe, reply using remove me as the subject.
