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 <[email protected]> wrote: > Can anyone offer any advice? > > Thanks. > > On Dec 2, 3:26 am, Ian Dunlop <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
