Move to OpenAL Soft

[Robmaister]

I don't know when this happened, but for at least a few days, the connect.creativelabs.com domain has disappeared. This site hosted the OpenAL installer and some helpful PDFs. At the moment, the only way to get OpenAL is via those sites that aggregate software (more than half of which just link to the now-dead site) and re-uploads posted on various websites.

Leaving users to get OpenAL this way is a potential security issue. People can modify the re-uploads of the installer to include malicious software.

The Creative implementation is (was?) proprietary anyways, OpenAL Soft is LGPL, which means that we should have no problem redistributing in binary format.

I'm going to be very busy these next few weeks, otherwise I'd do it myself and just submit it as a pull request. It shouldn't be too hard, though. OpenAL Soft is supposed to be a drop-in replacement.

OpenAL Soft website

[jeske]

I think this begs the bigger question of whether OpenTK should distribute native binaries, or be dependent on any non-system binaries. Personally I like that OpenTK is a managed-only cross-platform implementation.

Come help us figure out what to do with this on OpenTKR-dev:

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

[Robmaister]

I was thinking a little bit more along the lines of distributing with the installer, so as to avoid an exception being thrown immediately for any Windows users without OpenAL installed.

[jeske]

OpenTK is a library for developers. IMO, how it is distributed is less important than how apps built using it are distributed.

Today I can build a 3d program using OpenTK-GL and GameWindow on Mac, zip it with the platform neutral OpenTK.DLL, unzip it on windows (32bit or 64bit), and it runs. It's a CLR-only cross-platform solution.

OpenTK-AL already breaks this on windows, because windows doesn't come with OpenAL. Personally I'd like to fix this and make OpenTK a 100% CLR cross-platform solution for Audio as well. This would mean either implementing OpenAL in CLR (mapping to whatever native libraries are available), or removing OpenAL and supporting a simpler Audio abstraction which can be made cross platform.

@jeske I totally agree with you. It would be nice to keep OpenTK as complete (enabling Graphics, Audio and Window management) and as independent (cross-plattform and no third-party libraries) as possible.

[Robmaister]

The installer already downloads OpenAL and (optionally) NShader, I don't know if anyone is going to really ever use that again, but I was saying we should update that:

https://github.com/andykorth/opentk/blob/master/Installers/Nsis/opentk.nsi#L180

OpenAL Soft is a package on most linux distros, but I'm not sure where OS X stands. If OS X has a built-in OpenAL implementation, I think it's cross-platform enough for our use.

Writing a CLR implementation of OpenAL would, IMO, be a large enough project to be considered it's own library. And as far as cross-platform audio libraries, everything else I've seen is either worse or on equal footing with OpenAL in terms of being commonly installed/portable. Assuming OS X doesn't have OpenAL, PortAudio is equally portable, binaries would have to be distributed on Windows and OS X, and it is a package on most Linux distros.

[Sappharad]

OpenAL comes with OS X, and has for as long as I remember. It just works out of the box with OpenTK, at least that has been my experience.

On Aug 15, 2013, at 2:58 AM, Robert Rouhani notifications@github.com wrote:

The installer already downloads OpenAL and (optionally) NShader, I don't know if anyone is going to really ever use that again, but I was saying we should update that:

https://github.com/andykorth/opentk/blob/master/Installers/Nsis/opentk.nsi#L180

OpenAL Soft is a package on most linux distros, but I'm not sure where OS X stands. If OS X has a built-in OpenAL implementation, I think it's cross-platform enough for our use.

Writing a CLR implementation of OpenAL would, IMO, be a large enough project to be considered it's own library. And as far as cross-platform audio libraries, everything else I've seen is either worse or on equal footing with OpenAL in terms of being commonly installed/portable. Assuming OS X doesn't have OpenAL, PortAudio is equally portable, binaries would have to be distributed on Windows and OS X, and it is a package on most Linux distros.

—
Reply to this email directly or view it on GitHub.

[jeske]

For me, OpenTK-GL is currently filling a niche more like Java3D, where the same single EXE/DLL directory runs on Mac/Windows with no native libs and no requirements to install native libs. To extend this capability, I'd prefer to add basic cross-platform audio and less game centric window support, more like GLUT/Ghost/EGL.

That said, I am drawn by the alure of including and wrapping more native libraries, such as bullet physics and OpenVDB -- more like Tao does, but in a more managed friendly interface like OpenTK.

Perhaps a good route would be to draw a line of separation between a cross-platform profile OpenTK-portable (OpenGL, GameWindow, GLUT/Ghost-ish windows, newly built basic Audio), and a per-platform native libraries profile OpenTK-native (OpenAL, OpenCL, ODE, Bullet, OpenVDB, etc).

[Robmaister]

Technically OpenGL still needs you to install native libraries on Windows/Linux. (I understand that Windows comes with an OpenGL 1.1 implementation, but it's unusable for anything beyond a single spinning cube).

Telling a Windows user to install OpenAL is essentially the same as telling them to install their graphics card drivers. Personally, I think writing your own audio abstraction library is a massive waste of time to avoid shipping/telling users to install a single binary on Windows.

As for where the line is drawn, I think that the it should be drawn at Khronos-style APIs parsed from .spec files. As I mentioned in the mailing list, other libraries are structured differently and may be better served by exposing a different type of API on the C# side. For example, with SharpFont, I could have just exposed a static FT class with properly stylized names and enums, and I did in the beginning, but I found that FreeType is essentially an object-oriented API made to work with C structs, so I made my API expose objects with instance methods that chain off to the extern functions.

I personally think all those other libraries would work better as separate libraries. But if we do decide to include a lot of other libraries, I think it would be best that they be split into separate assemblies, possibly with a common assembly that includes the math classes and a few helper classes. If that happens, I'd be happy to merge in my FreeType wrapper as part of OpenTK.

And unless I'm mistaken, OpenCL should be included in OpenTK-portable as well since graphics card drivers now include an OpenCL implementation (though I've really been able to test on NVIDIA, so that may not be true for AMD/Intel).

