Wow, nice and informative reply, thank you! Couple of points from my side: (1) use glDrawTexfOES for sprite renderings, it is super fast (2) as of 1.6 you can use OpenGL in NDK, so you can do all rendering in native code (3) Armadillo Roll is completely implemented in native code, with a tiny wrapper of Java ontop
Dmitry On Dec 4, 12:39 pm, Robert Green <rbgrn....@gmail.com> wrote: > GLSurfaceView should, in theory, give you an ideal gl configuration > for that device... However in practical use, there are sometimes bugs > on certain devices and firmwares that don't produce the correct > configuration parameters and thus you'll get bad performance. > > The Droid is a little different than most Android phones because it > has a PowerVR SGX530 chip which is quite fast and likes a 24 bit depth > buffer, as opposed to the HTC Qualcomm phones that aren't quite so > fast and like a 16 bit depth buffer. Someone should correct me if I'm > wrong but if you use a GLSurfaceView, you will probably get the ideal > depth buffer size which will result in the best performance. > > Here's another performance consideration for the Droid: It has a high- > res screen. It may be faster to run the game in a compatibility mode > which ends up being 320x589 or as opposed to 480x854. > > As far as GL ES goes, you just need to get used to the arrays and > reduced feature set. VBOs tend to run pretty quick on most phones. > I've found that nearly all phones really hate lots of texture > switching. I've got a multitextured (lightmapped) world working for > my new game that's running 30-60FPS with only fog but no GL lights on > my G1. A small lightmap and everything linear makes that work. > > I also wrote a Quake 2 level (BSP) renderer recently but scrapped it > because it was taking too long to get the optimizations in to render > quickly. GLES doesn't like to render 1500 faces all as separate > DrawArrays calls. It's too much. I was about to work on batching > them up and atlasing the textures, which would have worked fine but it > was turning into a big pain so I switched over to a simpler system and > will be just using an octree to partition the faces and portals if I > need to speed things up, though it seems to be fine with just having a > big VBO of the world so long as I keep the textures small and use > nearest magnification. > > My advice? Keep your poly count low, use the smallest textures you > can get away with, write your truly performance critical code in C > using the NDK (it'll be 10-20 times faster in my experience), > carefully tune your texturing (you'll always be fill-bound with these > chips) and deliver large batches to the GPU (don't try drawing face-by- > face on anything!). > > Watch out for texture compression formats because while Droid uses > PVRTC, every other phone uses ATITC. If you want to have the fastest > texturing possible, you'll need to compress to both formats for your > game and upload based on the extension. Otherwise just load textures > in as RGB_565 bitmaps like pretty much every game does. > > If you look at demos like Armadillo roll, it'll show you what you can > do with the environment but everything those guys did was using ATITC > textures so it runs a little better than if you use bitmaps. There's > a good chance they wrote a bunch of that natively as well, though it > was out well before the NDK (but that didn't stop several people from > building native libs). I'm getting similar lightmap performance to > armadillo roll in the new game and the only native code I'm using > right now is to interpolate verts. I'll probably move collisions into > native space as well. > > On Dec 3, 10:13 pm, Ian Dunlop <iandaviddun...@gmail.com> wrote: > > > Can anyone offer any advice? > > > Thanks. > > > On Dec 2, 3:26 am, Ian Dunlop <iandaviddun...@gmail.com> wrote: > > > > I'm experienced with openGL but not Android. I just started. I have > > > some spinning cubes running on a Droid and I'm barely getting 30FPS. > > > > Should I be using GLSurfaceView to get the bestperformanceor is > > > there a better way? > > > > Cheers, > > > Ian Dunlop > > > oeFun, Inc. -- 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
