Future of OpenTK about opentk

[renanyoy]

99% of peoples use only the GL binding in OpenTK, no needs of the other parts...

[andykorth]

OpenTK is pretty dead. I do take changes to the project here. There have been some bug fixes and some improvements, although mostly just to the math classes.

I'm entirely open to other changes, although I think users of the library need to realize it's not really much of an option for use on Mac, Linux, or any non-Windows platforms. I'm not really sure how much of OpenTK gets used, so I don't know how much something like performance improvements would be appreciated. The questions that do come up in the forum seem to be mostly related to GLControls and windows forms. I'm not a windows guy, so maybe OpenTK works great for these folks and they would appreciated the changes.

When I started maintaining this branch of OpenTK, I wasn't aware of the amount of work getting it cross-platform. For new cross platform projects, I'd definitely recommend using something else. And the Mono team might have better luck with the SDL3 stuff (or GLFW) than openTK.

Hopefully this doesn't sound to pessimistic. Changes here are very welcome. Although some of the opentk.com forum community doesn't like the idea of project forks, many other people are using this branch.

Thanks!

[Frassle]

Already well aware that the situation was pretty bleak. GLFW and SDL look interesting but both of them A add another dependency (so you have the dependency on SDL and the SDL binding and probably another API like MonoGame on top of that!) and B seem focused on graphics not audio and compute. Would be nice to get OpenTK to the point where it supports the Khronos and other Open* APIs as good as SharpDX does the DirectX ecosystem.

I'll start hacking away, see what I can do. Using both Windows and Linux (and hoping to start with monodroid some time) maybe I can help out a bit with the cross-platform issues.

[renanyoy]

I think monogame use opentk as renderer, so they should need the updates too..

[andykorth]

Kind of. Monogame uses a pretty small part of OpenTK. Mostly it uses the autogenerated (and hand generated parts) of the OpenGL bindings. Monogame definitely doesn't use any of the windowing code (which is a huge pile of code), it doesn't use the input code (which doesn't work on Mac). I don't recall now if it uses any of the openTK math classes.. I think it doesn't.

Regarding the mac cross platform issues, a lot of the key code is written in Carbon, which is very out of date and will soon be removed from the OS.

[Robmaister]

I've heard great things about SDL2. I'm not that familiar with the structure of OpenTK's windowing/input system, but if it's possible to hack in as an alternate backend, I think we should temporarily do that to get full support on non-Windows OSs. SDL and the wrapper would only have to be distributed if the SDL backend is chosen by the developer.

Meanwhile, we could overhaul OpenTK's OS-specific bindings for those who'd rather not depend on SDL.

Also, I think including other Khronos APIs would be cool, though I don't think there are too many other ones that are super useful at the moment. I suppose EGL and OpenSL ES might be useful on mobile platforms. OpenGL SC is something we can easily throw in, OpenVG might be useful to some people as well. COLLADA is also Khronos, but that sounds like a completely different project IMO. Oh, and someone should run the OpenGL ES 3.0 .spec file through and create a new namespace for it.

I have multiple Windows and Linux machines, and a friend with a (relatively old) MacBook that I can borrow on occasions to test thing, and I'd like to help with all of this.

I think the best way, moving forward, is to set up a bunch of milestones and issues on GitHub to organize what needs to be done and to break it down into sizable units of work.

[Frassle]

That's partly because the compute part is non-existent, and audio is only for low level OpenAL not something that everyone uses. I'd really like to see this project get to the point where we can support GL and CL at least and get them onto desktop and mobile (there are some mobile chips that support OpenCL now). Getting the other APIs in as well once GL and CL are stable would be great! I'm getting up to speed on how the binding generator works and will try and get compute bindings in when I can (moving house and new job atm so all a bit hectic but defiantly want to work on this).

Another thing we could possibly do, although this is really far fetched is try and unify common parts of OpenTK and SharpDX. I don't expect they'll want to move to a shared library anytime soon but if we can match their API for things like DataStream it will be easier work for people like MonoGame who use both APIs.

Can I propose milestone 1? SharpDX (and SlimDX before it) both had classes to allow easy access to unmanaged memory that could be passed to the native APIs. SharpDX has some clever tricks using Mono.Cecil to access IL instructions that C# doesn't normally use to make unmanaged memory access fast and relatively safe. Getting a similar system up for OpenTK (even if we don't change any APIs to use it quite yet) would be a good start to getting to ball rolling on this thing.

[Sappharad]

Please don't consider dropping OpenAL support, or anything that's working fine already.
In the case of graphics rendering, there are a few alternatives. Graphics might be in higher demand, and more people may be willing to help with that, but when I did research on my options over a year ago OpenTK was the only library that provided a low latency sound API that worked on all 3 platforms. The same is true for input, which despite Andy's claim above, does work fine on the current version of OS X. (As long as you're using the patches for it.)
I use OpenAL and OpenTK input for the OS X builds of the BizHawk emulators, and unless the options have changed in the last year, this is the only cross-platform library I can use for low latency sound and input on OS X.