[jeske]

Good points about OpenGL driver installs. You've convinced me my cross-platform aspirations are too aggressive.

Stepping back a bit, I think it should be easy to distribute OpenTK apps in a self-contained way for supported desktop platforms (mac/windows/linux). In this sense, redistributable native libraries like OpenAL-Soft are easy, since OpenTK and the end-app can install them... It's the non-redistributable stuff, like the raw OpenGL drivers which we'll have to prompt the user to install on their own. I'll have to think on this a bit, but I like that this creates a clear path to include things like ODE, OpenVDB, SharpFont, and others (as separate and nicely wrapped assemblies).

On a related note, I can see the sense of MonoGame providing XNA and mapping that down to whatever is available. This way they can map XNA's slightly simpler model down to whatever is on the platform. I wonder if there would be value to sharing a cross-platform managed window binding (like GLUT/EGL/Ghost) which could allow MonoGame/XNA to branch out beyond a "game window".

[renanyoy]

it seems you forget the primary targets that are iOS and Android
devices, computers are the devices of the past...

regards,
renan

On 16/08/13 06:29, David Jeske wrote:

Good points about OpenGL driver installs. You've convinced me my
cross-platform aspirations are too aggressive.

Stepping back a bit, I think it should be easy to distribute OpenTK
apps in a self-contained way for supported platforms
(mac/windows/linux). In this sense, redistributable native libraries
like OpenAL-Soft are easy, since OpenTK and the end-app can install
them... It's the non-redistributable stuff, like the raw OpenGL
drivers which we'll have to prompt the user to install on their own.
I'll have to think on this a bit, but I like that this creates a clear
path to include things like ODE, OpenVDB, SharpFont, and others (as
separate and nicely wrapped assemblies).

On a related note, I can see the sense of MonoGame providing XNA and
mapping that down to whatever is available. This way they can map
XNA's slightly simpler model down to whatever is on the platform. I
wonder if there would be value to sharing a cross-platform managed
window binding (like GLUT/EGL/Ghost) which could allow MonoGame/XNA to
branch out beyond a "game window".

—
Reply to this email directly or view it on GitHub
#18 (comment).

renan jegouzo (YoY)
software developer
email: renan@aestesis.org
web: http://aestesis.net/

[jeske]

I'm not forgetting mobile, it's just not why I use OpenTK. My need for OpenTK is very desktop centric. I think it's going to be quite a while before mobile-operating systems replace computers for 3d modeling and other 3d content authoring.

Also, WRT this discussion, all the dependency issues are moot for mobile, since it's basically embedded system development.

[renanyoy]

the thing, it's not what you do, it's what users do.
In few years, computers will only by used by IT engineers,
and handset, tablets, TV by final users.

me I use OpenTK in all my projects for all targets.
iOS, Android, OSX, Linux..
I made my own GUI. So I program once, build everywhere.

renan

On 17/08/13 08:45, David Jeske wrote:

Are these primary targets for OpenTK?

I do mobile development, but not with OpenTK.

—
Reply to this email directly or view it on GitHub
#18 (comment).

renan jegouzo (YoY)
software developer
email: renan@aestesis.org
web: http://aestesis.net/

[paulcscharf]

I think you have to support your statements regarding target platforms some more in this company. I also use OpenTK for Desktop-Development only at the moment.

And I also do not think that the usage of PCs will decline in the future. Certainly, things may change, but I am thinking of the steambox for example, which will bring the PC to the living room as gaming platform (and I would say there is a good chance of doing so successfully, knowing Valve.)

On another point, I would second that any revival project should not start including other libraries in the core of OpenTK. To me, getting the existing features to work on all platforms, and fixing any issues with them has a much higher priority.

[renanyoy]

I just says that for now OpentTK works well on Android and iOS, and I
don't understand why you plan to abandon this targets,
when you talk about the future of OpenTK.

renan

On 17/08/13 10:15, amulware wrote:

I think you have to support your statements regarding target platforms
some more in this company. I also use OpenTK for Desktop-Development
only at the moment.

And I also do not think that the usage of PCs will decline in the
future. Certainly, things may change, but I am thinking of the
steambox for example, which will bring the PC to the living room as
gaming platform (and I would say there is a good chance of doing so
successfully, knowing Valve.)

On another point, I would second that any revival project should not
start including other libraries in the core of OpenTK. To me, getting
the existing features to work on all platforms, and fixing any issues
with them has a much higher priority.

—
Reply to this email directly or view it on GitHub
#18 (comment).

renan jegouzo (YoY)
software developer
email: renan@aestesis.org
web: http://aestesis.net/

[paulcscharf]

Oh, as far as I understand, nobody is doing that.
In fact, in the google group that jeske created the other day ( https://groups.google.com/forum/#!forum/opentkr-dev ) Android and iOS support is also mentioned.

I think it is simply not the main concern right now, given that there are more serious ones, for example regarding OSX and OpenCL.

So, while we are certainly keeping the mobile platforms in mind, it is just not relevant for this discussion, so no worries!