Re: [Flightgear-devel] PATCH Suggested configure.ac changes/improvements affecting mac users
Jari Häkkinen wrote: Ideally for macs, alut should be removed altogether but that is probably not an viable option. The second best option would be to include alut I disagree, alut has one important feature: it supports all supported WAV files on all supported platforms. So if the audio works on the development platform it'll work everywhere. No surprises that some plane doesn't work on Macs. And that's the reason I would go for FreeALUT, it supports more compression types: raw, ulaw, alaw and adpcm. function declarations for the 5 backward compatibility function in the Apple OpenAL framework in soundmgr_openal.hxx (or cxx if they does not need to be exposed, alut is only used in soundmgr_openal.cxx, I think ... I still have a lot of fg code to read). Is there planned increased use of alut functionality? If not, then the choice is a no-brainer. A No, In fact I've removed some alut functionality in the overhauling process. Erik -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] alcinfo compile problem
I can't compile alcinfo: cc -DHAVE_CONFIG_H -I. -I../../../flightgear-complete/tests -I../src/Include -I/home/moore/graphics/fg/cvs-integrate/local/include -I/usr/local/include -g -O2 -D_REENTRANT -MT alcinfo.o -MD -MP -MF .deps/alcinfo.Tpo -c -o alcinfo.o ../../../flightgear-complete/tests/alcinfo.c ../../../flightgear-complete/tests/alcinfo.c: In function ‘main’: ../../../flightgear-complete/tests/alcinfo.c:62: error: ‘ALC_ALL_DEVICES_SPECIFIER’ undeclared (first use in this function) ../../../flightgear-complete/tests/alcinfo.c:62: error: (Each undeclared identifier is reported only once ../../../flightgear-complete/tests/alcinfo.c:62: error: for each function it appears in.) ../../../flightgear-complete/tests/alcinfo.c: In function ‘testForError’: ../../../flightgear-complete/tests/alcinfo.c:320: warning: incompatible implicit declaration of built-in function ‘exit’ This is on Fedora 11, with openal 0.9-0.17. Tim -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] alcinfo compile problem
Tim Moore wrote: I can't compile alcinfo: cc -DHAVE_CONFIG_H -I. -I../../../flightgear-complete/tests -I../src/Include -I/home/moore/graphics/fg/cvs-integrate/local/include -I/usr/local/include -g -O2 -D_REENTRANT -MT alcinfo.o -MD -MP -MF .deps/alcinfo.Tpo -c -o alcinfo.o ../../../flightgear-complete/tests/alcinfo.c ../../../flightgear-complete/tests/alcinfo.c: In function ‘main’: ../../../flightgear-complete/tests/alcinfo.c:62: error: ‘ALC_ALL_DEVICES_SPECIFIER’ undeclared (first use in this function) ../../../flightgear-complete/tests/alcinfo.c:62: error: (Each undeclared identifier is reported only once ../../../flightgear-complete/tests/alcinfo.c:62: error: for each function it appears in.) ../../../flightgear-complete/tests/alcinfo.c: In function ‘testForError’: ../../../flightgear-complete/tests/alcinfo.c:320: warning: incompatible implicit declaration of built-in function ‘exit’ This is on Fedora 11, with openal 0.9-0.17. Thanks, this is fixed now. Erik -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] AS332 into CVS?
Hi CVS I was working on a Aerospatiale AS332 for some months. Now I reconfigured the FDM with help of HHS and Maik Justus. There is still some work to do, of course. But the as332 has a model, a FDM and some basic instruments/animation and is now ready for basic test/use. I wish to see it in the CVS ... is there someone who can put it into CVS? Recent file is here: http://www.divshare.com/download/9545837-0a5 Thank you for your answer, Yves S. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: source/src/Main main.cxx, 1.306, 1.307 options.cxx, 1.128, 1.129
On 30 Nov 2009, at 14:24, Erik Hofman wrote: Modified Files: main.cxx options.cxx Log Message: update to allow selection of a new sound device Nice work! And the preference / settings changes too - I know this is painful work, but it's long overdue and will really help make using FG more pleasant for lots of people. Incidentally, I am currently cursing Apple's OpenAL implementation, it only supports the default input and output devices - despite 'supporting' the enumeration extension. I have a patch to iaxclient (as used by fgcom) to allow input and output device selection for the openAL backend, but it's completely pointless on Mac, without patches to OpenAL itself :( James -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Runtime selection of sound device
James Turner wrote: Nice work! And the preference / settings changes too - I know this is painful work, but it's long overdue and will really help make using FG more pleasant for lots of people. Thanks, It's not yet perfect but already usable as it is. Incidentally, I am currently cursing Apple's OpenAL implementation, it only supports the default input and output devices - despite 'supporting' the enumeration extension. I have a patch to iaxclient (as used by fgcom) to allow input and output device selection for the openAL backend, but it's completely pointless on Mac, without patches to OpenAL itself :( That's sad. Erik -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Runtime selection of sound device
Erik Hofman James Turner wrote: Nice work! And the preference / settings changes too - I know this is painful work, but it's long overdue and will really help make using FG more pleasant for lots of people. Thanks, It's not yet perfect but already usable as it is. Incidentally, I am currently cursing Apple's OpenAL implementation, it only supports the default input and output devices - despite 'supporting' the enumeration extension. I have a patch to iaxclient (as used by fgcom) to allow input and output device selection for the openAL backend, but it's completely pointless on Mac, without patches to OpenAL itself :( That's sad. That all seems to work pretty well, but where or when did we lose or where did we put the menu item which enables us to select various views? On a different subject, I get a crash on reset here on a completely repeatable basis. I get this message: trying to sequence waypoints with no active route Then FG crashes and exits rather than resets in: fgfs.exe!SGPropertyNode::set_string(const char * val=0x1c096528) Line 491 + 0x12 bytes Vivian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Runtime selection of sound device
The Apple OpenAL implementation is open source, btw. http://developer.apple.com/audio/openal.html#anchor3 On Mon, Nov 30, 2009 at 9:51 AM, Erik Hofman e...@ehofman.com wrote: James Turner wrote: Nice work! And the preference / settings changes too - I know this is painful work, but it's long overdue and will really help make using FG more pleasant for lots of people. Thanks, It's not yet perfect but already usable as it is. Incidentally, I am currently cursing Apple's OpenAL implementation, it only supports the default input and output devices - despite 'supporting' the enumeration extension. I have a patch to iaxclient (as used by fgcom) to allow input and output device selection for the openAL backend, but it's completely pointless on Mac, without patches to OpenAL itself :( That's sad. Erik -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgfs sound crystal clear /w pulseaudio in FC12
Hi Erik, For any Fedora users, I recommend preupgrade to FC12. All the fgfs sounds work and are crystal clear, no crackle! This includes ATC, ATIS, vor and loc ident, marker beacons, cockpit sounds (switch clicks, flaps, etc.). I encountered several potential gotchas: 1. If you have an NVIDIA graphics card, before you begin, print the info from the following link: http://linuxsoftwareblog.com/blog/?p=232 2. Clean up /boot before you start preupgrade. Delete all but the most recent kernel files. If you do this, a 200 MB /boot is big enough. 3. Do a sudo yum upgrade before running preupgrade. 4. Be ready with a fedora DVD for a rescue. After preupgrade completes, and the system is rebooted, you may need to edit /etc/inittab to boot into run level 3. 5. The info from the link in #1 should allow you to get nvidia driver support. I use the driver from www.nvidia.com, so only the first item was required to allow the nouveau module to release control so the install could proceed. Hope this helps others. Thanks Erik for staying on this! Regards, Dave P. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs sound crystal clear /w pulseaudio in FC12
On 11/30/2009 09:44 AM, dave perry wrote: Hi Erik, For any Fedora users, I recommend preupgrade to FC12. All the fgfs sounds work and are crystal clear, no crackle! This includes ATC, ATIS, vor and loc ident, marker beacons, cockpit sounds (switch clicks, flaps, etc.). I encountered several potential gotchas: 1. If you have an NVIDIA graphics card, before you begin, print the info from the following link: http://linuxsoftwareblog.com/blog/?p=232 2. Clean up /boot before you start preupgrade. Delete all but the most recent kernel files. If you do this, a 200 MB /boot is big enough. 3. Do a sudo yum upgrade before running preupgrade. Should read 3. Do a sudo yum update before running preupgrade. 4. Be ready with a fedora DVD for a rescue. After preupgrade completes, and the system is rebooted, you may need to edit /etc/inittab to boot into run level 3. 5. The info from the link in #1 should allow you to get nvidia driver support. I use the driver from www.nvidia.com, so only the first item was required to allow the nouveau module to release control so the install could proceed. Hope this helps others. Thanks Erik for staying on this! Regards, Dave P. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs sound crystal clear /w pulseaudio in FC12
On Mon, Nov 30, 2009 at 10:44 AM, dave perry wrote: For any Fedora users, I recommend preupgrade to FC12. All the fgfs sounds work and are crystal clear, no crackle! This includes ATC, ATIS, vor and loc ident, marker beacons, cockpit sounds (switch clicks, flaps, etc.). Ok, I'm definitely going to have to try upgrading here ... I encountered several potential gotchas: 1. If you have an NVIDIA graphics card, before you begin, print the info from the following link: http://linuxsoftwareblog.com/blog/?p=232 2. Clean up /boot before you start preupgrade. Delete all but the most recent kernel files. If you do this, a 200 MB /boot is big enough. 3. Do a sudo yum upgrade before running preupgrade. 4. Be ready with a fedora DVD for a rescue. After preupgrade completes, and the system is rebooted, you may need to edit /etc/inittab to boot into run level 3. If you boot up and the X11 graphics fail to start (because of some degenerate combination of left over nvidia drivers and libs that didn't play well with the default X11 stuff from the upgrade.) You should be able to hit Alt-F2 to get a text login prompt. I have always installed the nvida drivers using the .sh file downloaded directly from the nvidia site, so at this point you can just login as root and sh NVIDIA.sh to install/freshen the drivers. Then you can run init 3 to kill X11 followed by init 5 to startup again. You shouldn't need the install dvd to do this. Also at the boot prompt you should be able to add the single option to boot up in single user mode with no graphics. There is also emergency mode which boots up with the root partition mounted read only ... but a good admin can quickly remount it rewrite. :-) (something like mount -o rw, remount / but it's been a while.) 5. The info from the link in #1 should allow you to get nvidia driver support. I use the driver from www.nvidia.com, so only the first item was required to allow the nouveau module to release control so the install could proceed. Hope this helps others. Thanks Erik for staying on this! Regards, Dave P. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] November 2009 FlightGear News letter
Hi, another month's over (we ignore the 2 hours to go), another newsletter is finished. Thanks to all contributors for their contributions! Especially Vivian for his detailed AI paragraphs. Read the November Newsletter The letter has been locked for edits, but corrections can still be made by Simon and me. Please let us know if any typo's/mistakes draw your attention. Next months newsletter can be edited from now on. Happy flying! Gijs _ Kakker, Party of Nerd: download ze gratis voor in je Messenger http://buddytest.rulive.nl/default.aspx?src=taglines-- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fg shows a blank screen
On 11/29/2009 01:59 AM, Csaba Halász wrote: On Sun, Nov 29, 2009 at 12:54 AM, Jari Häkkinen j...@flygarna.se wrote: I traced the problem to changeset 10838 in OSG. I cannot say what goes wrong but maybe one of the list readers do. http://www.openscenegraph.org/projects/osg/changeset/10838/OpenSceneGraph/trunk Good job pinpointing the trouble! Since that commit introduces a change in default behaviour, I suppose restoring the previous behaviour by explicitly specifying the mask should fix it. This works for me: http://gitorious.org/fg/jesters-clone/commit/e80075464dc67e868cfc42d209a4ca7c7be234f1 But we shall wait until one of our OSG experts takes a look. We might also want to make it conditional on the OSG version (always fun, that) because this enum value hasn't existed before. I committed your patch with an autoconf test. Any Windows friends using OSG from svn will need to #define HAVE_CULLSETTINGS_CLEAR_MASK. Tim -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Runtime selection of sound device
On 30 Nov 2009, at 16:43, Nicolas Quijano wrote: The Apple OpenAL implementation is open source, btw. http://developer.apple.com/audio/openal.html#anchor3 It is, and a kind person has even posted patches to fix the implementation: http://playcontrol.net/ewing/jibberjabber/defective_core_audio_mac_os.html But I really, really dislike messing with the standard dev packages, especially when I need to earn a living doing dev work on the same machine. Oh well. James -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fg shows a blank screen
Thanks. Tim Moore wrote: On 11/29/2009 01:59 AM, Csaba Halász wrote: On Sun, Nov 29, 2009 at 12:54 AM, Jari Häkkinen j...@flygarna.se wrote: I traced the problem to changeset 10838 in OSG. I cannot say what goes wrong but maybe one of the list readers do. http://www.openscenegraph.org/projects/osg/changeset/10838/OpenSceneGraph/trunk Good job pinpointing the trouble! Since that commit introduces a change in default behaviour, I suppose restoring the previous behaviour by explicitly specifying the mask should fix it. This works for me: http://gitorious.org/fg/jesters-clone/commit/e80075464dc67e868cfc42d209a4ca7c7be234f1 But we shall wait until one of our OSG experts takes a look. We might also want to make it conditional on the OSG version (always fun, that) because this enum value hasn't existed before. I committed your patch with an autoconf test. Any Windows friends using OSG from svn will need to #define HAVE_CULLSETTINGS_CLEAR_MASK. Tim -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OpenAL / ALUT problem on Mac (was PATCH Suggested configure.ac changes/improvements affecting mac users)
Hi Jari, I really appreciate your passion, time and effort on this. However, embedding a part of alut.h code to SimGear is not a good idea even if it is a very limited lines of code, and this is why I haven't added my alut.h patch to SG/cvs. The reason is very easy. Adding something that doesn't belong to your project may increase the maintenance cost in the near future (when ALUT changes, you may need to change your code as well). Moreover, your fix won't allow other developers/users to use free-alut with SG/Mac. That's not a good idea, and the same to my alut patch. For developer-friendliness, we can add --with-openal-framework= option for letting you specify the path to your own OpenAL.framework. You can add one (or more) of alut.h, free-alut, and a fix for OpenAL (like http://playcontrol.net/ewing/jibberjabber/defective_core_audio_mac_os.html as James posted). This way we don't have to mess with the sysmtem-default framework and the users can build FG with or without free-alut by using their own OpenAL.framework. I can also provide a prebuilt OpenAL.framework for saving your time. With combination of configure option, prebuilt OpenAL.framework, and my helper build script, users can built FG right out of the box. Of course you need to either add the framework to FlightGear.app/Contents/Frameworks or specify DYLD_FRAMEWORK_PATH, but it won't be a big problem, I believe. Tat p.s. I'm open to this issue, so please feel free to tell your opinion all developers. On Nov 30, 2009, at 5:37 AM, Jari Häkkinen wrote: I am not sure if this thread is going anywhere. This will be my last post in this thread. I think we (Eric and Tat) should decide for one strategy. They may already have done so but this is my last try to persuade a change in alut usage. As Tat outlines below there are several ways to deal with alut on mac and I use a fourth variant myself. The reason to keep bugging you on this issue is that there are many patches required to compile fg on mac. I would like to see a flighgear et al. code base that actually compiles everywhere without requiring patches. In this case it is possible to make the build path simpler on mac, removing Tats patching or the need to compile freealut. Ideally for macs, alut should be removed altogether but that is probably not an viable option. The second best option would be to include alut function declarations for the 5 backward compatibility function in the Apple OpenAL framework in soundmgr_openal.hxx (or cxx if they does not need to be exposed, alut is only used in soundmgr_openal.cxx, I think ... I still have a lot of fg code to read). Is there planned increased use of alut functionality? If not, then the choice is a no-brainer. A third option is to use freealut as Eric does and I did until recently. A forth is to use Tats strategy with adding alut.h from Creatives OpenAL framework. Which one of the four above to use depends on the implementers but when you decide please take into account that every step of user (and developer) friendliness is a good thing. And believe me, fg needs developer friendliness. Some background: I work on macs with 64-bit SnowLeopard (10.6.2) and I do not cross compile (i.e., I do not create universal binaries) and use terminal tools in the compilation process (no xcode). The discussion in this thread has been confusing since the code itself is slightly confusing, at least for an outsider, and the preprocessor makes different code selections depending on which alut.h is used. In simgear/simgear/sound/soundmgr_openal.cxx there are several #if statements. Naively one would think that compiling on macs the code path is to go through section inside #if defined( __APPLE__ ) conditionals. However, what happens depends on which alut.h is used by the preprocessor because of conditionals like #if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1 and consequently the requirements on the underlying alut library changes. 1) Adopting my strategy to not include any alut.h at all and simply adding a declaration for alutLoadWAVFile will make the preprocessor to select the code inside the __APPLE__ conditionals. 2) Adopting Tats strategy to use Creatives alut.h will also make the preprocessor to use code inside __APPLE__ conditionals. I have not tried it myself but I have deduced it from Tats postings. 3) Use freeglut libraries and headers. This will actually make use of alut functionality not included in the Apple OpenAL framework (remember there is only 5 of them left) because of #if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1 conditionals. The preprocessor will include code inside this type of conditionals, and actually ignore one __APPLE__ conditional. (Interestingly the code ignored is the only Apple compatibility alut function, alutLoadWAVFile, call in simgear ... is it coincidence or made on