I had created my own branch of OpenTK over a year ago with the intention of filling in holes for the OS X implementation, but it just wasn't worth it at the time. There's a lot to learn regarding interacting with the native OS, and there wasn't any interest being shown. If that's not true and we want to do something about it, it would be great if this project could start moving again, but be sure to keep in mind that this is still the only option for many goals.

That being said, I can test things on OS X and sometimes (rarely) fix them. I also have a few versions of Windows in VMs to compare against.

[Robmaister]

@Frassle Yeah, this would be a good idea at some point, I think we should focus on the broken stuff first (like window/input), though. Also, speaking of IL tricks, this is something we should do pretty soon:

http://www.opentk.com/node/2845

It's fairly simple, but should give all OpenTK-based programs a nice speed boost. And as for speed regarding unmanaged memory access, I can't think of anything faster than calling GL.MapBuffer and manipulating the pointer in an unsafe block, but I suppose some people would rather not use unsafe, so getting some nice tools to do this would be good.

@Sappharad I'm using OpenAL too, I don't think it's going anywhere. My only complaint is the need to have Creative's OpenAL installed. Would be nice if we could package OpenAL Soft with OpenTK so that people who don't have OpenAL installed don't have the game immediately crash on them. It's LGPL which means we should be able to redistribute without a problem.

[Frassle]

So I'm waiting on some legal issues on how much I can help out with this project (I work on OpenCL drivers so legal want to make sure this work wouldn't affect any company contracts). Either way this goes do feel free to plunder my github repos for bits and pieces I've done on OpenCL/GL/AL bindings before.

[paulcscharf]

I probably have little to contribute to this discussion itself, but I thought I would mention that I am very interested in OpenTK's future, and have already been promoting it a bit on a small scale over the last few months.

So if there is anything I can do to help out, I would certainly try. Unfortunately I have almost no knowledge regarding all those technical things, you guys talk about above.
My own expertise lies in the area of mathematics, general graphics programming, webdesign and to some degree C#.

In fact, I have been working (somewhat on and off) on a C# library that is supposed to provide a powerful and high-performance object oriented layer on the procedural OpenGL and am currently working on a game project using that library for rendering(and monogame for the rest).
(Just to clarify why I am interested in OpenTK.)

From what I read it seems that the OpenGL part of OpenTK is not the major issue however?
Even so, I certainly would like to help if I can, be it by testing things(only on Windows though), or by reviewing other's changes and additions, or maybe just mundane things, like commenting undocumented code. Whatever is needed.

I will try to keep on reading here, as well as other places these issues are discussed.
And if my particular skills or willingness to help should be helpful, I hope someone will point out to me what can be done.

On a last note, I may just be looking in the wrong places, but it seems to me that there really is no central place to organise these things at the moment.
The current OpenTK website seems rather out of date and I cannot judge how much the forum traffic is worth there.
So I am wondering if it might not be worth considering to officially split off these efforts to revive OpenTK into their own project?
Not to look down on the fiddlers great work on OpenTK, but with him virtually gone, forked repositories all over the place, etc., it seems like the infrastructure to support this project does not really exist, at least to me. You guys will be better able to judge that.

