Talk:OpenAL

From Wikipedia, the free encyclopedia

Famicom style controller This article is within the scope of WikiProject Video games. For more information, visit the project page, where you can join the project and/or contribute to the discussion.
Start This article has been rated as Start-Class on the assessment scale.
Low This article is on a subject of Low priority within gaming for inclusion in Wikipedia 1.0.
VG To-do:

Would it be better to just list the game engines instead of games used? It'll scale better and is a bit more informative. ENGIMa 04:52, 1 Dec 2004 (UTC)

MaxDZ8 12:27, 28 September 2005 (UTC): I agree with this. There are good reasons to not list games. At best, technology shall be listed. This boils down to Doom3, UnrealTechnology2, Quake3 (merge Q3 and D3 with "id technology"?). I'm not sure about America's Army: Operations, Hitman 2, Freedom Fighters, Psychonauts. Because those are just mere products and doesn't add anything useful, I suggest to just pull em out. Personally I believe this is just mere marketing which is not going to add useful content to wiki.

My proposal is to change The following games make use of OpenAL: Doom 3, Unreal 2, Unreal Tournament 2003, Unreal Tournament 2004, Jedi Knight 2, Jedi Knight: Jedi Academy, Postal 2, America's Army: Operations, Hitman 2, Freedom Fighters, Psychonauts. to Many games used OpenAL, notably those based on Unreal Technology 2 and games from ID-software based engines. Other games also employed this technology.

Considering wiki's policy however, this change will possibly be undone in future. By the way, maybe it's a nice idea to say that first AL implementations were really bad and doppler effects are still broken (if you read last mails on the mailing list, you know how much Creative is done to get it work in 1.1). Please also suggest your opinion on the AL extension issue and the lack of recording. End of message

According to various feedback [here] the list shall be mantained. I disagree with that but I respect Wiki's policy so I've used the compromise solution of grouping everything in a list. This should give us the best of both worlds. MaxDZ8 15:59, 6 October 2005 (UTC)

Anyone interested in a history of development section? Loki, Creative, SWeng, the "lost" OpenAL version of Alpha Centauri? Why the Linux version uses Lisp for its config file? Ah, good times.


I don't think it's right to say that Creative developed OpenAL. They currently host the web site and developer resources - but the original API was developed by Loki in order to port Windows games to Linux - and much of the development work was done by OpenSource enthusiasts and by Apple.

IMHO, the credit in the opening paragraph should go to Loki.

SteveBaker 13:45, 1 February 2006 (UTC)


Contents

[edit] Questionable "Portability" and Other Criticisms

I am not sure if this is appropriate to place in the main page, but OpenAL's "portability" is quite poor in my opinion. Since Creative took hold of OpenAL, development of this library has been pretty much been developed directly for Windows by Creative employees, while the ever dwindling open-source community around OpenAL takes this code and makes it work for Linux, OS X, etc. I do have experience in using the OpenAL library in the development of an audio engine simulatenously across three platforms (Linux, Windows, OS X), and that engine does not fit my definition of "cross-platform" at all in its current state. I make this claim for the following reasons:

  • The trend seems to be that once a new version of OpenAL is released for Windows, the same version is not seen for other platforms for a period of months
  • The library does not behave consistently across platforms for the same version (this is based on personal experience)
  • Documentation for older versions of OpenAL is totally absent from the OpenAL website, despite that those older versions are the most current versions for many systems
  • Function definitions are usually, but not always, consistent across platforms
  • Because of many of the above issues, the source code for a "working" OpenAl engine has to be littered with #ifdef macros to ensure correct operation

I have personally brought these issues forth to the OpenAL community (including Creative) on their mailing list, and no one there refuted my claims.

http://opensource.creative.com/pipermail/openal-devel/2006-April/004278.html

I am not sure if such criticisms (which although stated as my own, are shared by many others) belongs on the main page for this topic, as it may be seen as slanderous or as a non-neutral-point-of-view. But I am interested in discussing a proposal of putting these criticisms on the main page for OpenAL.

--RootsLINUX 03:45, 16 June 2006 (UTC)

Unluckily, mailing lists are to be taken with extra care, especially when you are the one posting in the mailing list, as that can be considered original research. I suggest trying to find reliable sources that verify the suggested information and cite them in the article. We need third-parties to report about this, like CNN, Ars Technica, eWeek, etc. Hope it is a bit clearer now. -- ReyBrujo 04:02, 16 June 2006 (UTC)
(I'm the author of the second revision of the ALUT library that is shipped with the latest versions of OpenAL - so you can't regard me as an NPOV source here!) I agree that since Creative (and to a lesser degree, Apple) took the reins, the main thrust of the development has been in support of Windows...and even more specifically - for Creative's own hardware under Windows. To some degree the API has been directed towards the hardware features that Creative's hardware has. However, in the absence of these two companies, OpenAL was a dead project. There was very little work done on it between Loki's sad demise and Creative picking it up. The Linux version certainly lags the Windows/MacOS versions quite severely and the root cause of that is that there is a separate code base for the two implementations. What really needs to be done to fix this problem is to merge the Linux, MacOSX and Windows versions into a single source base and use conditional compilation for the OS-specific differences. This would tend to make developers think about the impact of their changes on the other platforms rather than (as now) simply diving in and changing code as if no other platforms existed. However, there are quite a few other problems with OpenAL that aren't going to get fixed unless there is a large influx of developers who don't work for either Apple or Creative. OpenGL gets around this commercial driving of the API by having an active ARB composed of hardware vendors, OS developers and application developers. OpenAL's charter says there should be an ARB - but it does not exist and has never met. SteveBaker 14:18, 16 June 2006 (UTC)

[edit] Disagreeing history

http://www.openal.org/openal_vista.html Clearly states that both Creative and Loki started it together, and straight from the horses mouth. -74.118.188.16 17:40, 15 March 2007 (UTC)

[edit] Sound card support

Would it be an idea to list (at least particially) what soundcards do work with OpenAL? If such a list exists, would someone link to it? —Preceding unsigned comment added by 212.130.70.253 (talk) 11:13, 9 September 2007 (UTC)

[edit] Wrong WikiProject?

Why is this in the VideoGames WikiProject? Shouldn't it be, just like OpenGL, in the WikiProject Computing? --DanielPharos (talk) 12:27, 11 May 2008 (UTC)

[edit] EAX?

One thing I've never understood is what the relation between EAX and OpenAL is. Is EAX still an extension to OpenAL? If I'm not mistaken, EAX 2.0 is basically a part of DirectSound3D hence it's supported by many non Creative products. EAX 3.0 - 5.0 are just extensions to DirectSound3D. If it is just an extension, has there been any effort by non Creative developers to "Extensions can be promoted to ARB (Architecture Review Board) status, indicating a standard extension which will be maintained for backwards compatibility. ARB extensions have the prospect of being added to the core API after a period of time." since it would seem to me this would make it easier for them to support EAX 5.0 in their hardware (although they may still have patent issues to contend with) Nil Einne (talk) 17:45, 24 May 2008 (UTC)