Since we're talking visual effects here, you could go by the available OpenGL ES version. The OpenGL ES Xcode template has an example that tries to create an ES2 context (kEAGLRenderingAPIOpenGLES2), and falls back to ES1 if you're not on hardware that supports ES2 (PowerVR SGX, the GPU in the iPhone 3GS, third-generation iPod Touch, and iPad).

Another way you can do it is to compile a universal binary with different code in armv7 than armv6, and put your fancier graphics in the armv7 code. All of the "fast" devices run armv7 and the "slow" devices don't, so the appropriate one will be launched when your app starts.

ThemsAllTook Wrote:Since we're talking visual effects here, you could go by the available OpenGL ES version. The OpenGL ES Xcode template has an example that tries to create an ES2 context (kEAGLRenderingAPIOpenGLES2), and falls back to ES1 if you're not on hardware that supports ES2 (PowerVR SGX, the GPU in the iPhone 3GS, third-generation iPod Touch, and iPad).

Another way you can do it is to compile a universal binary with different code in armv7 than armv6, and put your fancier graphics in the armv7 code. All of the "fast" devices run armv7 and the "slow" devices don't, so the appropriate one will be launched when your app starts.

I tend to check for the number of texture units .... most people don't realize it but even when running a common GLES 1.x path for all devices, there are vast differences between various devices in terms of GLES capabilities.

Yup, it would be better to, rather than simply query which version of hardware you're running on (you'll have to upgrade your app every time new hardware comes out), instead do some other test, like ThemsAllTook or warmi suggest.

Well, I was going to do something where I check the hardware, and if it's iPhone, iPhone 3G, or iPod Touch 1G; assume it's slow; everything else (including any new devices to be introduced) assume it's fast.

Maybe it makes more sense to test for OpenGL ES 2.0 though. If that means the more powerful GPU is present, and I assume the GPU will affect performance a lot more that the CPU speed...

I wasn't aware that they used different version of the ARM chip, on different devices. Does this mean, I'm creating universal binaries anyway (with two lots of executable code, one for each version of the CPU)?

On the topic, do many people find the need to code directly in ARM (or Thumb?) asm on iPhone? and can we do that in Xcode?

Jamie W Wrote:Well, I was going to do something where I check the hardware, and if it's iPhone, iPhone 3G, or iPod Touch 1G; assume it's slow; everything else (including any new devices to be introduced) assume it's fast.

That's what I do (assuming "fast" means 2nd Gen iPod touch or better). Since there's no way to differentiate the 2nd gen touch from the 1st gen devices other than clock speed this seemed like a reasonable approach. I guess Apple could turn around and release a newer but slower device but if that happens I'm giving up.

Jamie W Wrote:Does this mean, I'm creating universal binaries anyway (with two lots of executable code, one for each version of the CPU)?

If you're targeting OS 3 or above you can build a UB by setting "Architectures" to "Optimized (armv6 armv7)" in the build settings. For games, you'll usually want to turn off Thumb for armv6, but leave it on for armv7. You can do this in the build settings by adding conditional settings to "Compile for Thumb".