the Fiddler's picture

OpenTK gains support for OpenGL ES 1.0, 1.1 and 2.0

OpenGL ES is a subset of the OpenGL API used in embedded devices. It is used by Apple's iPhone, Google's Android, Nokia's Maemo, the Sony Playstation 3, the Pandora handheld and other devices.

OpenTK now offers experimental support for OpenGL ES profiles 1.0, 1.1 and 2.0, which roughly translate to OpenGL 1.3, 1.5 and 2.0 respectively. This includes inline documentation but excludes strongly-typed enums, which will be added at a later time. There is also no support for constructing contexts through EGL, however it should be possible to use an external GL ES context in conjuction with OpenTK. Finally, the bindings are untested - please file any bugs you encounter.

If you are interested in helping out, testing or porting (esp. to iPhone and Android), make a post!


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
objarni's picture

This is great news!

How would a port to for example IPhone work technically..? Is there a .NET implementation for IPhone?

the Fiddler's picture

Novell is working on Mono implementations for both iPhone and Android, but neither is available yet:

For the iPhone, you need to use full AOT compilation into native code (Apple doesn't allow JIT compilers). The biggest technical hurdle for the ports is getting an OpenGL ES context. For Android, this requires Java interop - no idea about the iPhone.

objarni's picture

OK so with a suitable bytecode->native compiler for the IPhone (is there a good one..? gcc?) the only problem left is "hooking up" the OpenTK ES context?

For Android, this requires Java interop - no idea about the Android.

I'm not sure I follow - Android or IPhone?

the Fiddler's picture

Meant to say 'no idea about the iPhone' :)

Mono includes a bytecode->native compiler (see http://mono-project.com/AOT) and AFAIK they are working to bring it to the iPhone. Unity3d supports the iPhone (which probably means the compiler is working already) and someone mentioned a public beta will begin around August.

Inertia's picture

Good job, reading the enums I was rather pleased to see a compact GetPName for the first time ever. Enums called ShaderPrecision and ShaderBinary are promising aswell.

Are there any emulators one can use to play with this, or is the hardware required?

the Fiddler's picture

AMD distributes an emulator and there are other open-source implementations.

Frankly, the ES API is what OpenGL should have been but isn't: short, clean and to the point. Plus it has shader binaries, which are pretty important in larger applications.

JTalton's picture

Sweet. I had read about this elsewhere first. I've actually been off working in C++ with an ObjC wrapper making an iPhone game. I'm still working on Golem3D but not as active. Once C# with OpenGL comes out for the iPhone it will be a great thing.

triton's picture

Indeed, this is gonna be great.

Any news regarding this?

the Fiddler's picture

We are still on the planning stage, but a Mono developer is helping with the iPhone port.

There is a ton of work left to do:

  1. EGL bindings
  2. Conditional compilation (e.g. do not pull OpenGL/OpenCL in)
  3. Platform-specific parts (window creation, parts of context creation)
  4. ES cleanups (type-safe enums and error checking)

Of course, additional hands would help things move along faster! The ES bindings could use some love, specifically.

Inertia's picture

1. & 3. (I like to think of this as "canvas") Isn't it possible to recycle lots of logic from the "desktop" GL classes? I'll take a look at the EGL specs asap, but from the GL ES specs the API appears to be very close to OpenGL.

2. Why don't you move ES-related classes to OpenTK.Handheld or OpenTK.Embedded? It appears "desktop" GL and GL ES cannot each have a context and share textures, display lists etc. with each other, so essentially they are 2 different things that should not be connected in any way. Future handheld devices might support OpenCL, so there should be nothing from OpenTK's side to prevent a programmer from using OpenTK.Compute and OpenTK.EmbeddedGraphics together.

4. In other words, you simply want all functions using OpenTK.Graphics.GLES***.All enums replaced with appropriate ones? The enums themselves look rather clean to me already (but I haven't compared them to spec yet)