Hi all.

My mobile game for android runs pretty well on the vast majority of the devices that it's designed for (API 15+): the problem is that on some "very slow" devices it's unplayiable.

I would like to avoid those users to download the app from the store, or at least reduce the graphic effects on those devices.

(for example disable the particle system or the shadows ecc).

So I would like to have a method to retrive at runtime the device performance.

I was thinking about SDL_GetPerformanceFrequency, but this gives me information just about the processor.

There is a way that I can obtain information about the graphic cards?

And at a more high level, there is a way (maybe in the manifest file) to deny some devices that have slow hardware to download the game?

(because of course they will be very hungry to pay for a game that is unplayiable...)

Thank you all.

Leonardo

This is a tough one, you could limit it by GL version in the hopes that newer devices will support higher versions and also have much power but it doesn't guarantee much unfortunately.

e.g.

<uses-feature android:glEsVersion="0x00020000" android:required="true" />

Best bet is for you to offer simple options, low, medium, high and have the user decide (or you could monitor performance and offer the lower the graphics while playing).

This is a hard problem, and one of the reasons that more people make their games free on the Play Store than on Apple's app store. There's just so many devices out there it is effectively impossible to avoid selling your game to a customer who won't be able to play it.

One tool in the manifest to add to Nanoha's suggestion is the screen size: <supports-screens android:smallScreens="false" /> ditches tiny phones which are probably underpowered. But in general it's hard to do much in the manifest beyond OS version, screen size and GLES version.

At runtime, I assess device's graphics capabilities mainly by proxy, I look at information like:

* Number of CPU cores

* Amount of RAM

* Whether highp is supported in fragment shaders

* Whether GLES3 is supported

* Whether depth textures are supported

And I choose a graphics option based on that - I let the user override my choice.

I'm with Nanoha, your best bet is to offer different 'performance' settings or offer a way to control options that you may think would result in a lower performance. It also helps to have one of these devices on hand to test with as it gives you somewhat of a bottom-line. As its better to have fewer bells and whistles and still be able to run vs not being able to run at all. Also the issue you are facing is not specific to mobile devices, meaning if you ever written any application of significant complexity especially games, you will always have to worry about this unless you are only publishing to a single uniform device or range of devices.

thank you very much guys... very useful idea.

I will try to do my best.

Leonardo