G1/ADP1 is definitely fill bound. Here is a bit of code that works the G1 over. I have a Quake3 class game engine / level renderer done in all Java / OpenGL and OpenGL ES on Android. I've yet to update things to use VBOs, so it's all vertex arrays and there is massive curved surfaces which I don't do any minimization or LOD on yet and that is what really kills the level renderer especially w/ levels that have a lot of curved surfaces. You'll see some bullet firing / particle system w/ explosions and if one gets next to a wall and fire a ton w/ all the explosion particles frame rate will drop a lot due to being fill bound. Anyway.. here is a video of the engine right after I finished porting it w/ zero optimizations for OpenGL ES. The entire level file is approximately 16 megs and maxes out the G1. All the curved surface calculation which needs to be worked over takes ~2 minutes to load.
The general idea is that the G1/ADP1 should be able to handle a Quake3 class renderer at 30-45 FPS given that the level doesn't go overboard w/ curved surfaces then again I'm doing no reduction and they really are nicely curved. Anyway here is the video.. A little ghetto I know, but it gives you an idea of what an unoptimized for mobile game engine does on the G1. I'm actually just about to launch a bunch of the main content for an expansive tutorial series on OpenGL ES and Typhon (typhon.egrsoftware.com) and the final tutorials and release will be the Quake3 class game engine where I'll fully explain the innards. I'm also releasing all the code as MIT licensed and I did not look at a line of Quake code directly at least and did the majority of work before Q3 was open sourced, so it's original source, so it can be used freely for games and such. I'd really like to see games explode on Android! I also really can't wait to give it a good once over and update it as most of the engine is still 1.4 Java 5-6 years old and I can squeeze more performance out for sure. I'm rather curious to see the improvement when I switch to VBO alone. Now note it is almost a direct port of the desktop Java renderer and actually with the use of Typhon 95 % of the code is cross platform and there are only 14 classes and a scant amount of direct render loop code that is specific to Android/OpenGL ES (14 classes total including Activity and setup code; beyond Typhon). Regards... On Nov 10, 11:56 am, Patrick <[email protected]> wrote: > I can understand the texturing/filling takes power but could it really > be as bad as dragging it down to 2,5%? > Would be really great to get this number up to at least a steady FPS > with ~ 20000 polys / frame and I feel it should be possible > > ARM 11 Qualcomm MSM7200A 528 MHz with 256 MHz ARM9 2nd core, Hardware > 3D graphics support with up to 4 million 3D triangles per second, and > 133 million 3D textured pixels per second fill rate, OpenGL ES- > compliant 3D graphics > > 4 million 3D triangles per second > and 133 million 3D textured pixels per second fill rate > > Feels weird that there is no "real world" way to get even 10-15% of > that on the phones? > > On Nov 10, 8:17 pm, Robert Green <[email protected]> wrote: > > > Jni is not really a big factor in this. In my experience, if you use > > vbos, you're not nearly as triangle bound as you are fill bound. If > > you're only filling half the screen and you use vbos with no normals > > and no index, I imagine you could get up there with vert count. > > > Here's a little test to see where the texel unit has limits and > > optimizations... make a quad that's bigger than the viewport and > > texture it. Rotate it so that it faces the lookat directly, so that > > there is no skew or distortion. It will render very quickly. Now > > rotate it just a degree away from the lookat about any axis. You'll > > see the framerate drop significantly. > > > This shows that no matter how few or many triangles you have on > > screen, you will always be limited by the texture unit. > > > On Nov 10, 1:36 am, Patrick Årman <[email protected]> wrote: > > > > Ok so no where near the chips full potential then, sad to hear, did you > > > use > > > buffers and minimized glcalls? I'm guessing you used only Java and no > > > native > > > code? Though the JNI might be the bottleneck? > > > > On Nov 10, 2009 7:44 AM, "Jeremy Slade" <[email protected]> wrote: > > > > 4-5k polys per frame seems about right from my experience on a G1 > > > > On Nov 9, 1:42 pm, Patrick <[email protected]> wrote: > Well I've been > > > searching for this informa... > > > -- > > > 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]<android-developers%2Bunsubs > > > [email protected]> > > > For more options, visit this group > > > athttp://groups.google.com/group/android-developers?hl=en -- 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