Looking forward to seeing where this goes, and I hope to be making games using OpenTK for a long while to come!

[jeske]

If OpenTK is to make progress it needs a proper fork, a new communication hub, and possibly a name to distinguish it from the existing languishing OpenTK.com (even something as simple as OpenTK-2).

I'd like to talk more about this, but we don't even have a good place to talk about it. Any chance I can get some of you to join this mailing list.... For now I called it "OpenTKR", the R could stand for "Refresh" or "Reboot" or whatever you like...

https://groups.google.com/forum/#!forum/opentkr-dev

@andykorth - i think predicting Carbon's demise is highly premature, though MonoMac looks like it's providing a nice way to access modern Cocoa services from C#/CLR.

As for whether OpenTK should have a future, I think that is a fair question to ask and discuss. From a quick survey, it seems like Tao-Classic and SharpGL should work together more, while OpenTK should coordinate with MonoMac, MonoGame, and friends (which are currently based on OpenTK)... As for why, see below.

MonoGame (cross platform XNA) - lots of interest/activity, but very game focused. uses MonoMac.OpenGL which is a modified OpenTK

Tao Framework - dead, recently revived into...
Tao Classic - nice that they roll up lots more libs than OpenGL, but the APIs are more clunky than OpenTk because they expose almost raw C-OpenGL

SharpGL - currently Windows only, and spiritually very similar to Tao.OpenGL. (exposing raw C-OpenGL) Includes a simple scene-graph library as well.

[Frassle]

I think the ideal situation in terms of refresh would be if Mono offered some space and support and allowed MonoTK. Like you say close collaboration with MonoGame would be a useful and being part of Mono would make it more likely that Xamarin would take the updates and put them into MonoDroid/IOS.

[jeske]

It looks like MonoGame has at least some interest in going the route of SDL2# and using an unmanaged OpenGL wrapper, like MiniGL.

https://github.com/flibitijibibo/SDL2-CS/issues/20

[Robmaister]

Yeah, I've been following that. He seems persistent on writing C-style bindings in C#, from what I remember reading, a lot of the MonoGame developers don't seem to like that. The big issue is that it will break API compatibility with every single MonoGame class that has to call OpenGL and any games that may directly call OpenGL (if that's even a thing, I haven't used XNA/MonoGame extensively).

If we can fix our input backends fast enough (or hack together an opt-in SDL backend), it may be easier for MonoGame to just update OpenTK instead of migrate to a new library.

Alternatively, we could just let them do their thing and let us do our thing.

[paulcscharf]

I am usually all for doing our own thing. But having monogame use OpenTK gives us a nice popularity bonus, which might be helpful in our revival campaign.

Btw:
Yes, using OpenTK directly in monogame is a thing(as in possible, I do not know how popular). I have been working on a game for two months now, and we are using monogame, and even monogame drawing for menus and such, but the actual game is rendered using OpenTK directly. So far it works fine at least on Windows.

[Frassle]

I am usually all for doing our own thing. But having monogame use OpenTK gives us a nice popularity bonus, which might be helpful in our revival campaign.

Agreed. It could also be useful for guiding our short term goals on what they think (as users of OpenTK) is the highest priority things to fix/add.

[glopesdev]

I just found this thread after desperately mining OpenTK.com forums for clues about what's going on with OpenTK... seriously, I think having a new communication hub for OpenTK should be the highest possible priority! I can't even imagine how many people interested in OpenTK must have dropped off just because they couldn't find anything/were not persistent enough...

That said, I'm currently working on an open-source computer vision and audio processing framework that uses OpenTK for both image visualization and audio capture.

I'm reaching the stage where I would like to share the framework in NuGet, and realized that there is already an OpenTK package. This seems to have been built from @andykorth fork by @exDreamDuck. I actually think that being proactive is the best way to get things going, but I would just like to share some views on the NuGet presence:

