JTalton's picture


Hey all,

Things are going well. Slowly coding away. I am hoping to release a new version of Golem (it's been a year!) soon that is built on OpenTK using the GameWindow, fonts, and cross-platform support. I'm still really excited about OpenTK. Holding my breath for some of the new features. I know there is the issue tracking system, but is there a roadmap for new features? I am trying to change my schedule around to find more time outside of work and family to devote to coding. Is there anything I can help with in OpenTK?

New Font Support
I am patiently waiting and hoping for this.

OpenGL 3.0 Support
Hoping to remove deprecated functions and move to OpenGL 3.0. Waiting on support.

Mac OS X Support
Looking good! Very excited to have this support.

GameWindow Support: Window Icon - Window Placement - Mouse Grab
I am looking forward to these enhancements.


Comment viewing options

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

Nice question, what would be the roadmap of features for 2009? I am a bit worried that the new OpenGL3 release will bring more work on fellow developers (like porting pieces of code and hunting bugs), making the features left behind.

Either way, the more developers exist, the better would be...
I am in the mood to help in OpenTK development, but currently I can't track any easy task that suits my skills :(

Personally, my wish for OpenTK is to get a high-level library that would make application development even more rapid, like an XNA alternative ;)

kanato's picture

So Fiddler has the final say on this of course, but here is my take on a couple of those issues. I think we're close to 0.9.2, once the font stuff gets all fixed on linux. Last time I checked the trunk it seemed to work but I did not do any thorough testing at all, so maybe there are still issues being resolved. Once 0.9.2 is released, I will probably merge the Mac OS branch into the trunk so there will be MacOS support in 0.9.3. The only major feature missing there is fullscreen support, which I hope to start working on early next week.

I also would like to have window icon and mouse grab support in GameWindow. The mouse grab I think is mostly a matter of settling on an API that's consistent. Icon support will be a little more work because each OS has its own icon format, and the System.Drawing.Icon class is a bit deficient, since one cannot pull out particular sizes of icons using it, and what you'd really want for window icons is to be able to convert all appropriate sizes in an icon to the type required by the OS. This shouldn't be difficult, but it will take a bit of research and coding. So that doesn't answer your question on a roadmap for this feature, but I think it shouldn't be too many versions away. :)

the Fiddler's picture

I think JTalton has covered the roadmap for the close future.

