Dependency Installer

Imho neither OpenTK nor apps built upon OpenTK should be responsible for updating the end-user's drivers, if at all it could be setup.exe's responsibility.

Yep, it should not be OpenTK's responsibility. Just wanted to know some other ppls thoughts on this.

You're right - drivers should be end user / hardware manufacturer / operating system responsibility. But as you mention, oalinst.exe could be silently run during setup.

I guess that's a fundamental difference between OpenGL and OpenAL -- OpenGL is bundled with graphics card drivers, but OpenAL is generally not bundled with sound card drivers..? Or maybe just creatives soundcards?

Yeah.

For windows platform an installer including dotnetfx.exe, oalinst.exe and the game (incl. OpenTK) will be necessary -- and mostly sufficient. Also a big notification "update your graphics drivers" -- maybe with links to NVidia and ATI download pages should make that more convenient for the end user. (actually OpenTK could be used to decide whether the user has a NVidia or an ATI gfx card!)

Anyone out there who would care to describe the situation for ubuntu and mac?

And there no chance of raising OpenAL Soft into the fully managed world - that is including it in the OpenTK source tree? Is it technically possible at all? Is it performance-wise possible?

Yes, I was talking about porting it to C#.

Why is it such a bad idea?

(My guess :
it is quite a hack rewriting such a bit-level-library as OpenAL Soft in C# (with almost equivalent performance), right? I've done some image processing in C#, it's dog slow compared to C. Also big-matrix-operations are like an order of magnitude slower in C# compared to C. Sadly :(
)

Another idea is to prepare a cross-platform installer (in managed code) that would install your application along with the necessary components. It could be written to detect and install missing dependencies, like openal, from the net if download size became a concern.

Yeah that would be a great utility program. Like the windows setup compiler InnoSetup but compiling to a .NET exe instead of a legacy exe.

More complex than InnoSetup since it would include

a) downloading from the internet while doing setup
b) cross-platform driver-detection

But also simpler than InnoSetup since you could skip things like

d) file associations
e) registry access
f) complex scripting

b) could be achieved by using some kind of configuration data, different for each platform.

If the utility is made OpenTK-specific, it would be simplified a great deal.

Also, then the configuration data could be made available as some kind of xml data files on the opentk.net site (somewhere), for example. Then the setup is more-or-less "up-to-date" whenever it is run!

If it is openal that is the only dependency, this is starting to sound practical! Openal could be installed directly into the application folder, and not system-wide. (I know this is true for windows, how about mac/ubuntu?)

One caveat is doing a clean un-install. That differs a lot from platform to platform..

It's an intriguing idea ...

The simplest implementation would just check for the existence of openal32.dll or libopenal.so.1 and download a copy to the app directory if either is not available or is an old version. (This could be extended to cover other unmanaged dependencies that might come up in the future, e.g. libvorbis for decoding audio).

The goal should be "single deployment entity" -- ideally one .zip file. Setup/install seems a whole other story, and requires a lot more work, especially to work cross-platform.

Heading for the stated goal -- what about a little something like this:

GameDir\Run.exe // this is what the user "clicks" or "mono Run.exe"s
GameDir\OpenTKGame.exe
GameDir\OpenTK.dll // of course :)

.. where OpenTKGame.exe is the normal GameWindow application.

Run.exe behaves like this:

1. Checks what platform it's on
2. Downloads* the appropriate openal driver for that platform, to same directory (if it's not already there; no need to download later version since game was developed before that newer version anyway)
3. Runs OpenTKGame.exe

Run.exe only has to be run once. But it does not really hurt to run it twice, since it just finds the OpenAL library instantly anyway.

* it would be good if the download URLs were stored at the opentk.net site, since we have control over that, but not where oalinst.exe is located!

Another brute-force way is adding both OpenAL32.dll and libopenal.so.1 to the .zip in the first place. A little bigger .zip to distribute, a lot less fuzz :]

