Posts RSS Comments RSS Digg Technorati Blinklist Furl reddit 66 Posts and Comments till now
This wordpress theme is downloaded from wordpress themes website.

Platforms, platform versions, API versions, supported features, OpenGL ES 2.0 & 3.0

Background – SDL2, C++, Graphics API’s, Platforms, Devices says: Simple DirectMedia Layer is a cross-platform development library designed to provide low level access to audio, keyboard, mouse, joystick, and graphics hardware via OpenGL and Direct3D. It is used by video playback software, emulators, and popular games…

SDL2 can help with cross-platform development using OpenGL (OpenGL ES, DirectX), such as setting up a cross-platform context, and it’s one path to enable you to share C++ code across the multiple platforms.  I started from the sample project, which gives you a build setup with wrappers for each platform.  For Android, I’m not writing OpenGL ES directly in Java JDK – rather the JDK calls to my cross-platform C++ code that is compiled with Android NDK.  Similarly, my iOS project shares the same C++ code base (ie compile source as Objective-C++ instead of as Objective-C).

Since Dec 2005 I’ve worked on a GPU model simulation.  From the perspective of writing GPU models, the GPU API’s (OpenGL, OpenGL ES, DirectX) may seem high level.  But from the perspective of applications software (or middleware), using these APIs is the lowest layer you’d write.  Anything lower and you’d be writing the API’s or the associated GPU drivers.  Also, starting from scratch (or near scratch) is different than modifying an existing code base.

So my SDL2 setup is not comparable to using middleware or a game engine (in terms of the layers, it’s closer to writing one).  SDL2 just makes it a little easier to setup a cross-platform C++ code base that accesses the low level API’s (OpenGL, OpenGL ES, DirectX) to run on multiple operating systems (Windows, Linux Ubuntu, Mac OS X, Android, iOS, etc).

Even if you only develop GPU software for one operating system, you have to face the issue of API versions and GPU hardware features (supported by GPU & its driver).  For example, on Windows you might decide to use only DirectX 11, and only worry about Windows 7+ with GPU’s that support DirectX 11.

Android API versions & device support