1. The package was uploaded onto https://www.nuget.org/packages/OpenTK/ with version 1.1. It's important to realize that for all intents and purposes this makes it the official version of OpenTK, as far as NuGet is concerned.
2. Unfortunately, not all components of OpenTK were made available. In particular, I was looking for OpenTK.GLControl, which is still one of the easiest ways to get OpenGL going on Windows Forms.
3. There at least 4 different packages on NuGet that seem to advertise OpenTK: OpenTK; OpenTK Unofficial; OpenTK + Compatibility + GLControl; and OpenTK 1.0 + GLControl.

All of them have varying numbers of downloads, with Unofficial marching ahead with upwards of 2,000 downloads! However, I would expect the OpenTK package to consistently catch up since it holds the official name and icon. NuGet identifiers are unique, and while you can transfer ownership, you can't actually delete packages (just unlist them). So apart from manual intervention from the NuGet crew, no one can get another OpenTK package uploaded with the official name.

I'm fine with this fork being the official release, especially since it seems to be the only OpenTK codebase where something is still happening, but it would be nice if some of the current holes could be plugged in. Namely, I think it would be very useful if someone completes the NuGet release by adding OpenTK.GLControl, (and possibly compat?) as independent NuGet packages that depend on the already released OpenTK package.

With these missing packages in place, there would be even less reasons for other users to download other unknown packages and would establish this fork even more as the de facto distribution of OpenTK.

I also think that OpenTK is too precious a library to die this way, and I'm also available to contribute. I don't know if anyone is currently maintaining the NuGet presence, but I would be happy to help with this specifically.

[jeske]

@glopesdev - it would be helpful if you could join the group I started to discuss picking up the OpenTK torch.

https://groups.google.com/forum/#!forum/opentkr-dev

I posted there about a new binary OpenTK build I posted on github... Can you try this and reply if you have any issues with it? It includes OpenTK.GLControl.dll. If this binary works for you, I'm happy to work to clean up the NuGet situation.

https://groups.google.com/forum/#!topic/opentkr-dev/VdnQXBydgdc

[BenjaminNitschke]

I can continue to support the OpenTK nuget package, we need it for our development anyway (www.deltaengine.net) and we update it quite a lot with our internal needs. The situation is however much different from a few years ago, when fixes were needed every couple of weeks. Now people can work with versions that are 1-2 years old, which are still working fine and stable. Other than that I have to agree with andykorth, OpenTK is not what is was when fiddler was working on it. We do still use it for our Editor and provide users the option to use it, but it is not longer our default framework (GLFW for example is just much smaller, is easier to test with and has a much quicker startup).

I was also asked to support some other nuget packages with dependency to OpenTK. For example some people asked for an updated GLControl with a dependency to the latest OpenTK nuget package I will upload later today when I find some time for it ^^

Also joined that google group

[glopesdev]

Thanks @exDreamDuck :) Actuallly, it was me that asked for the GLControl package via NuGet as well. Great to hear you're still around and thanks again for taking care of this.

By the way, I'm not sure you realized this, but the project website on the OpenTK package points to some creative labs webpage (and not OpenTK) which is actually a dead link...

[Robmaister]

That page was the Creative OpenAL implementation that could be installed for users who didn't have an OpenAL implementation (most of them). A little while ago that site went dead, which is why I opened this issue

[BenjaminNitschke]

The new nuget packages now have been released (I updated to version 1.1.1161, each release needs a new version number):
http://www.nuget.org/packages/OpenTK/
http://www.nuget.org/packages/OpenTKWithOpenAL/
http://www.nuget.org/packages/OpenTK.GLControl/

My fork is also now up to date with andykorth :) There might be some additions from our side that are now merged into it, but more to come in the upcoming months (we just started serious work on 3D and shaders again).

[glopesdev]

That's awesome news, @exDreamDuck! I'll give it a spin later today, thanks so much :-)

Can I make one final suggestion for future releases? Sorry I didn't notice earlier... Could you make OpenTKWithOpenAL depend on OpenTK as well? The reason for this is that if you have to make a reference to a project that just uses OpenTK and one that uses OpenTKWithOpenAL, you'll have to download the OpenTK assembly twice... also helps to keep everything more unified, with the same version, etc.

