Thanks for the nodpi tip... I do have a followup question though. To control performance, I would like to be able to tell android "no matter what the phones native resolution is, if it is bigger than X, could you please lie to me, as in api 3, and make it closer to X, but don't just render me as a postage stamp with black bars, but fill the screen with me?"
Something like "I would like the height no greater than 320ish" and it would pick something close to that, then tell me a height and width which had an aspect ratio matching the actual screen.. I would render to that height and width, and android would fill the screen... All with the assumption that that would be faster than my rendering to the full screen would be. (my fps took a definite hit going from api 3 to api 4, and I *assssssssssume* that is because the size of the GL surface increased from the "it's about 480x320" lie to the "it's exactly 857x480" truth.) I messed with the android:large-screens="false" sorts of things in the manifest, but none of them seemed to do what I was looking for. I'm open to any other tips for speeding up GL. But first I need to add some stats to see just how many triangles I am rendering overall at the moment, maybe it's more than I realize. I have some fairly aggressive Level of Detail code, so I don't expect it to be much... I think I make fewer than 10 calls to drawPrimitives (grouping my triangles into as few shipments as possible, as it were). I'm cramming a zillion things into each texture (uv subrectangles) I was getting 30fps in api 3, and now seem almost half of that. - Dan On Jun 4, 1:43 pm, Tom Gibara <[email protected]> wrote: > I recall getting bitten by this same bug a while ago when I switch an app > out of "density-compatibility scaling". > > One thing you may need to watch out for is a bug in Android 1.5 - it mangles > the dimensions of images in the drawable-nodpi directory iirc. > > There's a bit of code you might find useful here: > > http://blog.tomgibara.com/post/190539066/android-unscaled-bitmaps > > -- > Tom Gibara > email: [email protected] > web:http://www.tomgibara.com > blog:http://blog.tomgibara.com > twitter: tomgibara > > On 4 June 2010 17:47, Samsyn <[email protected]> wrote: > > > > > Lance, (and everyone) > > > Thank you so much! That was exactly it. All I had to do was rename > > my drawables folder to drawables-nodpi (and I did a full rebuild just > > to be nice) and now everything is back to normal, with api 4 in place. > > > Of course, now I have to decide if I want to support higher rez > > screens at the expense of frame rate or not. It's so PRETTY, but it's > > at least 50% slower. :) > > > Again, I was really pulling my hair out on this. Of course it might > > have been NICE if the GL Error Check actually mentioned it didn't feel > > the texture was a power of two. I, of course, just knew that it was, > > so I never logged a getWidth() on it. It's still a little odd that > > some textures were happier than others, but I imagine that is > > something to do with which wrong-sized-texture stepped on the memory > > of which other. :-) > > > Once again, thank you! > > > - Dan > > > On Jun 4, 8:27 am, Lance Nanek <[email protected]> wrote: > > > If I take a default API level 3 app, load the icon using > > > BitmapFactory.decodeResource, and check Bitmap#getWidth and > > > Bitmap#getHeight, then I get the values of 48 on the Droid. Now if I > > > set android:minSdkVersion to 4 or higher in the manifest, then I get > > > the values of 72. This is because changing the API level changes the > > > default values for the screens supported: > >http://developer.android.com/guide/topics/manifest/supports-screens-e... > > > > It takes the app out of compatibility mode, where Android reports a > > > smaller screen resolution than actually exists, and it starts scaling > > > up resources from directories like the drawable directory, which is > > > considered medium density when there is no density specifier, not high > > > density. > > > > So anyway, depending on how you are storing and loading the images you > > > are using for your textures, changing the API level may be causing > > > Android to resize them. Textures have to have power of 2 size > > > dimensions, so this resize can make an image that can be used as a > > > texture into an image that can't be used. It's pretty easy to prevent > > > the resizing, there are previous threads on that. > > > > On Jun 4, 3:35 am, Samsyn <[email protected]> wrote: > > > > > and yes, if I regress to api 3, the problem goes away, but apis 4 and > > > > 5 both have the problem.- Hide quoted text - > > > > - Show quoted text - > > > -- > > 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 at > >http://groups.google.com/group/android-developers?hl=en- Hide quoted text - > > - Show quoted text - -- 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
