Hmm, for less texture data, but keeping some alpha, there are also the options of: RGBA_5551; PowerVR Texture Compression (PVRTC); and reducing the resolution of the texture, but still filling the screen with it. Not all phones support PVRTC, however, so you have to check for support and have a more compatible format ready as a fallback with that option. Never tried any of the above myself. Maybe testing with a 1x1 size texture to see the best speed for minimal texture data first would be a good idea.
On Feb 1, 7:10 am, Mario Zechner <badlogicga...@gmail.com> wrote: > i'm working a prototype game that has a very similar setup to yours. I > have a 2048x2048 big background texture which i load in 32-bit argb > mode (i have yet to discover what format to use for 16-bit rgb 565, > png doesn't support it, didn't care yet though). I split up this big > thing into 256x256 pixel chunks for visibility culling so i only draw > those chunks on screen. Additionally i have a second layer of 256x256 > chunks in 16-bit rgba 4444 for which i also do culling. i have up to > 1000 sprites on the screen, those are 12by12 pixels big. The sprites > each consist of 2 triangles. All sprite triangles i write into a > dynamic VBO each frame which is extremely fast to my surprise (write > to temporary float array then pass that to the VBO). Everything is > rendered in ortho mode using pixel perfect projection except for the > sprites which use a lower mipmap level due to me still not sure on how > big they should get. The two layers of background use linear filtering > for both min and mag. > > On my droid i get between 35-45fps, rendering and simulating the scene > (and the simulation of the sprites takes quiet some time as it does > pixel perfect collisions on a collision map of 2048x2048 bytes). On my > hero i can get 60fps with the sprites turned of. The MSM7200 seems to > have an optimization for axis aligned triangles in there that makes it > blazingly fast. The droid gets around 50fps if i turn the sprites off. > Note that i use 32-bit argb for the first layer which waste a lot of > bandwidth and memory. > > The problem on the droid is sampling the texture. The portions of your > quad that are not visible will of course not fetch any texels, try the > following to see that effect: > > - let the quad fill the whole screen > - the the quad fill 3/4 of the screen > - let the quad fill 1/2 of the screen > > you only have 4 vertices to be transformed so you are clearly not > transform bound. However, as you fill less and less space on the > screen your framerate increases indicating that you are fillbound. For > an ortho setup mipmapping won't help you as all texels will be fetched > from the original size level 0. Linear filtering will also scrap some > fps as you sample 4 textels for each pixel on screen. Nearest > filtering might be the best option and will look as good as mipmapping > (which is essentially linear filtering in your case) or linear filter > as your quad is pixel perfect and screen aligned. Another way to > reduce the texel fetch pressure is to use lower bit-depth textures, 16- > bit argb4444 or rgb565 as less bytes have to go over the bus (if they > do). There is simply no way on the droid to get around the fill rate > issue. Switching to compatibility density mode which is around 540x320 > pixels (from the top of my head this figure is for sure not correct) > will get you another 2-3fps, but compared to the native screen res it > looks worse and is not worth the extra fps. From this it is clear that > the problem is probably not related to actually filling the > framebuffer but only to fetching texels. > > To summarize: > - use mipmapping for scaled down quads, nearest filtering for pixel > perfect screen aligned quads > - use 16-bit argb/rgb textures instead of 32-bit argb textures > > That's all you can do. The PowerVR in the droid is a beast and will > happily transform as many vertices as you throw at it, i have yet to > encounter an issue with that rendering stage. Fetching texels is > expensive though so avoid it at all cost :) > > On 1 Feb., 07:22, Robert Green <rbgrn....@gmail.com> wrote: > > > The texture memory copy / fill bottleneck has been fairly consistent > > across all chips so far. It's more pronounced on the MSM7200 chips > > but is clearly still there. The good news is that while you might not > > be able to get your upper FPS that you were hoping for, you probably > > will be able to get a fairly good and stable framerate with a far more > > complex scene. I was surprised at how no matter what I did, I > > couldn't get my environment rendering over 40FPS with low res > > textures, mipmap/nearest and no special effects, yet with a full scene > > of monsters, HUD, multitextured environment, weapons, explosions, > > fire, etc running with large textures with trilinear filtering on, I > > got 30FPS. Crazy, huh? I think there is a LOT going on in terms of > > optimizations and I wouldn't necessarily expect slowdown to be linear. > > > On Jan 31, 10:14 pm, Federico Carnales <fedecarna...@gmail.com> wrote: > > > > Hi Lance, > > > > I doubt that's going to change much, I'm not doing any complex > > > geometry or anything. Just to make sure, I removed the glClear, > > > glActiveTexture, and glBindTexture calls from the draw method, and the > > > performance is exactly the same. > > > > The performance hit seems to come from using heavy textures, not from > > > excessive GL calls or state changes. > > > > Thanks, > > > > Federico > > > > On Feb 1, 12:52 am, Lance Nanek <lna...@gmail.com> wrote: > > > > > If the final is only a non-transparent background and a couple > > > > sprites, you may actually get it to perform slightly better than the > > > > benchmark, not worse. The benchmark has a lot of extra stuff getting > > > > called every frame. With a non-transparent background and drawing in > > > > order, glClear isn't needed. If you only ever use the first texture > > > > unit then then glActiveTexture call isn't needed. If all your > > > > textures, the background and sprites, fit in one atlas texture then > > > > the glBindTexture call isn't needed. If you use shared buffers then > > > > the glVertexPointer and glTexCoordPointer calls aren't needed. All > > > > those could be moved to only be called once instead of every frame if > > > > those conditions are met. > > > > > If you switch from triangle strips to triangles you can easily draw > > > > the background and multiple sprites in a single draw command as well. > > > > Degenerate triangles for connecting things might even work in triangle > > > > strip mode. So the number of draw commands may not even go up. > > > > > On Jan 31, 7:13 pm, Federico Carnales <fedecarna...@gmail.com> wrote: > > > > > > Correction: using SurfaceView to draw the background image does indeed > > > > > give me 60fps. And when adding the "sprites" on top of it, the > > > > > performance is not 60fps anymore, but still better than GLSurfaceView. > > > > > > Federico > > > > > > On Jan 31, 9:09 pm, Federico Carnales <fedecarna...@gmail.com> wrote: > > > > > > > Did the test you requested, RGB_565, mipmapped - nearest. Got 18ms/ > > > > > > frame. Better, but still unacceptable as this would only be the > > > > > > background image. The final app uses several sprites with alpha on > > > > > > top > > > > > > of the background, so the performance drops significantly. > > > > > > > What's funny is that I'm getting better performance with a regular > > > > > > SurfaceView and CPU rendering. Not 60fps, but better than OpenGL's > > > > > > performance. Something is seriously wrong there. > > > > > > > Regards, > > > > > > > Federico > > > > > > > On Jan 31, 7:37 pm, Robert Green <rbgrn....@gmail.com> wrote: > > > > > > > > I'd test it on my Droid but my graphics guy has it right now. I > > > > > > > can > > > > > > > try it out in a week or two when I get it back from him. > > > > > > > > I think you may be video memory bound in some form. It sounds > > > > > > > like > > > > > > > it's sheer bytes slowing you down. Can you load the texture as > > > > > > > RGB_565 mipmapped - nearest and give me a number? What about > > > > > > > using > > > > > > > glDrawTexiOES? I didn't realize you were trying to draw a 32 bit > > > > > > > full > > > > > > > screen image. I pretty much only draw 16 bit bitmaps when I can > > > > > > > unless it's an effect or control and I need the alpha for that. > > > > > > > > On Jan 31, 12:52 pm, Federico Carnales <fedecarna...@gmail.com> > > > > > > > wrote: > > > > > > > > > I've created a small sample class to show the problem: > > > > > > > > >http://fedecarnales.googlepages.com/TextureTest.java > > > > > > > > > It simply creates a full screen GLSurfaceView, sets up an > > > > > > > > orthogonal > > > > > > > > 2D matrix, creates a 1024x1024 texture from the default icon > > > > > > > > file, and > > > > > > > > displays it as a 480x854 quad on screen. The time-per-frame is > > > > > > > > measured by counting the time it takes to render 100 frames, > > > > > > > > then > > > > > > > > dividing it by 100 and writing it to the Logcat. > > > > > > > > > On my Motorola Milestone, it's taking 34ms per frame, which is > > > > > > > > outrageous. If I enable mipmapping it goes down to 20ms per > > > > > > > > frame, > > > > > > > > which seems to indicate that the problem is directly related to > > > > > > > > the > > > > > > > > texture size or dimensions. > > > > > > > > > What's interesting is that if you convert the bitmap to > > > > > > > > ARGB_4444 > > > > > > > > before loading it as a texture, the rendering time goes down > > > > > > > > from 34ms > > > > > > > > to 24ms, which to me seems to show that it's a problem related > > > > > > > > to the > > > > > > > > size of the texture in bytes rather than the dimensions > > > > > > > > (although the > > > > > > > > dimensions will obviously change the byte size). > > > > > > > > > Regards, > > > > > > > > > Federico > > > > > > > > > On Jan 31, 2:09 pm, Robert Green <rbgrn....@gmail.com> wrote: > > > > > > > > > > Federico - are you using GLSurfaceView or did you init EGL > > > > > > > > > yourself? > > > > > > > > > If you initialized it yourself, did you check to make sure > > > > > > > > > the config > > > > > > > > > gave you 24 bits of depth and not 16? That would be one > > > > > > > > > thing to > > > > > > > > > cause the slowdown. > > > > > > > > > > I usually get 40FPS on a Droid full-screen (not with a big > > > > > > > > > quad but > > > > > > > > > with a 3D scene) so something is certainly up with your code. > > > > > > > > > > On Jan 31, 10:58 am, Lance Nanek <lna...@gmail.com> wrote: > > > > > > > > > > > I don't have a Droid to test on, but if you haven't tried > > > > > > > > > > it already, > > > > > > > > > > it might be worth dropping the various texture settings > > > > > > > > > > down to their > > > > > > > > > > fastest/lowest quality and enabling mipmaps to check if > > > > > > > > > > that's where > > > > > > > > > > the problem is. Something like this: > > > > > > > > > > > gl.glHint(GL10.GL_PERSPECTIVE_CORRECTION_HINT, > > > > > > > > > > GL10.GL_FASTEST); > > ... > > 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 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
