objarni's picture

Dependency Installer

[Move Reason: Completely unrelated to the bookpage. Driver problems have no place in the book. Use the FORUM for discussions/support. Thank you! -Inertia]

I get "alut.dll not found" errors with OpenTK0.9, when trying out a simple Alut.Init() windows application.

Do I have to have alut.dll besides the .exe after all..?

What is your approach when it comes to availability of OpenAL implementations on different OSs?

I mean, it is quite safe to assume some kind of OpenGL implementation on Windows / ubuntu.

But what is the situation for OpenAL? I just found out I didn't have the necessary .dll for OpenAL (OpenAL32.dll) on my WinXP SP2 box (home development/game box so it contains quite a lot of stuff, but not OpenAL..).

Should I ship my game with OpenAL drivers for the different operating systems or what is your suggestion?


Comments

Comment viewing options

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

It depends on how Mono searches for the DllImport-ed libraries. I haven't tried it yet (I'm building OpenAL Soft to test this as we speak), but I think it would work.

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 most complicated solution would pack everything (your app, OpenTK and other managed and unmanaged dependencies) in a single installer executable. This would be difficult to get right (a lot of testing will be needed!), but it would be awesome.

I'd be conent with the simple implementation for now. Any takers..? :)

objarni's picture

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 :]

Inertia's picture

[Linux]
we can ask users to compile and install OpenAL Soft manually (ugly), or try to find another means to ship this.

I believe everyone who is running Linux is aware that it's not as convenient as Apple's or Microsoft's OS. Sure, the recent distributions make it less complicated to set up, but one of the main points why people use Linux is that they wish to have more control over the OS and not so much to 'happen behind the curtains'.
This implies that you have to build from source too, somehow I doubt that many users will complain about it.

Regarding the 'installer', there's the problem that you cannot rely on Mono/Net being present on the OS. It might be the best course of action to use some web-based technology (I really, truely have never looked into building websites so this is just a guess, but I assume it is doable since there are web-based system scanners etc.) and send the user to the webpage to identify the system's drivers and offer options to upgrade. This is most likely doable with Java.

For the time being, the troubleshooting page in the book should be sufficient though.

the Fiddler's picture

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.

Inertia's picture

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).

How about setting up the dll.config to use libopenalsoft.so instead of libopenal.so? Then the search in /usr/lib/ will fail, and the library can be placed in the application's directory. Sorry if that's a stupid suggestion, but it would for sure not confuse the package manager, and is not invasive. The bad thing about this is, every OpenTK app using AL must ship with libraries.

How about placing libopenalsoft.so in /usr/lib/ and make that OpenTK's default in dll.config? (Not sure if the package manager only checks his internal list of filenames, or the whole directory)

objarni's picture

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.

Inertia's picture

This program would have to fulfill these tasks?

  • Figure out if OpenAL drivers are present. Figure out the driver version. Copy from URL if any of those are not satisfactory.
  • Figure out if there is an HW accelerated OpenGL driver. Figure out vendor. Figure out version. Open webbrowser to respective Vendors download page if not satisfactory.
  • Show user the EULA. Exit if user doesn't agree to terms.
  • Prompt user for path. Check for available diskspace. Create directories if necessary. Copy App to desired location.
  • Ideally 1 file.
  • Ideally self-compression. (not relying on 3rd party programs)
  • Should be SSU proof.

anything else?

objarni's picture

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.

objarni's picture

What would be great, at least for developers using OpenTK, is a utility program that collects the information of the system it is run on, and recommends updates, just as you say Inertia.

1. Run OpenTKDependency.exe (suggested name; it's a .NET executable)
2. It checks your system
3. It reports recommended updates to your system in order to develop OpenTK programs eg. via a HTML-generated page with links

This is really an automation of the Troubleshooting page :)

Edit: it should not install anything automatically, just recommend things.

Inertia's picture

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.