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.