Kanato has been working on the Mac OS X port, Inertia has identified the pieces for GL3 support and I've been hacking together a WinForms/GLControl-based GameWindow with Kamujin's timing patches (which I've apparently forgotten to push to svn).

Mac OS X Support
Once we decide how to proceed with the GameWindow (see below), this is probably ready to merge to trunk - if kanato and Inertia agree.

GameWindow Support
I've been wondering if a WinForms-based GameWindow would be better:


  • We push most platform-specific code down to .Net/Mono (better tested and OpenTK.dll should lose some weight!)
  • We automatically gain all requested features (window placement, icons, notifications etc)


  • We become reliant on the WinForms dll. This is already the case, so small loss here.
  • We lose on keyboard/mouse support (no left/right key detection, only 5 mouse buttons.) This can be worked around by hooking the current implementation to the native message queue (easy on windows, any idea how to do this on linux / macos?)
  • We might lose some speed on Mono due to the WM translation layer (probably insignificant, but cannot say without testing.)
  • Afaik, WinForms on Mac OS X need X11 installed (not running.) Would this be an issue in practice?

I quite like this idea as it would make the code quite a bit simpler, but I'd like to hear your opinions here!

New Font Support
I'm still not satisfied with the text renderer (and apparently I'll never be, unless it goes all the way to Uniscribe and Mono.Pango), but at least the hard work is more-or-less done. Two pieces remain: fix GL1.1 support and lock down the API. (I'll post an overview here and more details on the issue tracker.)

The issue with GL1.1 is that it cannot modulate RGBA textures by color with alpha-blending enabled. One solution is to render in two passes, but this introduces artifacts when text overlaps. The other, simpler solution is to disable cleartype and use alpha textures instead of RGBA ones.

Regarding the API, we'll have to decide whether TextPrinter.Begin/End are desirable and how to specify the rendering position, color and, possibly, a projection matrix.

OpenGL 3.0 Support
Right now we are working on the full GL3 profile. We are still missing the new context creation logic for each platform and the type-safe enums.

Once that is done, we can add the forward-compatible GL3 profile (probably by copying the relevant parts of the specs by hand.)

Edit: Missed your post, kanato, but I just ran out of time. See you next year! :D

Kamujin's picture

I am pretty sure that WinForms on OS X no longer requires X11.

As far as a WinForms based GameWindow, I think all of the negatives are trivial except for the possibility that it will introduce limitations on input system. In my opinion, full mouse and keyboard support are critical features.

martinsm's picture

Afaik, WinForms on Mac OS X need X11 installed (not running.) Would this be an issue in practice?

Mono implementation of Windows.Forms on MacOSX does not require X11. At least with latest Mono 2.0.1 I am able to run winforms applications without installing X11.

kanato's picture

Are you running winforms apps on Tiger or Leopard? I thought Leopard comes with X11 installed already, so I'd want to be sure that WinForms works on Tiger without X11 to be convinced. Maybe I can test this by uninstalling X11...

My understanding of the OSX / X11 issue is that X11 had to be installed for Mono's fonts to work, so this is really a limitation of System.Drawing.dll and not System.Windows.Forms.dll. Which means that whether we use a WinForms GameWindow or not we still will have this limitation in the fonts.

WinForms GameWindow:
I should experiment with doing this a little bit. WinForms applications typically look rather out of place on MacOS because they come in with a lot of Windows-isms (ie. menu bars are inside windows). For GameWindow, I think it won't be an issue but it's something that should be checked.

As far as hooking to the native message queue, it's easy on MacOS. It allows you to register multiple event handlers for windows, etc. so we can register our own event handler without conflicting with Mono's. I'm not sure what order event handlers are called for an event though, but if we want to go this route I can do some experimentation.

objarni's picture

flopoloco: I think one contribution you could do is build example-programs. Such examples, covering larger and larger areas of the OpenTK API, will make OpenTK more robust/performant on different platforms. Each example could concentrate on some specific feature of the OpenGL API (like Nehes classic GL tut's).

Maybe a small game? Pong? Tetris? Missile attack?

Inertia's picture

"Is there anything I can help with in OpenTK?"

Like objarni said, one thing everyone can contribute to OpenTK are example programs. They don't have to be awesome pretty, nor contain the most 1337 optimizations man has seen so far, but simply verify that a certain extension (or multiple extensions used together) work flawlessly and all required tokens can be found in the enums used by the Extension's functions. The example may contain material which has already been covered in another example (it will be very hard to write a GL program that does not use GL.Begin() or GL.Draw*** commands) but ideally it will test some unique features.

Here are some (ambitious) ideas what could be done (nowhere a todo list or complete in any way)

  • Pick a Nehe Example (or any other tutorial/example you liked) and port it to OpenTK.
  • Fractals are very fun. (e.g. this one should look pretty awesome when using tetraeder http://en.wikipedia.org/wiki/Sierpinski_triangle)
  • Some application for testing Transform Feedback.
  • An example that uses (ideally both) instancing Extensions. (Bonus points can be earned by adding instancing hacks :P)
  • A test scenario for the Occlusion Query Extension.
  • Any implementation of a shadow algorithm.
  • A GLControl example that iterates through all texture formats and then allows the user to pick a supported format from the list and let the application show a texture in that format.
  • Replicate Alut's functions to procedurally generate noise. (C source code for freealut may be a starting point)

How about renaming the current GameWindow to NativeWindow (or similar) instead of abandoning it? At very least pinball simulators make use of the left/right key distinction, and the existing code is tested and works.

[Mac OS X Support]
Cannot really make a statement about this due to the lack of a test system, but imo it should be merged to trunk as soon as it's stable enough to run the examples. It will take one version increment to iron out all problems, so the sooner it gets into trunk and used by people, the faster the problems can be identified.

[Font Support with GL1.1]
I would really not bother with a GL 1.1 fallback, unless someone really manages to dig out some hardware that does not support the required Extensions. Last time I checked, you get DirectX 10 low-end cards for 40€ ....

[OpenGL 3.0 Support]
The worst parts (merging 2.1/3.0 specs and identifying function/enum changes) are already done, Context creation is a chapter on it's own because - although only very few attributes were added to context creation itself - we should consider allowing contexts with sRGB or floating point framebuffers as opposed to RGBA8-only framebuffers. Hardware support for this is not yet widespread, but it is improving.

P.S. Oh, and Happy New Year 2009!

flopoloco's picture

You are right, examples and tutorials are definitely needed.

kanato's picture

[Renaming the GameWindow to NativeWindow and writing WinForms based GameWindow]

I've been thinking about this more, and I think this is the best solution. Probably the best approach would be to just add a windows form that implements INativeGLWindow (perhaps rename the interface to IGameWindowImplementation or something) and maybe have a static flag somewhere that would select whether the GLControl based IGameWindowImplementation object is created, or the native implementation is created.