Thanks again!

[jeske]

Where does your fork live, I don't see it on:

https://github.com/andykorth/opentk/network

FYI, Andy's branch has a bug with windows auxiliary mouse buttons (buttons
4 & 5) which I fixed here:

jeske@8a46bd3

My revision history is a little messy as I'm not yet familiar enough with
git to keep a clean history. However, more fixes and integrations are
present in these trees I'm managing.

https://github.com/jeske/opentk
https://github.com/OpenTKR/OpenTKR

How do folks feel about the merge history, should I redo the merges to
clean it up, or focus on fixes?

P.S. I plan to pull Frassle's UnmanagedArray changes.. I'm just searching
to see if I can find a cleaner way to do the IL injection.

[Frassle]

I'd wait on those for a bit. I'm not totally happy with them. I was planning on working on them this Saturday but I'm still not sure how exactly to accomplish it. I've posted a topic https://groups.google.com/forum/#!topic/opentkr-dev/qKgpfp1YObQ any feedback would be good.

[jeske]

BTW, I've decided to make another branch with cleaner merge history than
the mess whcih is in my current fork at...

https://github.com/jeske/opentk

Along these lines, I've deleted my OpenTKR/OpenTKR repo. I'll recreate it
when I have a cleaner revision history.

On Wed, Aug 28, 2013 at 9:03 AM, David Jeske [email protected] wrote:

My revision history is a little messy as I'm not yet familiar enough with
git to keep a clean history. However, more fixes and integrations are
present in these trees I'm managing.

https://github.com/jeske/opentk
https://github.com/OpenTKR/OpenTKR

How do folks feel about the merge history, should I redo the merges to
clean it up, or focus on fixes?

[BenjaminNitschke]

"Can I make one final suggestion for future releases? Sorry I didn't notice earlier... Could you make OpenTKWithOpenAL depend on OpenTK as well? The reason for this is that if you have to make a reference to a project that just uses OpenTK and one that uses OpenTKWithOpenAL, you'll have to download the OpenTK assembly twice... also helps to keep everything more unified, with the same version, etc."

Actually, it is not that simple, each nuget package needs something in the lib folder, there needs to be a .NET assembly (native only files does not work and you cannot really add this as a reference to your .NET project anyway). We use OpenTK and OpenTKWithOpenAL in all of our OpenTK projects and since they both use exactly the same assembly file, it works fine, no matter how you mix and match them. Normally just one of those should be used in a simple project (we have however some complicated solutions with over 100 projects).

[BenjaminNitschke]

My fork is here: https://github.com/exdreamduck/opentk (I thought it was obvious, just click on a username)
I merged with all the changes in jeske, but I will wait a bit for the next OpenTK nuget update, our team also has some outstanding changes we should merge in the next 1-2 weeks.

[glopesdev]

"Actually, it is not that simple, each nuget package needs something in the lib folder, there needs to be a .NET assembly (native only files does not work and you cannot really add this as a reference to your .NET project anyway)."

Are you sure about this? I'm asking because I've seen packages like OpenCV_binaries that only contain native stuff (dlls and lib files) and you actually can install/uninstall on your project. You're right they won't get added as .NET references, but they were never assemblies to begin with anyway.

I'll try to play around a bit with this tonight, sorry, haven't had much time the last couple of days...

[thefiddler]

@exDreamDuck Would it be possible to commit your nuget script to your repo? I will try to add a nuget target to the build process but I'd like to avoid duplicating any work if at all possible!

[BenjaminNitschke]

Sure, I have added the nuget files into the Installer directory:
https://github.com/exDreamDuck/opentk/tree/master/Installers/nuget

Be careful with merging, I just had some bad merge conflicts. Hopefully all resolved, but my Github for Windows keeps crashing :(

If you need any help with the nuget scripts, let me know. I also put a small Help.txt file in that directory explaining all steps. Good luck.