Or on Android, you might decide to use OpenGL ES 3.0, or OpenGL ES 2.0 and check extensions for newer features (such as VAO).  On Android, you’d also have to decide what Android API level (which correlates to support on Android Platform versions).  Of course you could have multiple builds (and corresponding code paths with #ifdef’s) for more than one Android API level – for example, have a newer code base with some fall-back support for old Android platforms.

And here’s a screenshot form Android Eclipse –> Window –> Android SDK Manager.  Notice how it says “Android 4.4 (API 19)”.  Also notice Kindle Fire HDX is listed under “Android 4.2.2 (API 17)”.

My current plan (for my small hobby project of simple graphics demos) is to support multiple platforms (Android, iOS, Windows, Linux, Mac OS X), but only support reasonably new versions of each platform (such as Android 4.4 with OpenGL ES 2.0 or 3.0).  I especially don’t want to waste a lot of time on any really old API’s such as fixed function pipeline style OpenGL ES 1.1 or OpenGL 2.x.  It’s worth mention that the older deprecated stuff gets older and more deprecated as each day passes.

The cross-platform hello world cube in my previous post started from the SDL2 (2.0.0) testgl2.cpp and testgles.cpp examples.  It was at least using glDrawElements() / glDrawArrays() instead of intermediate mode glBegin() / glEnd().  However, it was still using old fixed function code like glMatrixMode(GL_MODELVIEW), which is deprecated in OpenGL 3.0, and removed from OpenGL ES 2.0.  I’m planning to at least upgrade my project to exclusively use reasonably new API’s such as OpenGL shaders instead of fixed function.  I’ll probably use OpenGL ES 2.0 with extensions (such as for VAO’s) or OpenGL ES 3.0 (Android, iOS), OpenGL 3.x or 4.x (Windows, Linux, OS X), and later I might add a DirectX 11 path too (for Windows and Windows Phone).

I found more info on Android OpenGL ES version support here:
So OpenGL ES 3.0 requires at least Android 4.3 (API level 18), and a device that supports OpenGL ES 3.0.

Here’s an Android chart that claims 96.3% of devices (as of Dec 2, 2013) support OpenGL ES 2.0, and only 3.6% support OpenGL ES 3.0:

0.1% distribution suggests that a fallback path to OpenGL ES 1.1 is not useful for Android (to put it lightly), while OpenGL ES 2.0 is dominant.  However, maybe in 2 to 5, OpenGL ES 3.0 support will be above 90%.

Kindle HDX uses API Level 17 & OpenGL ES 2.0

Amazon Kindle uses a fork of Android called Fire OS which uses API Level 17.  OpenGL ES 3.0 requires Android API level 18 (Android 4.3) or higher, so if I want to support Kindle Fire HDX then I shouldn’t use anything newer than API Level 17 and OpenGL ES 2.0.  Probably there are other Android devices also very recently released that do not yet support OpenGL ES 3.0.

OpenGL ES versioning (Apple iOS, wikipedia)

So with SDL2, you still get to deal with all the “fun” of versioning.  For example, the following Apple iOS page lists a small number of devices with support for different versions of OpenGL ES (versions 1.1, 2.0, 3.0):

As of 2013/12, this list goes back to iPod touch 3G (September 9, 2009).  Every Apple iOS device here is listed as supporting OpenGL ES 1.1, 2.0.  But only the latest are listed as supporting OpenGL ES 3.0 – iPhone 5s, iPad Air, iPad Mini Retina.  iPod touch 5G does not support OpenGL ES 3.0.  So unless I want to only support the newest devices (which might be fine since this project is just for fun & learning), then I should not exclusively use OpenGL ES 3.0.  However, anything older than Sep 2009 is very old (that’s 4 years 3 months).  Also, as described on wikipedia, OpenGL ES 2.0 requires programmable pipeline (good):

> OpenGL ES 2.0 was publicly released in March 2007.[2] It is based roughly on OpenGL 2.0, but it eliminates most of the fixed-function rendering pipeline in favor of a programmable one in a move similar to transition from OpenGL 3.0 to 3.1.[3] Control flow in shaders is generally limited to forward branching and to loops where the maximum number of iterations can easily be determined at compile time.[4] Almost all rendering features of the transform and lighting stage, such as the specification of materials and light parameters formerly specified by the fixed-function API, are replaced by shaders written by the graphics programmer. As a result, OpenGL ES 2.0 is not backward compatible with OpenGL ES 1.1. Some incompatibilities between the desktop version of OpenGL and OpenGL ES 2.0 persisted until OpenGL 4.1, which added the GL_ARB_ES2_compatibility extension.[5]

Here’s what wikipedia says about OpenGL ES 3.0:

> The OpenGL ES 3.0 specification[6] was publicly released in August 2012.[7] OpenGL ES 3.0 is backwards compatible with OpenGL ES 2.0, enabling applications to incrementally add new visual features to applications. OpenGL 4.3 provides full compatibility with OpenGL ES 3.0.

So the iOS scene is similar to the Android scene.  OpenGL ES 2.0 is the primary version supported, but OpenGL ES 3.0 is the future (and exists today on a small subset of devices).

OpenGL ES 2.0 or 3.0 or both?

For my project, I can use OpenGL ES 2.0 or 3.0 or both (aka 3.0 with a 2.0 fall-back path).  If I use OpenGL ES 2.0, I can still use extensions to detect additional features such as GL_OES_vertex_array_object for Vertex Array Object support.  If I want to develop for the present, 2.0 is the obvious choice.  If I want to develop for the future I could move completely to 3.0.

Trackback this post | Feed on Comments to this post

Leave a Reply