Robert, your right. Accessing the gl extensions at runtime will tell us what effects we can use. But I Wa thinking that even if all the extensions I want are available, maybe my program uses them all very heavily and I want to limit that based on the class (horsepower) of the gpu. I have not done much OpenGL programming so maybe this is not really a case that comes up.
On Dec 18, 5:43 pm, Robert Green <[email protected]> wrote: > Shaun, > > Most "effects" are things that you program so to enable/disable them, > you have to do it in your own code. Most other primitive features > like fog, lights and texture filtering are all controllable in GL, so > you wouldn't need any additional configuration options for your GPU. > > I'm comfortable saying that all we need is a relative class of GPUs > that basically indicates how much raw power they have. I'm trying to > make my new game scale across all phones but I'm having a problem on > the ones with software renderer. No matter how far I drop the res of > my textures or how basic I make things, I can't get over 10 fps on > it. That's where I'd like to draw the line and say that my game just > can't be installed on it. I know I can never provide a good > experience on it, and thus the basic class system. > > On Dec 18, 2:15 pm, shaun <[email protected]> wrote: > > > > > And to be able to access the device's setting for GPU class (or > > whatever it ends up being) programmatically at runtime if we want to > > disable/enable features/effects based upon its value. > > > On Dec 18, 3:12 pm, shaun <[email protected]> wrote: > > > > I think Robert Green is on the right track. We need something like > > > this now! > > > > On Dec 18, 2:34 pm, Robert Green <[email protected]> wrote: > > > > > I'd really like to see a GPU Class enumeration starting with the > > > > software renderer. > > > > > android:gpuClass="integer" > > > > > class 0 = software renderer > > > > class 1 = MSM7200 series > > > > class 2 = PowerVR SGX series > > > > class 3 = Some faster, more powerful GPU > > > > etc... > > > > > This way, we could specify that a game only works on class-2 and above > > > > hardware. It would make it MUCH easier for us to build high-quality > > > > games targeted at "gamer" phones. > > > > > This in conjunction with a GL ES version would be perfect, however I > > > > believe there will be some overlap. My gut says that using the > > > > proposed class system, one would expect class 2 and above GPUs to > > > > support OpenGL ES 2.0. Perhaps in the future some class 5 GPUs will > > > > support 2.1 or 3.0 or whatever comes down the pipeline. > > > > > On Dec 18, 4:05 am, Hexage <[email protected]> wrote: > > > > > > There is growing list of upcoming devices (HTC Tattoo, HTC Legend, > > > > > MOTO MT710, etc.) without hardware accelerated OpenGL. Basically all > > > > > devices based on a low-end chip (Qualcomm MSM72xx, Marvell PXA310) > > > > > will not feature GPU. However many games rely on a hardware > > > > > accelerated OpenGL for lag-free rendering. > > > > > > Currently, we can use: > > > > > > <uses-feature android:glEsVersion="integer" /> > > > > > > to specify the GLES version needed by the application. I assume that > > > > > this requirement will be satisfied with the Android PixelFlinger (the > > > > > software renderer) which is not what we want. Is there any way to > > > > > specify a hardware accelerated OpenGL as a requirement in the > > > > > manifest? > > > > > > Something like this would be great: > > > > > > <uses-feature android:name="android.hardware.gpu" /> > > > > > > Thanks, > > > > > David- Hide quoted text - > > > > > - Show quoted text -- 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