Regarding the 'installer', there's the problem that you cannot rely on Mono/Net being present on the OS.

This is mostly a problem on WinXP and OSX. Most major Linux distros include Mono by default. Fortunately, WinXP SP3 is probably going to include .Net 2.0, and on OSX it's a simple click to install from mono-project.com.

Unmanaged dependencies are a bit uglier. On Windows, you can place OpenAL Soft's openal32.dll in the app directory, and it will be picked up automatically. Not so on Linux, where DllImport (internally dlopen) picks system-wide libraries in /usr/lib over app-specific ones. It's probably ok if we ask linux users to compile OpenAL Soft (it's very simple). It's probably not ok to ask them to install a new libopenal.so into /usr/lib (this action could break other applications and might confuse the package manager).

The solution probably is to (somehow) change the search path on Linux at runtime - unfortunately I haven't managed to do that yet.

I don't think it's appropriate to ask a "linux user" (that is a very broad term, you know?) to compile openal.

I'm a linux user.
I'm an experienced programmer.
I can very well compile openal to make a casual game work in linux.
Do I want to?

Most definitely NOT.

The most popular and still growing linux distribution is ubuntu. It has finally come to the very sane conclusion that linux users are humans, just as everybody else.

My colleges wife is using ubuntu since half a year ago. She does not know what a compiler is. She could be a potential Dogfight 2008 player. Now do you think she wants to compile openal to play Dogfight 2008? I think the probability is close to 0.

So please, change your minds regarding asking the user to compile dependencies to make a OpenTK based program work on their operating system!

Of course there a still "compile myself"-nerds out there, they will manage anyway! So this discussion should NOT be about them.

Edit: Of course, Ubuntu uses debians package system, so a game could simply require openal. Maybe this is the most sane option in the ubuntu/debian case. It makes installation incredibly simple -- but puts more of a burden on the developer since he/she must get the game into each linux distributions repository. In my case, I'm satisfied if Dogfight 2008 is included in the main ubuntu repository.

Ideally it should be as easy as a setup program for windows.

Problem is, as I see it, the installation/uninstallation procedure differs quite a lot for eg. in windows compared to ubuntu.

In ubuntu and many other linux based operating systems, the package database really stands in the way of a traditional "user downloads setup from a webpage" way of doing things (the windows way, basically).

As a casual games developer I don't see a simple solution to this; maybe we have to give up the dream of "one setup to satify them all".

OpenTK is really great for platform independent *development*, but there are still practical problems to be solved when it comes to platform independent *distribution*.

It think it is great we communicate about these issues.

The problem is: if the user actually needs to run OpenTKDependency.exe, it's guaranteed that (s)he has outdated drivers, because they were never updated. There is little point in writing an App for that, besides telling them what OS they are running *doh* and which graphics card is installed. Imo just direct them to a page with links. We could split the Troubleshooting page by OS into 3 pages total, to avoid confusion.

You must forward the user to Mono or .Net anyways, since this is not guaranteed to be present. Might aswell go 1 step further and ask for updating GL/AL drivers while at it. Sure, this isn't optimal but it's not like this must be done every time you run the App. It might actually be educational, too.

Detecting which vendor built the graphics card isn't really easy, if there's no GL.GetString() available. Even if it is available, it might return 'Microsoft GL 1.1' on windows, which is not helping. A solution could be storing a string[] of DirectX driver names for each vendor and test System.Environment.SystemDirectory for presence of any of those strings. This detection would only work under windows and assumes DirectX drivers to be installed.

Regarding OpenAL Soft, it is not very difficult writing a program that replaces oalinst.exe's functionality, assuming you may add libraries to '/usr/lib/'. Not sure if renaming the library is a good idea though, investigating if the search path under Linux can be changed through System.Environment.GetEnvironmentVariable( "path" ) (and it's SetEnvironmentVariable mutator) might be worth a try. ...but shipping your App with OpenAL drivers isn't ideal either.