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!


Comment viewing options

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

1 & 3: EGL itself is pretty clean, and resembles GLX quite a lot. You need a platform-specific stub to get a window handle and a display connection, which you then use to create the platform-independent EGL context. All in all, it fits quite nicely into the IWindowInfo, IGraphicsContext and IGraphicsMode abstractions.

Of course, a) you'd still have to implement the IPlatformFactory interface for a complete port and b) the iPhone doesn't use EGL. Fortunately, getting a simple context up and running looks fairly simple.

2: The issue is that regular OpenTK.Graphics.GL takes up about 1.8MB of disk space. When your hard limit is 10MB, you really can't afford to waste that amount to code you aren't using.

Conceptually, OpenTK is split into a distinct parts:

  • OpenTK core. This contains the main interfaces and platform-abstractions (i.e. IGameWindow/GameWindow, IPlatformFactory/PlatformFactory), as well as the math library. These are going to be compiled in no matter what.
  • OpenTK.Platform which contains platform-specific implementations for the main interfaces.
  • OpenTK.Graphics contains the various OpenGL and OpenGL ES profiles.
  • OpenTK.Audio for OpenAL 1.1.
  • OpenTK.Compute for OpenCL 1.0.

Right now, the core depends on OpenTK.Graphics. Once this dependency is broken we'd be able to compile each part independently: either into different dlls (as you propose), or into a single one using conditional compilation.

4: Pretty much, yes. The enums are right there, but the C signatures do not use them - I'm afraid we'll have to fix that by hand.

Error checking is simple enough to implement - no problems there!

Inertia's picture

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.


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

the Fiddler's picture

2. Agree 100%. I'll fix that.

For the size issues, take a look into ilmerge. It's an awesome little tool that can merge all assemblies into a single executable. There's an open-source alternative, called mono-linker, but it's a little hard to get (it's buried deep into the Mono repository) and it crashed on [return: ] attributes last time I tried (maybe this is fixed now).

4. I actually removed the C signatures on purpose. The C headers changed every couple of weeks (we were at version 43 last time I checked), so the signatures fell out of sync rapidly.

I've given up on the hand-written approach: I'll just translate the C headers into xml and run them through the generator. Ultimately, this will save us a lot of trouble once OpenCL 1.1 is released.

Inertia's picture

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)

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

the Fiddler's picture

As far as I can tell, this feature is enabled by default.

Inertia's picture

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).

the Fiddler's picture

ILMerge is windows-only, unfortunately, and I don't know if the resulting binaries will work on Mono. (I'll have to check mono-linker again.)

cjac's picture

beta in august. release later.

cjac's picture

what's mono-linker?

the Fiddler's picture

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.