Open GL vs. Open GL ES

[goatslayer]

Hi,

I started a foray into graphics programming using the Allegro 2D games programming library. It is a good library, but I now I want to look into using Open GL.

Question is however, I'm not a software development house, just a lowly developer working on a few concepts.

The most satisfying result I can imagine from graphics programming is to get those concepts on devices like the iPhone, android phones, psp etc.

If I develop in Open GL ES, could I get away with not using Open GL for running those applications on desktop machines as well?

I guess the scenario might be, normally I will develop of portable devices. Sometimes however I might want to do a little app for the PC, should I bother going to Open GL if Open GL ES does what I need?

Thanks, any views are appreciated!

[JVene]

OpenGL ES, as implemented currently in the iPhone is based on OpenGL 1.5. There are similar, and a great deal of what you write for ES is applicable, but not so exactly that you want to write application code directly to OpenGL (of any version).

I empathize with your question. It appears to be a paradox that so much interest is focused on the iPhone, and yet there appears to be scant resources available. Such is part of the paradox of a new platform.

When you write, you want your application code to write to an abstraction which represents the graphics calls to OpenGL, such that you can localize the differences which exist between the platforms you might wish to target, and to the forward moving versions we can expect from the iPhone platform itself.

It's not just about OpenGL vs ES, it's about the various details regarding each implementation. The iPhone uses PowerVR, which uses specific compression formats unique to that graphics chip. Other platforms would be different, and you might be tempted to write for each platform, but you probably don't really want that. From a business standpoint it makes more sense to be portable among the various versions going forward. The opportunities for business will be governed by that.

The abstraction I describe will look and work like a graphics engine, driven by the OpenGL / ES design. Every time you're tempted to write directly to the OpenGL (ES, etc) API, write to your abstraction instead. Before long this means your application API becomes the abstraction, which in turn can be specialized for all your applications needs for all platforms you intend to cover, and all versions which appear in your future.

Android isn't going to support C++ development as far as we can see. iPhone will likely never support Java, so the two will be independent product lines for everyone. You might share some of the graphics materials, but little else beyond the basic designs.

The iPhone is significantly unique in it's combination of user input features and graphics capabilities. There are a few devices emerging that are adopting this concept, and there may be some potential for crossover.

Another area of abstraction required is the application/device interface. iPhone requires some objective-C to get the app running and accept input. This can be 'mated' to a C++ framework, which is then portable to other platforms and devices. Each point of contact between the application and the device requires a layer of indirection, because each of the devices will only be similar, not exactly the same. It's difficult to determine which without those devices, and it's likely most of the interesting ones are not yet available.

[goatslayer]

JVene, thanks for the reply. I understand that if there are differences expected you write some sort of abstraction so that you only need to change how you use the library code while your core code uses the same interfaces.

The interesting thing you focus on however is the iPhone, while there are the following platforms supporting Open GL ES:

- PS3
- Pandora(.org)
- iPhone
- Symbian

These are huge platforms. Strictly hypothetically speaking without knowing the overhead for thinking about Open GL at the same time. Would code developed for these platforms using Open GL ES not run quite nicely on the PC?

Has anyone actually gone about things this way?

[JVene]

Let me take this a step or two further.

First, I have done this. I own several businesses, and one of them targets this general direction.

I found that the iPhone is a relatively small platform. There's as much power in the phone as was available in average CAD workstations at the turn of the century, but compared to 'modern' platforms, there's considerable difference. The PS3 is among the most difficult to develop for, and expensive. The difference for that platform are not just about OpenGL/ES, but about the nature of the environment - it's a specialized 10 core processor. For platforms like the Wii, you must pass an interview, and demonstrate that you have a staff before they let you pay the fee.

In theory OpenGL ES is so similar to OpenGL, that you'd be able to make ES applications work, but in practice you will still need abstraction to help, or you'll be lost in a maze of special version builds that will ultimately de-leverage your efforts at market coverage.

What is appropriate is to design that engine, first, for the ES platform, then expand. One of the reasons I decided not to use any of the engines I could find was that they were squeezed into OpenGL ES 1.x, not expanded out of it. For the phone, in order to provide competitive results, it was better for me to specialize toward the tight squeeze on the phone, especially when it came to physics.

What I did, in order to help with development and portability, was to download the OpenGL ES emulation package from Imagination Technologies for their PowerVR chip (which is in the iPhone). This allowed me to develop OpenGL ES applications in Windows, which also then operate nicely when I select to support OpenGL as the backend, yet I can compile the application in XCode (subsituting the appropriate application framework that 'surrounds' the OpenGL ES code) for the iPhone.

This also means I can target various Windows CE builds from VS2008, and port the code into Linux when appropriate for other builds.

At no time do I allow application code to write directly to the OpenGL ES API. It's just not good business.

However, there's nothing to stop me from accessing OpenGL features (or DirectX for that matter) if I so choose.

What's just as important to me is the fact that I can also move forward to OpenGL ES 2.0, which is as different from 1.5 as ES is from OpenGL, is many respects.

[goatslayer]

Cool, thanks JVene! - good post. Certainly gave me a few things to think about.