dhakim's picture

Structuring OpenTK Calls for Maintainability

I love code complete, I love how all the OpenTK functions take specialized enums instead of ints, allowing me to quickly find exactly what it is I wanted. I even love how there's an All, allowing me access to everything there ever was in OpenGL, even if it hasn't been wrapped up yet.

But I'm wondering if I've coded myself into a hole...

Myself and a couple other guys have coded up a rendering engine using OpenTK for work, it works great on Windows, and in the course of a day I managed to get it running on Mac OS X in Mono. The next step is MonoTouch, and unfortunately all the using OpenTK.Graphics.OpenGL at the top of the files have to become either OpenTK.Graphics.ES11 or OpenTK.Graphics.ES20. This wouldn't be so bad a change, going through all the files and changing that one using statement could be done very quickly, and could even be done as an afterthought, so long as we only use functions in the intersection of the versions we want.

The problem I'm running into is that as soon as I change one of those usings, I run into a giant mound of errors, partially from differences in the OpenGL and OpenGLES apis, but mostly because every line that says GL.Enable(EnableCap.blank) has to be changed to say GL.Enable(All.blank) throughout the code, with similar issues for every other usage of the nice enums. It kind of makes me wish all the functions were overloaded to take ints.

So is there an elegant way to structure my code around this problem, or am I going to have to make 2-3 versions of the rendering engine (and/or add additional abstraction on top of the called OpenTK functions), along with all the maintainability issues that presents when we inevitably need to fix things in the engines? :(


Comment viewing options

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

As of version 1.0, OpenTK.Graphics.ES20 contains the same enums/overloads as OpenTK.Graphics.OpenGL. As long as you stay within the common subset of both APIs, the code should still compile just by changing the using directive.

It seems MonoTouch doesn't include the improved bindings yet and I'm afraid there's nothing we can do about this (MonoTouch is a commercial, closed-source project from Novell). I'd suggest asking on their forums.

dhakim's picture

Thanks Fiddler, reposted in the MonoTouch forums. Turns out I was using version .9.9.2 of OpenTK as well, so I didn't even think OpenTK handled this case.

I did have an idea while I was reposting, though it might be a stupid one for reasons I don't yet understand about how OpenTK and MonoTouch work... Even if they never update their bundled version of OpenTK, would I be able to compile the latest version of OpenTK using MonoTouch, then link all my code against that?

the Fiddler's picture

As far as I know, MonoTouch is using a custom, stripped-down version of OpenTK. It should be possible to compile and use OpenTK on MonoTouch with two simple modifications:

  • add "MINIMAL" to your compiler defines in MonoDevelop.
  • comment out line 200 of Source/OpenTK/BindingsBase.cs (the one that reads GetExtensionDelegate(name, signature) ?? - ES on iPhone doesn't expose extensions or EGL for that matter).

Obviously, this is completely untested and it might not work without additional work. If you try that, please let me know of the results - it would be nice to have OpenTK work with MonoTouch out of the box.