OpenTK gains support for OpenGL ES 1.0, 1.1 and 2.0

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.

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.

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.

Indeed, this is gonna be great.

Any news regarding this?

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)

1&3) The khronos website was down earlier and thus no access to the specs. Got them now, will read the essential pieces this weekend. According to your assessment (and my impression of the situation), no major problem there.

2) Sorry, totally forgot about the size constraints being a problem (the 500GB HDD that came with my PC last year is nowhere near half-full).
Actually I was referring to namespaces, not necessarily dlls. Moving ES closer to the root namespace will make the difference more obvious and I'd also like to suggest not re-use the name GL for ES-related functions (applications may have code-paths for both APIs) and rather name it GLES or ES. So if programmers browse code, they don't have to know which using statements the current file has, but can identify on first sight whether the code is currently related to GL or ES.

ES.GenBuffers...
ES.BindBuffer...
...etc

I'd prefer to have 1-2 big .dlls (as it currently is) allowing conditional compilation if you feel something is just wasting space (e.g. people might want to use FMOD instead of OpenAL and simply remove it from OpenTK for their projects). For Desktops/Laptops disk space is not a problem, but allowing to shrink OpenTK - when the application is ready to ship - will certainly help if the app is meant to be distributed by internet downloads and not hardcopies.

4) I'll take a look at that, since I've done that for GL already it should be pretty obvious what belongs where.

P.S. Mind my interest in GL ES is fairly limited, although I don't have a PS3 that's the only platform I'd be interested porting my renderer for.

Offtopic, but before I forget it: Who did the OpenCL functions? The person should be slapped for adding tons of meaningful // OpenCL 1.0 comments over the function signatures, rather than c&p the native C. :P

[ILMerge]
If there's a parameter that strips the resulting assembly of unused classes/structs/methods/etc., I cannot see it. (I knew about ILMerge, but that missing feature is why I didn't bother with it)

[OpenCL]
Apologies, so whoever is responsible for the frequent changes should be slapped. :P

Assuming this is true, I take back all statements regarding conditional compilaton of OpenTK. (Waste of our time doing that, if you can simply reduce size by a post-build step).

beta in august. release later.

It's a tool that can strip and merge assemblies into a single one. Depends on Mono.Merge and Cecil.

The project exits somewhere deep inside the mono repository.

Edit: or was it Mono.Merge that depends on Mono.Linker? I can never get this right.

I'm currently playing around with OpenTK for the iPhone. It looks great, but I really miss those strongly-typed enums (one of great advantages of OpenTK over similar products)...
Do you know when they will be implemented?

I will make the necessary changes in formatting, but we need some volunteers who either write some small example applications from scratch or port existing GL examples to ES. They don't have to be groundshaking, but should run without causing any errors and test the most fundamental parts of ES (VBO, FBO, GLSL).

Yes, with one caveat: the signatures.xml file is auto-generated and will be overwritten whenever the specs or our converter tool changes. Updated signatures should go to the overrides.xml file.

Inertia has pretty much completed the XML overrides for the 2.0 spec. We still have the 1.1 and 1.0 specs to do (the latter is not very useful nowadays, but the former is).

I'll post some more concrete documentation on the generation process over the next few days.