And yes, the touch slowdown also sucks a lot. I use 30ms for the racer i linked to above and it is still noticeable.
On 26 Jan., 19:44, Mario Zechner <badlogicga...@gmail.com> 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 <rbgrn....@gmail.com> 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 <badlogicga...@gmail.com> 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 > > ... > > Erfahren Sie mehr » -- 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
