Very insightful post. It takes a lot of time to do all of those tests and make all of those observations. I feel like we should assemble a little knowledgebase containing all of this information structured into something cohesive that developers can use. I'd be happy to host it on http://www.batterypoweredgames.com or http://www.rbgrn.net. Perhaps I'll take a first shot at it using everything here and then take contributions to polish it up.
I have to comment on the jerkiness that you were seeing, though. I'm not saying that you don't know what you're doing but I'd be curious to see your code on that. I do all of my physics and animations time- based and everything for me is smooth as silk. If you wouldn't mind posting the bit that calculates the new rotation, I'd like to have a look at it. On Jan 26, 12:44 pm, Mario Zechner <[email protected]> wrote: > I can share your experience on the Droid/Nexus One. Interestingly the > HTC Hero performs better than the droid on the scene above. > > As for the background: yes, depth tests/writes and lighting are > disabled, only alpha testing is enabled (which is a bit faster than > alpha blending). A single fullscreen quad performs as you said with > 60fps on MSM7200 hardware. That's probably the optimization in the > chip. I was however suspecting that this optimization would also kick > in for the tiles of the scene above but it doesn't seem so. Never the > less i get a framerate between 40 and 50fps on the hero, while the > droid struggles at ~40fps now. > > Lowering the texture resolution helped on the PowerVR as well as on > the MSM7200, around 5fps increase. Setting the filters to near and > linear yields similar relative results to yours on the PowerVR. The > effect with nearest filtering is much more pronounced on the MSM7200. > Which should be expected as the PowerVR has a way higher nominal fill- > rate. However, only getting not even 10% of the fill-rate kinda sucks. > I don't suspect that it's a bandwidth problem in the CPU->GPU > direction as the textures should be stored on the graphics chip > itself. I might be wrong though, that's how it works on the desktop at > least. If the textures are indeed stored in system RAM than that might > explain the poor sampling rates. > > The triangle cap at 2000 is something i tried to achieve already. It > helped a bit on the MSM7200, no real difference on the PowerVR. I > think i read somewhere that the vertex transforms are performed on the > CPU on G1 hardware. The PowerVR should have it's own FPU or ALU. I > have all my VBOs in dynamic mode at the moment, i will try to use > static ones and see if that helps. There's also no difference between > using fixed and floating point vertex attributes from some > microbenchmarks i did (small untextured triangles, depth buffer off, > lighting on, no alpha blending/testing). The bottle neck in my case is > not the transformation and lighting though as far as i can tell, at > least not on the PowerVR. > > Here's another interesting case study. I wrote a tutorial on Android > Game Development for the german Android community over > athttp://www.androidpit.de. > You can find it > athttp://www.androidpit.de/android/de/de/wiki/view/Spieleentwicklung_101. > The end result of the tutorial is a small Space Invaders clone. The > scene is pretty simple: > > http://www.androidpit.de/android/de/de/wiki/view/Datei:gameworld.png > > There's a total of 4x8=32 saucers displayed, each using a mesh with > ~50 triangles, unindexed. That's 1600 triangles. The blocks are also > rendered seperately, there's 3x5=15 of them each having 12 triangles > that's another 180 triangles. The ship in the front has another 50 > triangles. The background is not moving and a fullscreen quad rendered > with ortho projection, depth test/write off, lighting off, alpha > blending/testing off and min/mag filter set to mipmap-nearest and > linear. The saucers, blocks and ship are rendered with depth test/ > write on, lighting on, and for the blocks alpha blending is also on. > The saucers share one texture which is bound once for rendering all of > them, min/mag filter mipmap-nearest and linear. The same for the ship. > The text is a couple of quads in a single VBO with a glyph texture, > ortho projection, and nearest for both filters. All meshes are dynamic > VBOs. For each object i do a push and pop of the model-view matrix, > one glRotatef and glTranslatef call per object (saucer, block, ship). > That's a shitload of JNI calls. > > Now, on the droid i get between 47-50fps with the above setting. My > Hero can do 32fps max when all saucers are on screen. The more saucers > you kill, and thus the less saucers are on the screen the better the > framerate gets on the Hero. With one saucer left it's roughly > 55-58fps. I got a little suspicious and disabled lighting on the Hero. > Instant 60fps. So i suspect the rumor that T&L is done on the CPU is > true. Interestingly the matrix operations are not a problem. I can > happily draw 100 objects the way i described above and still get > 100fps (good for my RTS i'm working on :p). Lighting on the MSM7200 > seems to be a no go. And the worst part is that i can't precalculate > the vertex colors and thus the lighting for rotating objects. Sucks > big times. You can find the full source code for the Space Invaders > clone athttp://code.google.com/p/android-gamedev/. > > Now the performance on the Droid is also a little strange. So seeing > that turning of the lighting didn't affect the framerate on the droid > i suspected the fill-rate to be the sucker. I turned off rendering the > background image, and tada instant 60fps again. This is really > troublesome, especially since a friend of mine, an iphone game dev, > has no problem achieving 60fps rendering the above scene on his 3GS. > So maybe the bandwidth of the RAM is really the culprit here as you > stated. > > Another problem in that regard is that time based movement depends on > more or less steady framerates in order to not feel jerky. Well, try > this herehttp://file-pasta.com/file/104641723/spaceracer-android.apk. > Control the thrusters by any key/trackball except the home, back, > search and menu key, controll the rotation of the ship by the onscreen > buttons. If you are as sensible as me you will see a bit of stuttering > when the ship moves in a single direction and more stuttering when the > ship rotates. I draw the ship in total white so the effect is more > pronounced. Now all the calculations are based on the delta time > between frames. It does not matter wheter i put the physics in a > seperate thread with double buffering as proposed > athttp://replicaisland.blogspot.com/2009/10/rendering-with-two-threads.... > or do them in the GL rendering thread, the stuttering is always there. > It's not the first time that i write a game using time-based movement, > hell i can't even count the number of times i did that in the past > already. On any Android devices i tested is the stuttering is there, > leaving me with the suspicion that the multi-tasking is taking it's > toll. On further inspection the delta times vary between 16 and 30 > milliseconds which is the cause of the stuttering. > > I love Android and i was used to working with shitty hardware in my > DOS days. But some things just make me go crazy. Maybe we can use this > discussion thread to share best practices concerning fill-rate and > other issues. > > On 25 Jan., 19:55, Robert Green <[email protected]> wrote: > > > > > Seems like no matter what I do with the Droid/Nexus One, I don't get > > much over 40FPS. I'm multitexturing and drawing a full screen level > > with HUD on top. If I drop the texture resolutions down to crap and > > use all nearest neighbor filtering, I get about 40FPS. If I crank the > > texture resolutions (all 1K) and pop it up to trilinear filtering, I > > get 30-32FPS. G1 is more extreme - 35FPS on all low/nearest, 7FPS on > > high/trilinear. It seems then that most of these chips (MSM7200, PVR > > SGX530, Snapdragon) are all fill-bound in the same way. Perhaps it's > > a memory bandwidth issue of some sort. > > > Are you rendering your background in an orthographic projection with > > the obvious stuff like lights, depth check and blend shut off? That > > should go really fast - much faster than what you're getting. I > > remember getting 60FPS on both the G1 and Droid rendering a full > > screen quad orthographically. > > > BTW - I don't let my scenes get much over 2000 triangles. The MSM7200 > > seems to start to get vert processing slow-down around there. The SGX > > and Snapdragon don't seem to mind it. I'd be comfortable pushing > > those up to 10k triangles. Static VBOs do help a lot with the memory > > bottleneck. Since I can't use a vertex shader to do mesh animations, > > I can't use a static vbo on those but I keep the vert count super low > > on my animated characters so performance isn't too bad. > > > To be honest, my biggest performance problem is simply the touch slow- > > down issue on Android 1.5/1.6. > > > On Jan 24, 7:44 pm, Mario Zechner <[email protected]> wrote: > > > > Hi, > > > > i'm currently writting a small game that uses a tile based approach to > > > render the background. Additionally i want to zoom in and out so using > > > the 2D texture blit extension is out of the window. > > > > The tile map is split up into different cells i use for frustum > > > culling, similar to a quadtree but with fixed size. I really only > > > render what can be seen from the camera (and a bit outside the borders > > > of the view). Here's an image that should give you an idea: > > > >http://file-pasta.com/file/0/device.png > > > > Each tile is mapped to a 32x32 region in a texture atlas of size > > > 256x256. The texture minification filter is set to mipmap-nearest, the > > > magnification filter is set to linear. At the zoom level above the > > > mipmap filter kicks in which should lower the pressure during > > > sampling. > > > > The mesh for the scene above is actually several meshes (here 4, one > > > for each partition) each containing 8x8 tiles, using 2 triangles per > > > tile that makes 8x8x6=384 vertices. That's 384x4=1536 vertices to be > > > transformed, which the powervr sgx 530 in my trusty milestone should > > > handle easily. The meshes are stored in static VBOs of course. > > > > The following settings are used for the above scene: depth test > > > disabled, dithering disabled, lighting disabled, texturing enabled, > > > blending enabled. i even bound the texture only once in the setup code > > > for the screenshot above. > > > > I get 35fps on my milestone in native resolution, and 36fps in > > > compatibility mode. If i don't fill up the full screen with tiles but > > > only half of the screen i get 50fps. again, all i do is: > > > > bind texture atlas > > > > render partition 1 > > > render partition 2 > > > render partition 3 > > > render partition 4 > > > > where each partition consists of 8x8x2=96 lousy triangles. > > > > According to the specs of the chip it's capable of roughly 200mp/s. > > > The scene above has 8x8x32x32x4=262144 > > ... > > read more » -- 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
