To expand upon what Frogblast said, the template code defines two classes: ES1Renderer
and ES2Renderer
. The EAGLView
class first tries to create an ES2Renderer
instance, but if that fails it creates an ES1Renderer
. The failure comes about if the ES2Renderer
is unable to set up an OpenGL ES 2.0 context using the following code:
context = [[EAGLContext alloc] initWithAPI:kEAGLRenderingAPIOpenGLES2];
if (!context || ![EAGLContext setCurrentContext:context] || ![self loadShaders])
{
[self release];
return nil;
}
If a device supports OpenGL ES 2.0, this should succeed. If not, the application falls back to the ES1Renderer
OpenGL ES 1.1 renderer.
The reason the application has two different rendering classes is that OpenGL ES 1.1 and 2.0 have different and incompatible rendering pipelines. OpenGL ES 2.0 lets you create programmable shaders for some stunning effects, but it can be more difficult to use for simple tasks than OpenGL ES 1.1.
Many people add fallbacks to their application if they use OpenGL ES 2.0, because only the iPhone 3G S and later devices have support for this never API. However, if you are developing an iPad-only application, you can assume it will have 2.0 support. You could also restrict your application to running on devices with this capability by adding the opengles-2
key to the UIRequiredDeviceCapabilities
in your Info.plist.
You can use OpenGL ES 1.1 just fine on the newer devices, so if you want to disable the 2.0 rendering path you can have the EAGLView in the template ignore the ES2Renderer
class and just work with the ES1Renderer
. You could also take the OpenGL ES code from the ES1Renderer
and just place it within the EAGLView.