Windows

OpenTK does not come with any installer or setup. Instead, you download the OpenTK binaries and add a reference to "OpenTK.dll" in your Visual Studio/SharpDevelop/MonoDevelop project. (Unzip the binaries first!)

OpenTK demo
To run all of the OpenTK builtin examples, the following software is required:

  1. .NET2.0 or Mono 1.2.6
  2. OpenAL 2.0.3

This is also the software required for an end-user running an OpenTK application. Note that OpenAL is not strictly required if the application does not use any sound.

OpenTK development
If you want to start developing applications using OpenTK, first make sure the items under "OpenTK demo" are installed, then download a compiler/IDE for .NET/mono. Here are some popular choices:

  1. SharpDevelop
  2. MonoDevelop (bundled in the mono installer)
  3. Visual Studio Express

Setting up an OpenTK application in Visual Studio Express
It is a good idea to add "OpenTK.dll.config" to your project, and make sure the "Copy To Output Folder" (not "compile"!) is set to "Copy Always". The application will run without this on Windows, but not on Linux or Mac OS X.

Last, but not least, make sure the "Copy Local" property is set to true for the OpenTK reference, to simplify the distribution of your application.

Setting up an OpenTK application in SharpDevelop
Include the "OpenTK.dll.config" in your project, if you want it to run under Linux Mac OS X.
Visual explanation:

OpenTK References on SharpDevelop

Comments

Comment viewing options

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

Has there been any thought/discussion about unifying the behaviour on different platforms regarding OpenTK.dll.config, if that is possible technically? What I mean is, OpenTK will work under window without OpenTK.dll.config. Under Linux, OpenTK will crasch without it.

I would prefer the following behaviour:

1) OpenTK requires OpenTK.dll.config to reside beside OpenTK.dll upon "boot" or something (static constructor in GL or somewhere appropriate), or else an exception is thrown "Could not find 'OpenTK.dll.config', please make sure it is placed in the same folder as 'OpenTK.dll'"

The reason behind this is making platform-independent development easier.

This very basic thing had me looking for bugs in my code one or two nights. With the above exception it would have been avoided... :)

the Fiddler's picture

Checking for the existence of the file is not trivial however: what happens for example when the execution path is different than the one where OpenTK.dll resides?

Depending on how dll.config files are loaded by Mono, it might also be possible to generate these at runtime. I am not sure if this is possible, but it would be pretty nice if it were.

In any case, this stuff is not high priority at the moment. More robust handling of the dll.config files would be nice, so I'll check what can be done.

objarni's picture

Checking for the existence of the file is not trivial however: what happens for example when the execution path is different than the one where OpenTK.dll resides?

Well assuming the case

SomeFolder/Game.exe
SomeFolder/OpenTK.dll
SomeFolder/OpenTK.dll.config
[where SomeFolder = bin/Debug almost always]

.. would fix 99% of the cases I guess. [At least I don't like to install things into the GAC, to ease deployment of my projects.]

Generating the file at runtime would be another good (better!) solution, if it is possible and robust enough.

This is a usability issue, not really a "feature". I can understand usability has low priority in an early, feature-drained library. But how many more features are there left for OpenTK..? Once fullscreen is complete, it's almost feature complete IMHO.

After all, on the front-page of opentk.net, OpenTK is claimed to "Just work". Does OpenTK want to live up to that or not..? Usability is at the heart of OpenTK! :)

Sorry for being so rant-ish, but I think usability is important!

the Fiddler's picture

Well assuming the case

SomeFolder/Game.exe
SomeFolder/OpenTK.dll
SomeFolder/OpenTK.dll.config
[where SomeFolder = bin/Debug almost always]

.. would fix 99% of the cases I guess. [At least I don't like to install things into the GAC, to ease deployment of my projects.]
Agreed. However, what would happen if the structure was like:

/Launcher.exe
/bin/Game.exe
/bin/OpenTK.dll
/bin/OpenTK.dll.config?

If Launcher.exe does not change the working directory when spawning Game.exe, detection might fail! (though I guess that would be better than no detection at all)

Generating at runtime would be the best solution, yeah, if it can be made robust enough (and this is a big if, as dll.configs weren't meant to be used this way). It mostly depends on when Mono parses the file (do we get a chance to change it?) and how (can we generate it in memory or in a temp directory?) As far as I can see, noone has tried to do this before - or if he has, he hasn't documented it somewhere.

Regarding features, the main missing ones are fullscreen, joystick and Mac OSX support. We then have general usability issues (like this), addon functionality (e.g. audio/texture/model loaders) and bugfixes. This is high in the priority list, mainly because it is annoying (hey, I tend to forget the dll.config file myself!), but the workaround is simple enough that I haven't bothered to work on it yet.

the Fiddler's picture

Ok, more info. The dll.config file is loaded along with the dll, but only if it exists. Which means we need a way to run code when OpenTK.dll is first loaded - do you know of any way to do this?

The other solution would be to study Mono's source to see what it does, and use reflection to alter that. This leaves the possibility that future versions might break this code, so the first solution would be preferrable.

Edit:
Ok, even more info: it is possible to generate the config file at runtime. It can be written to ~/.mono/assemblies/OpenTK/OpenTK.config and Mono will pick it up automatically. 0.9.2+ won't need the dll.config file anymore :)

objarni's picture

Great news Fiddler!

Then OpenTK.dll is completely self-contained from 0.9.2? Cool cool cool.

objarni's picture

By Inertia's request, I'm adding my "solution layout snippet" here.

This is the way I structure my solutions on my hard drive:

Game.sln                   // in the root, no other file here
ThirdParty/OpenTK.dll|xml  // and other dependencies, structured into subfolders if many
Project1/Project1.csproj
Project1/MyClass.cs
Project2/Project2.csproj
Project2/MyOtherClass.cs

.. and then in the projects, I add references to OpenTK.dll getting IntelliSense. Be careful when Project1 references Project2: make sure it is referenced via the "Projects" tab.

This way all paths in the .sln and .csproj's are relative. I hate absolute paths, they've given me my share of headache in my developer life...

I don't worry so much that OpenTK.dll or other dll's exist in multiple places on my hard drive, after all they're local to each and every solution so it's very easy to manage. Hard drives are cheap, developer time is expensive..