Hello Tatsuhiro !
I'd like to thank you for this cool patch and the tips. Now I have
OpenAL working.
However, I continue making some kind of ALUT-less solution for SimGear.
Thanks again!
Vladimir
On Oct 20, 2008, at 6:48 PM, Tatsuhiro Nishioka wrote:
Hi,
Here's my old patch to include
On 20 Oct 2008, at 10:06, Vladimir Karmishin wrote:
I'm trying to compile Flightgear from CVS at OSX 10.5 systems.
It seems the 10.5 lacks of alut.h header. After a little google-ing, I
found that
Apple removed that haader from leopard (Thanks, Apple!).
Through, I'd found freealut
Hi James !
Thank you for fast and informative answer.
I guess, rewriting of wav file handling can be only difficult thing
in removing ALUT away from FG. In fact, there only 4 ALUT
functions FG uses. Initializing, Destroying and opening-closing
streams. The implementation of first two is a piece
On 20 Oct 2008, at 13:06, Vladimir Karmishin wrote:
Thank you for fast and informative answer.
I guess, rewriting of wav file handling can be only difficult thing
in removing ALUT away from FG. In fact, there only 4 ALUT
functions FG uses. Initializing, Destroying and opening-closing
Vladimir Karmishin wrote:
As I see around - the more and more of projects are moving
away from ALUT, and probally FG has to do it some time.
So, why not to start movement process now :-)
I find it rather annoying to have to move away from ALUT just because
Apple can't play nice. Bad for
* Erik Hofman -- Monday 20 October 2008:
I find it rather annoying to have to move away from ALUT just because
Apple can't play nice. Bad for them, let them straighten it out if they
don't obey the the specs. I vote against this.
The problem seems to be that the original (Creative) OpenAL
Melchior FRANZ wrote:
* Erik Hofman -- Monday 20 October 2008:
I find it rather annoying to have to move away from ALUT just because
Apple can't play nice. Bad for them, let them straighten it out if they
don't obey the the specs. I vote against this.
The problem seems to be that the
On 20 Oct 2008, at 15:30, Erik Hofman wrote:
The main problem is that Apple never removed the alut functions from
their OpenAL library causing linking conflicts wehn linking both
freealut and OpenAL.
Well, to be fair that's to preserve binary compatibility. I work
around that trivially be
Eric, the only problem with ALUT - it is not a part of OpenAL, and
it doesn't have any strict specs. So nobody can guarantee it's reliability.
In fact, I have to agree with Melchior FRANZ, about the whole OpenAL
subsystem. Since Creative abadoned the development - it's completely dead.
FMOD seems
Vladimir Karmisin wrote:
Eric, the only problem with ALUT - it is not a part of OpenAL, and
it doesn't have any strict specs. So nobody can guarantee it's reliability.
In fact, I have to agree with Melchior FRANZ, about the whole OpenAL
subsystem. Since Creative abadoned the development -
James Turner wrote:
On 20 Oct 2008, at 15:30, Erik Hofman wrote:
The main problem is that Apple never removed the alut functions from
their OpenAL library causing linking conflicts wehn linking both
freealut and OpenAL.
Well, to be fair that's to preserve binary compatibility. I work
James, if it doesn't mean problem for you, could You send me your framework
and SG patches ?
About libsnd - Yes, you may be right in case of libsndfile. I've coded a
simple WAV reader,
which does nothig but read uncompressed wav file and fill out OpenAL buffer
by PCM data.
The whole code is about
On 20 Oct 2008, at 16:02, Vladimir Karmisin wrote:
James, if it doesn't mean problem for you, could You send me your
framework and SG patches ?
Yep, I'll get them sent when I have a spare moment (maybe tomorrow,
however)
About libsnd - Yes, you may be right in case of libsndfile. I've
Vladimir Karmisin wrote:
James, if it doesn't mean problem for you, could You send me your
framework and SG patches ?
About libsnd - Yes, you may be right in case of libsndfile. I've coded a
simple WAV reader,
which does nothig but read uncompressed wav file and fill out OpenAL
buffer
On Oct 20, 2008, at 6:26 PM, Erik Hofman wrote:
Vladimir Karmisin wrote:
James, if it doesn't mean problem for you, could You send me your
framework and SG patches ?
About libsnd - Yes, you may be right in case of libsndfile. I've
coded a
simple WAV reader,
which does nothig but read
Hi,
Here's my old patch to include local alut.h into SimGear.
http://macflightgear.svn.sourceforge.net/viewvc/macflightgear/trunk/patches/SimGear-0.3-cvs-20061203-MacOSX.diff?revision=168view=markup
This will place alut.h inside SimGear. (Not inside OpenAL.framework)
You can modify this patch to
Vladimir Karmishin wrote:
Erik, it's just a simple startup code right now. Written only for test
purposes for myself.
Of course, if I feel I want to get it included in FG I'll polish it
and take a care
of endiannes. But thanks you for the care :-)
Actually I do have code laying around
On Oct 20, 2008, at 7:09 PM, Erik Hofman wrote:
Actually I do have code laying around that does exactly that but it
can
only read so called canonical wave files, meaning the layout should be
exactly like that otherwise it will fail (meybe even coredump).
I find that much too limited for
18 matches
Mail list logo
