[Flightgear-devel] Re: Helicopter Animations
* Jim Wilson -- Wednesday 28 April 2004 06:17: Probably the blades are doing a lot more than just spinning around the hub. Yes, indeed. Each blade consists of 5 segments which are animated in a way to make the blade appear bended (flap angle). Then each of these is rotated according to the incidence angle, and finally rotated. All in all, the bo105 uses 101 animations, with more to come. In any case, the same issue you mention is there even with the spin/rpm animation used on the props. At full rpm you really can't see the blades at all on the real thing, except _maybe_ a blur that gets darker in the center. Yes. The animation is work in progress. I'm now fading out the blades a bit already, and I will fade in a blurry rotor disk as the next step. Still there will be an interference effect, like in real life when you see a rotor in a film, where the rotation frequency interferes with the sample frequency. The rotor may look like standing still or spinning slowly, even in the wrong direction. That's hard (or rather impossible?) to avoid. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
Jon Berndt writes: You need to re run configure before make I left this step out in my original msg :-( % ./configure % make % make test Norman I got a successful build. I tried running some of the also-successfully-built test programs: Nothing produced any sound. Have you tried my partial build of the openal / win directory http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz probably best to install this into /usr/local i.e. cd /usr/local tar -xzvf $PATH_TO/openal.tgz HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Joystick configuration file changes.
Hi, After some debate on the developers mailing list we now have the possibility to adjust the _current_ configuration file to match the joystick bindings for windows. So there's no need anymore to copy the file and adjust it, but instead it is possible to change the axis numbering as described in the following example: If the axis description was as follows: axis n=2 descRudder/desc binding commandproperty-scale/command property/controls/flight/rudder/property factor type=double1.0/factor /binding /axis You could easily change it to the following to get it working for Windows also: axis descRudder/desc number unix2/unix windows3/windows /number binding commandproperty-scale/command property/controls/flight/rudder/property factor type=double1.0/factor /binding /axis Not the removal of 'n=2' in the axis tag and the addition of: number unix2/unix windows3/windows /number Where the value for unix is the value that was previously assigned to n=2. Any updated configurations are still welcome. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d audio and doppler shift
Curtis L. Olson wrote: This falls into the category of useless ear candy (and there are a few things left to be improved) but I have taken my first stab at implimenting some 3d sound in FG. Currently you only can get this effect when flying from the tower view (good R/C practice). As you do a fly by you should hear a volume change, hear a doppler shift, and hear the position change in the left/right speakers. The effect is best (or most like you'd expect to hear) if you fly by close, but not too close. (Requires latest CVS code of course.) Sorry Jon, no screen shots for this one. :-) Wow, that's really convincing! Did you try one of the jet fighters already, the sound ends in this low frequency rumble that you really would expect! Very nice. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Observations on todays cvs
Dave Perry wrote: 2. The tower view doppler shift seems to be in the wrong direction. I believe this is a known(?) problem with OpenAL for the Linux software emulation layer. There has been some discussion about it on the openal mailing list. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d audio and doppler shift
Erik Hofman wrote: Wow, that's really convincing! Did you try one of the jet fighters already, the sound ends in this low frequency rumble that you really would expect! Very nice. It's even better. You can hook up your 5.1 amplifier and speaker set using ALSA: http://floam.ascorbic.com/how-to/alsa5.1 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3d audio and doppler shift
(Requires latest CVS code of course.) Sorry Jon, no screen shots for this one. :-) Ha! How about a frequency/time plot? ;-) Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
On 4/28/04 at 4:10 AM Norman Vine wrote: Jon Berndt writes: You need to re run configure before make I left this step out in my original msg :-( % ./configure % make % make test Norman I got a successful build. I tried running some of the also-successfully-built test programs: Nothing produced any sound. Have you tried my partial build of the openal / win directory http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz probably best to install this into /usr/local i.e. cd /usr/local tar -xzvf $PATH_TO/openal.tgz I've just tried it, and can't get it to link. I added -lopenal32 to the libraries in src/Main/Makefile.am, output is below: make[2]: Entering directory `/cvs_clean/FlightGear/src/Main' g++ -DPKGLIBDIR=\/Flightgear_clean/lib/FlightGear\ -Wall -O2 -D_REENTRANT -L/usr/local/lib -o fgf s.exe bootstrap.o ../../src/Main/libMain.a ../../src/Aircraft/libAircraft.a ../../src/ATC/libATC.a ../../src/Cockpit/libCockpit.a ../../src/Cockpit/built_in/libBuilt_in.a ../../src/Controls/libContro ls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/ExternalNet/libExter nalNet.a ../../src/FDM/ExternalPipe/libExternalPipe.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM /YASim/libYASim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a . ./../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Autopilot/libAutopilot.a ../. ./src/Input/libInput.a ../../src/Instrumentation/libInstrumentation.a ../../src/Model/libModel.a ../ ../src/AIModel/libAIModel.a ../../src/Network/libNetwork.a ../../src/Navaids/libNavaids.a ../../src/ Scenery/libScenery.a ../../src/Scripting/libScripting.a ../../src/Sound/libSound.a ../../src/Airport s/libAirports.a ../../src/MultiPlayer/libMultiPlayer.a ../../src/Replay/libReplay.a ../../src/System s/libSystems.a ../../src/Time/libTime.a ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgrout e -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstruct ure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lopenal32 -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 ../../src/Input/libInput.a(input.o.b)(.text+0x3e81):input.cxx: undefined reference to `_joyGetDevCap [EMAIL PROTECTED]' /usr/local/lib/libsgsound.a(soundmgr_openal.o)(.text+0x19d):soundmgr_openal. cxx: undefined reference to `_alutInit' /usr/local/lib/libsgsound.a(soundmgr_openal.o)(.text+0x99d):soundmgr_openal. cxx: undefined reference to `_alutInit' /usr/local/lib/libsgsound.a(soundmgr_openal.o)(.text+0x111a):soundmgr_openal .cxx: undefined referenc e to `_alutExit' /usr/local/lib/libsgsound.a(soundmgr_openal.o)(.text+0x130a):soundmgr_openal .cxx: undefined referenc e to `_alutExit' /usr/local/lib/libsgsound.a(sample_openal.o)(.text+0x100a):sample_openal.cxx : undefined reference to `_alutLoadWAVFile' /usr/local/lib/libsgsound.a(sample_openal.o)(.text+0x1178):sample_openal.cxx : undefined reference to `_alutUnloadWAV' /usr/local/lib/libsgsound.a(sample_openal.o)(.text+0x1c0a):sample_openal.cxx : undefined reference to `_alutLoadWAVFile' /usr/local/lib/libsgsound.a(sample_openal.o)(.text+0x1d78):sample_openal.cxx : undefined reference to `_alutUnloadWAV' /usr/local/lib/libsgtiming.a(timestamp.o)(.text+0xd):timestamp.cxx: undefined reference to `_timeGet [EMAIL PROTECTED]' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x366):jsWindows.cxx: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibjs.a(jsWindows.o)(.tex t+0x6e4):jsWindows.cxx: undefined reference to [EMAIL PROTECTED]' /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/../../../libplibul.a(ulClock.o)(.text+ 0x91):ulClock.cxx: undef ined reference to [EMAIL PROTECTED]' collect2: ld returned 1 exit status make[2]: *** [fgfs.exe] Error 1 make[2]: Leaving directory `/cvs_clean/FlightGear/src/Main' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cvs_clean/FlightGear/src' make: *** [all-recursive] Error 1 My gcc version is 3.3.1-3 if that makes any difference: $ gcc -v Reading specs from /usr/lib/gcc-lib/i686-pc-cygwin/3.3.1/specs Configured with: /GCC/gcc-3.3.1-3/configure --with-gcc --with-gnu-ld --with-gnu-as --prefix=/usr --e xec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/sbin --mandir=/usr/share/man - -infodir=/usr/share/info --enable-languages=c,ada,c++,f77,pascal,java,objc --enable-libgcj --enable- threads=posix --with-system-zlib --enable-nls --without-included-gettext --enable-interpreter --enab le-sjlj-exceptions --disable-version-specific-runtime-libs --enable-shared --disable-win32-registry --enable-java-gc=boehm --disable-hash-synchronization --verbose --target=i686-pc-cygwin --host=i686- pc-cygwin --build=i686-pc-cygwin Thread model: posix gcc
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/docs-mini In directory baron:/tmp/cvs-serv6438 Added Files: README.sound Log Message: Add an explanation for using Arts. --- NEW FILE --- ALSA and Arts - This article leads me to the assumption that OpenAL at least on Linux is situated _always_ on top of the ALSA OSS emulation layer and does not use the ALSA interface directly but I find it hard to believe Why should I avoid directly using the ALSA layer with OpenAL ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
Martin Spott wrote: ALSA and Arts This article leads me to the assumption that OpenAL at least on Linux is situated _always_ on top of the ALSA OSS emulation layer and does not use the ALSA interface directly but I find it hard to believe Why should I avoid directly using the ALSA layer with OpenAL ? This has nothing to do with OpenAL. This article was already written before Curtis started implementing it. The major problem here is Arts that doesn't play nice with programs that don't support Arts directly. This problem has annoyed me so much that if I had to chose an desktop manager it would never be KDE until they decide to stop using Art completely. This document is just an explanation on using FlightGear with KDE/Arts enabled. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Spitfire Hurricane manuals
On 4/19/04 at 11:12 PM Vivian Meazza wrote: All you ever wanted to know about a Merlin with 2 speed, 2 stage supercharging is here: http://www.unlimitedexcitement.com/Pride%20of%20Pay%20n%20Pak/Rolls-Royce%2 0 Merlin%20V-1650%20Engine.htm Except exactly how the boost contol valve worked :-) Nice link! I've found a reference describing the BCV mechanism (Thrust for Flight by W. Thomson), apparently it consisted of a stack of metal aneroids that contract under increased pressure. This makes perfect sense - it would measure absolute pressure, and I believe is similar to the mechanism used in many barometers. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
David Luff wrote: ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgrout e -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstruct ure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lopenal32 -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 ../../src/Input/libInput.a(input.o.b)(.text+0x3e81):input.cxx: undefined reference to `_joyGetDevCap [EMAIL PROTECTED]' /usr/local/lib/libsgsound.a(soundmgr_openal.o)(.text+0x19d):soundmgr_openal. cxx: undefined reference Could you try moving -lopenal32 to the end of the linker command? As far as I know windows is a bit picky on the library sequence. Also, IRIX needs -laudio somewhere on the line, does Windows needs something similar? Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] prefix path to openal
Hello, may I kindly ask for an additional flag for 'configure' similar to '--with-plib=PREFIX' ? This might be very useful for people experimenting with a CVS version of OpenAL who still have a Linux distribution provided development package installed, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
* Erik Hofman -- Wednesday 28 April 2004 13:22: The major problem here is Arts that doesn't play nice with programs that don't support Arts directly. This problem has annoyed me so much that if I had to chose an desktop manager it would never be KDE until they decide to stop using Art completely. aRts is really not such a great thing. It started as a software synthesizer and (because there was no sound daemon at that time) was then enhanced with a DE interface. KDE 4 will use one of NMM, MAS, gstreamer. (Not decided yet.) Still, fgfs (and every other sound related application) works very well for me under KDE. And: - aRts can use ALSA - KDE can play sound without aRts (AFAIK; haven't tried) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
Erik Hofman said: Martin Spott wrote: ALSA and Arts This article leads me to the assumption that OpenAL at least on Linux is situated _always_ on top of the ALSA OSS emulation layer and does not use the ALSA interface directly but I find it hard to believe Why should I avoid directly using the ALSA layer with OpenAL ? This has nothing to do with OpenAL. This article was already written before Curtis started implementing it. The major problem here is Arts that doesn't play nice with programs that don't support Arts directly. This problem has annoyed me so much that if I had to chose an desktop manager it would never be KDE until they decide to stop using Art completely. This document is just an explanation on using FlightGear with KDE/Arts enabled. Is this still true? I'm running KDE and can't remember the last time artsd got in the way. To be honest though, I don't recall what changed. Maybe I just turned off most of the stupid sounds in the kde apps. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
* Melchior FRANZ -- Wednesday 28 April 2004 13:46: - aRts can use ALSA - KDE can play sound without aRts (AFAIK; haven't tried) Oh, I forgot to mention: the main problems with aRts and ALSA seem to lie in ALSA, at least for some chips (e.g. AC97). This improved vastly in the latest 2.6.* Linux kernels. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
Erik Hofman wrote: David Luff wrote: ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgrout e -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstruct ure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lopenal32 -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 ../../src/Input/libInput.a(input.o.b)(.text+0x3e81):input.cxx: undefined reference to `_joyGetDevCap [EMAIL PROTECTED]' /usr/local/lib/libsgsound.a(soundmgr_openal.o)(.text+0x19d):soundmgr_openal. cxx: undefined reference Could you try moving -lopenal32 to the end of the linker command? As far as I know windows is a bit picky on the library sequence. Also, IRIX needs -laudio somewhere on the line, does Windows needs something similar? With MSVC, there is a library for ALut : ALut.lib. _joyGetDevCaps should be in winmm.lib -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
Melchior FRANZ wrote: * Melchior FRANZ -- Wednesday 28 April 2004 13:46: - aRts can use ALSA - KDE can play sound without aRts (AFAIK; haven't tried) Oh, I forgot to mention: the main problems with aRts and ALSA seem to lie in ALSA, at least for some chips (e.g. AC97). This improved vastly in the latest 2.6.* Linux kernels. Sure, the most widely used sound option doesn't work correct. That makes sense. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
Norman wrote: Have you tried my partial build of the openal / win directory http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz probably best to install this into /usr/local i.e. cd /usr/local tar -xzvf $PATH_TO/openal.tgz -- test -- $ ./testdevice got Windows native audio -- test -- $ ./testmp3 boom.mp3 got Windows native audio chans 2 bps 16 bal 4 sps 44100 abs 176400 cbs 0 setfmt okay Could not GetProc alutLoadMP3_LOKI -- test -- $ ./testvorbis got Windows native audio chans 2 bps 16 bal 4 sps 44100 abs 176400 cbs 0 setfmt okay Could not GetProc alutLoadVorbis_LOKI -- test -- Many of the rest of them seemed to simply hang, but no sound was ever produced. I wonder, though, if your stuff was being used here, because I already have libopenal32.a in /usr/local/lib. I recompiled all the tests. Are we CygWin users going to be stuck with the previous codebase because openal doesn't work under CygWin? Or, do we have a choice with audio APIs? I'm hesitant to do a CVS update on the FlightGear tree at the moment because I'm not sure what the state of this OpenAL stuff is ... has it been formally introduced into FlightGear CVS, and does it replace the current audio system? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Erik Hofman wrote: This document is just an explanation on using FlightGear with KDE/Arts enabled. Ah, thanks. I didn't realize this, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
On 4/28/04 at 7:17 AM Jon Berndt wrote: Many of the rest of them seemed to simply hang, but no sound was ever produced. I wonder, though, if your stuff was being used here, because I already have libopenal32.a in /usr/local/lib. I recompiled all the tests. The tests compile and link with ../src/libopenal.a, so unless you've hacked their build script or replaced that lib with Norman's then you'll still be linking (the tests) against the original. Are we CygWin users going to be stuck with the previous codebase because openal doesn't work under CygWin? Or, do we have a choice with audio APIs? I'm hesitant to do a CVS update on the FlightGear tree at the moment because I'm not sure what the state of this OpenAL stuff is ... has it been formally introduced into FlightGear CVS, and does it replace the current audio system? At the moment the current CVS won't compile on Cygwin - there is no option to use the old audio code (that I know of). This isn't a complaint though - I think the long term benefits should far outweigh the short term pain. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On 4/28/04 at 2:13 PM Frederic Bouvier wrote: Erik Hofman wrote: David Luff wrote: ../../src/Environment/libEnvironment.a -lsgclouds3d -lsgrout e -lsgsky -lsgsound -lsgephem -lsgmaterial -lsgtgdb -lsgmodel -lsgtiming -lsgio -lsgscreen -lsgmath -lsgbucket -lsgprops -lsgdebug -lsgmagvar -lsgmisc -lsgnasal -lsgxml -lsgsound -lsgserial -lsgstruct ure -lsgenvironment -lsgthreads -lpthread -lplibpu -lplibfnt -lplibjs -lplibnet -lplibssg -lplibsg -lplibul -lz -lopenal32 -lglut32 -lglu32 -lopengl32 -luser32 -lgdi32 ../../src/Input/libInput.a(input.o.b)(.text+0x3e81):input.cxx: undefined reference to `_joyGetDevCap [EMAIL PROTECTED]' /usr/local/lib/libsgsound.a(soundmgr_openal.o)(.text+0x19d):soundmgr_openal . cxx: undefined reference Could you try moving -lopenal32 to the end of the linker command? As far as I know windows is a bit picky on the library sequence. Also, IRIX needs -laudio somewhere on the line, does Windows needs something similar? With MSVC, there is a library for ALut : ALut.lib. _joyGetDevCaps should be in winmm.lib OK, winmm fixes everthing except the alut stuff, I'm not sure why that broke right now but we've had that one before. The alut stuff is another matter - as far as I can tell only libopenal.a is built on Linux and that links OK, so why the trouble with Cygwin?. This is still the same link error I get with my own compile of the Linux subdir using Cygwin BTW. I hate linker errors - I always feel I have a fighting chance with compile errors, but I've never felt comfortable sorting linker errors :-( Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
Norman Vine wrote: David Luff writes: On 4/28/04 at 4:10 AM Norman Vine wrote: Have you tried my partial build of the openal / win directory http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz probably best to install this into /usr/local i.e. cd /usr/local tar -xzvf $PATH_TO/openal.tgz I've just tried it, and can't get it to link. I added -lopenal32 to the libraries in src/Main/Makefile.am, output is below: My WAG is you will need to add something like SoundLibs = -lopenal32 -lwinmm -ldsound -ldxguid -lole32 $(SoundLibs) There is a spot stubbed into the configure script for platform dependent audio libraries. Once we figure out exactly what we need for cygwin, we can put that into the configure script so it happens automatically. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
David Luff writes: On 4/28/04 at 4:10 AM Norman Vine wrote: Have you tried my partial build of the openal / win directory http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz probably best to install this into /usr/local i.e. cd /usr/local tar -xzvf $PATH_TO/openal.tgz I've just tried it, and can't get it to link. I added -lopenal32 to the libraries in src/Main/Makefile.am, output is below: My WAG is you will need to add something like SoundLibs = -lopenal32 -lwinmm -ldsound -ldxguid -lole32 $(SoundLibs) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
On 4/28/04 at 1:29 PM David Luff wrote: On 4/28/04 at 7:17 AM Jon Berndt wrote: Many of the rest of them seemed to simply hang, but no sound was ever produced. I wonder, though, if your stuff was being used here, because I already have libopenal32.a in /usr/local/lib. I recompiled all the tests. The tests compile and link with ../src/libopenal.a, so unless you've hacked their build script or replaced that lib with Norman's then you'll still be linking (the tests) against the original. FWIW, the tests wouldn't link when I replaced src/libopenal.a with Norman's libopenal32.a (renamed to remove the '32'). Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
Curtis L. Olson writes: Norman Vine wrote: David Luff writes: On 4/28/04 at 4:10 AM Norman Vine wrote: Have you tried my partial build of the openal / win directory http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz probably best to install this into /usr/local i.e. cd /usr/local tar -xzvf $PATH_TO/openal.tgz My WAG is you will need to add something like SoundLibs = -lopenal32 -lwinmm -ldsound -ldxguid -lole32 $(SoundLibs) There is a spot stubbed into the configure script for platform dependent audio libraries. Once we figure out exactly what we need for cygwin, we can put that into the configure script so it happens automatically. Note I am buried with *real* work and don't have any time for OpenSource for at least 2 weeks, but aren't there some test programs in SimGear someone can test this against ? Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d audio and doppler shift
On Wednesday 28 April 2004 09:57, Erik Hofman wrote: It's even better. You can hook up your 5.1 amplifier and speaker set using ALSA: http://floam.ascorbic.com/how-to/alsa5.1 Erik Impressive, that worked, thank you for the hint: Make a ~/.openalrc, we are telling OpenAL that we want surround sound and we want to use ALSA instead of OSS. (define speaker-num 4) (define devices '(alsa)) (define alsa-out-device surround40:0,0) Now i have 5.1 surround too. It's outstanding, using OpenAL was IMO a very good decision. :) Best Regards, Oliver C. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On 4/28/04 at 1:33 PM David Luff wrote: On 4/28/04 at 2:13 PM Frederic Bouvier wrote: With MSVC, there is a library for ALut : ALut.lib. _joyGetDevCaps should be in winmm.lib OK, winmm fixes everthing except the alut stuff, I'm not sure why that broke right now but we've had that one before. The alut stuff is another matter - as far as I can tell only libopenal.a is built on Linux and that links OK, so why the trouble with Cygwin?. This is still the same link error I get with my own compile of the Linux subdir using Cygwin BTW. I hate linker errors - I always feel I have a fighting chance with compile errors, but I've never felt comfortable sorting linker errors :-( OK, I was wrong when I said it was the same as the original linker error. The original was undefined references to various __imp__* functions: ../../src/Cockpit/libCockpit.a(navcom.o)(.text+0xa404):navcom.cxx: undefined reference to `__imp__al GetError' ../../src/Cockpit/libCockpit.a(navcom.o)(.text+0xa70f):navcom.cxx: undefined reference to `__imp__al Sourcef' ../../src/Cockpit/libCockpit.a(navcom.o)(.text+0xa715):navcom.cxx: undefined reference to `__imp__al GetError' ../../src/Cockpit/libCockpit.a(marker_beacon.o)(.text+0x28c6):marker_beacon .cxx: undefined reference to `__imp__alSourcef' ../../src/Cockpit/libCockpit.a(marker_beacon.o)(.text+0x28d4):marker_beacon .cxx: undefined reference to `__imp__alGetError' ../../src/Cockpit/libCockpit.a(marker_beacon.o)(.text+0x2d32):marker_beacon .cxx: undefined reference to `__imp__alSourcef' ../../src/Cockpit/libCockpit.a(marker_beacon.o)(.text+0x2d40):marker_beacon .cxx: undefined reference to `__imp__alGetError' ' ...etc... Norman's libopenal32.a contains these functions, my libopenal.a doesn't, and these errors are hence fixed with Normans .a. However, Norman's libopenal32.a doesn't contain any alut* functions, which my libopenal.a does, so hence these errors are replaced with the _alut* errors. Norman, if you could tell us roughly how you created your libopenal32.a perhaps I could try creating one in the same manner but including the alut functions? Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Slightly OT: Vector math question(s)!
I'm about to start writing something in C to calculate the heading required to maintain a track and the resultant ground speed given a wind vector. This is destined to be a simple flight planner for my Palm but I'd like to make an interface to FG so that in theory you could save a real flight and replay it in FG with the same conditions. I envisage creating a struct to hold the the polar co-ords of each of the vectors involved i.e. magnitude and angle from 0 deg. Given that the processor in a palm is not that beefy should I be storing and calculating the vectors this way or using the cartesian system? I'm a total C newbie so please go easy on me :-) All the best, Matt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
* Erik Hofman -- Wednesday 28 April 2004 14:15: Melchior FRANZ wrote: Oh, I forgot to mention: the main problems with aRts and ALSA seem to lie in ALSA, at least for some chips (e.g. AC97). This improved vastly in the latest 2.6.* Linux kernels. Sure, the most widely used sound option doesn't work correct. That makes sense. I may of course be wrong. But this was the impression I got from reading the Linux kernel mailing list (lkml), the kde-core, kde-devel, and kde-amarok (sound development) lists, and from regularly updating to the latest ALSA (now as part of the kernel; separately before) and at least once every week to the latest version of aRts. :-P m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
Melchior FRANZ wrote: * Erik Hofman -- Wednesday 28 April 2004 14:15: Melchior FRANZ wrote: Oh, I forgot to mention: the main problems with aRts and ALSA seem to lie in ALSA, at least for some chips (e.g. AC97). This improved vastly in the latest 2.6.* Linux kernels. Sure, the most widely used sound option doesn't work correct. That makes sense. I may of course be wrong. But this was the impression I got from reading the Linux kernel mailing list (lkml), the kde-core, kde-devel, and kde-amarok (sound development) lists, and from regularly updating to the latest ALSA (now as part of the kernel; separately before) and at least once every week to the latest version of aRts. :-P Ah well, lest be positive. It's a good thing that ALSA has evolved an a feature rich GPL'ed sound system for Linux that (almost) supports a large number of sound cards from different vendors. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On Wed, 28 Apr 2004 13:29:08 +0100 David Luff [EMAIL PROTECTED] wrote: The tests compile and link with ../src/libopenal.a, so unless you've hacked their build script or replaced that lib with Norman's then you'll still belinking (the tests) against the original. I'll have to adjust that. Has anyone gotten OpenAL to work with CygWin? I think the long term benefits should far outweigh the short term pain. ... for those _not_ using CygWin. For those using CygWin, it's fatal at the moment. Unfortunately, I have zero time to look into getting it working, with my workload on JSBSim, preparing for the conference later this summer, etc. So, at least at the moment, I'm stuck with the previous revision of Flightgear. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
David Luff writes: Norman's libopenal32.a contains these functions, my libopenal.a doesn't, and these errors are hence fixed with Normans .a. However, Norman's libopenal32.a doesn't contain any alut* functions, which my libopenal.a does, so hence these errors are replaced with the _alut* errors. Norman, if you could tell us roughly how you created your libopenal32.a perhaps I could try creating one in the same manner but including the alut functions? I have rebuilt the opeal dll and replaced the one on my site http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz This should export the required alut* funcs and it includes the Makefile I used Note you will need to use my headers instead of the ones in CVS if you want to recompile this easiest to do by % cd %OPEN_AL % tar -xzvf openal.tgz % cd win % make should just work the .a and .dll files will be left in the 'win' directory though My guess is we may need to add the Router / files to the DLL to take advantage of Vendor specific libraries but this will have to wait unless someone else wants to play Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
Jon S Berndt writes: For those using CygWin, it's fatal at the moment. AFAICT It is fatal for those using any form of gcc on Win32. Oh well I guess there is always MSVC grin Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FW: Should we require windows users to use tools that honor Unix lineendings? (Re: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversiontransitiontomorrow)
FYI I will keep an eye out for any solution the Zope folks come up with as solving this will open up the possibility of using SVN instead of CVS. cross-platform-development-is-a-challenge'ly yrs Norman -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jim Fulton Sent: Wednesday, April 28, 2004 10:13 AM To: Tim Peters Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Should we require windows users to use tools that honor Unix lineendings? (Re: [Zope-dev] Re: [Zope3-dev] ATTENTION! cvs to subversiontransitiontomorrow) Tim Peters wrote: [Jim Fulton] ... You will be able to do read-only anonymous checkouts like so: svn co svn://svn.zope.org/repos/main/project/trunk For example: svn co svn://svn.zope.org/repos/main/ZConfig/trunk FYI, I tried that on Windows (XP), and it worked fine. One glitch, which may be all over the place: some of the text files got checked out with Windows line ends, but most did not. For example, 14 of the 19 *.txt files in ZConfig ended up with Windows line ends, but none of the 37 *.py files did. Ack, no, none of the checked-out .txt files did either. The .txt files that had Windows line ends were all created by svn for its own purposes (README.txt files in .svn directories). I'm not sure what to do about this. Best I can tell from the docs so far, svn wants a svn:eol-style property added to every line-oriented file, with value native in order to get platform-sane line-end conversions. The doc's explanation of the effect of that matches my understanding of what CVS does for all non-binary files, which is usually exactly right. I noticed that Fredrik Lundh complained about something similar here: http://effbot.org/zone/subversion.htm ... Properties are nice, but having to use three different commands to check in a text file from Windows is pretty annoying. Looks like svn *expected* us to do this by setting enable-auto-props during the intial imports, with a bunch of [auto-props] settings in a config file; like [auto-props] *.c = svn:eol-style=native *.cpp = svn:eol-style=native *.h = svn:eol-style=native *.py = svn:eol-style=native *.dsp = svn:eol-style=CRLF *.dsw = svn:eol-style=CRLF *.sh = svn:eol-style=native;svn:executable *.txt = svn:eol-style=native *.png = svn:mime-type=image/png *.jpg = svn:mime-type=image/jpeg I found this to be so unbelievable, that I had to resoearch it myself. After looking this up in the book and expressing my amazement on the #svn channel (and recieving confirmation from svn developers there), I have to admit that you are right. I know better than to doubt you, but this is just so unbelievable, I couldn't help it. I think we'll have to develop a standard set of config file settings like that for committers to add to their personal svn configs -- I don't think that this is practical. I think it will be very hard to communicate this to everyone. Plus, every time someone comes up with a new dang file suffix, everyone will have to update their config files. I think the real answer, the answer that the svn (and arch) developers believe in the heart of hearts is that windows users should be using tools that understand, well, understand and always produce Unix line endings. Is it practical to require windows users to use tools that understand and produce Unix line endings? or can that be done on the server side? I suppose it could. I think that a post-commit script could inspect new files and, for any new file that has no mine-type property, or has one with a text type, set the svn:eol-style proprty to native. It would have to do this in a separate transaction. Does anyone want to volunteer to write this script? We'll also need to fix cvs2svn to do something similar. Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
On 4/28/04 at 10:09 AM Norman Vine wrote: I have rebuilt the opeal dll and replaced the one on my site http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz This should export the required alut* funcs and it includes the Makefile I used Note you will need to use my headers instead of the ones in CVS if you want to recompile this easiest to do by % cd %OPEN_AL % tar -xzvf openal.tgz % cd win % make should just work the .a and .dll files will be left in the 'win' directory though Norman, this compiles, links, and produces the expected sound from FlightGear :-) Many thanks for sorting this - I certainly couldn't have got it working otherwise. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On 4/28/04 at 9:04 AM Jon S Berndt wrote: On Wed, 28 Apr 2004 13:29:08 +0100 David Luff [EMAIL PROTECTED] wrote: I think the long term benefits should far outweigh the short term pain. ... for those _not_ using CygWin. For those using CygWin, it's fatal at the moment. Norman's latest openal build fixes it :-) You have to admire Curt's methodology - fatally breaking the Cygwin build has certainly created a momentum to fix it, and presumably saved the time and hassle of riddling the sound code with ifdefs! Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/docs-mini README.sound, NONE,
Jim Wilson wrote: Is this still true? I'm running KDE and can't remember the last time artsd got in the way. To be honest though, I don't recall what changed. Maybe I just turned off most of the stupid sounds in the kde apps. My impression was that recent versions of arts and esd released the sound device after a timeout if nothing was being played, so that (statistically, at least) applications that need exclusive access will see an open device. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On Wed, 28 Apr 2004 15:57:55 +0100 David Luff [EMAIL PROTECTED] wrote: Norman, this compiles, links, and produces the expected sound from FlightGear :-) Many thanks for sorting this - I certainly couldn't have got it working otherwise. Cheers - Dave This was all done under CygWin? Can someone summarize the process? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
David Luff wrote: Norman's latest openal build fixes it :-) You have to admire Curt's methodology - fatally breaking the Cygwin build has certainly created a momentum to fix it, and presumably saved the time and hassle of riddling the sound code with ifdefs! In my own defense, all indications from the openal code and the web page seemed to be that cygwin was supported. I'm not able to test every combination of every platform in advance myself, especially since I don't have easy access to a windows machine that I can tie up to do cygwin builds ... or even has enough HD space if I wanted to. To be perfectly honest, the OpenAL switch has generally gone more smoothly than I expected. I was bracing for much worse, but most people on most platforms seemed to have an easy time of it. Cygwin is a little bit different nut to crack. As I understand it, cygwin can link against any .dll out there so in theory it should be able to work with the standard openal SDK. But, you have to create a wrapper libopenal.a to make the cygwin linker happy since it doesn't know how to directly link against .dll's. That process isn't all that difficult, but it also isn't documented very well and most people don't know how to do it. I remember fiddling with this stuff years ago when we first started this project because there wasn't any libopen*GL*.a for cygwin at that time, but I wouldn't be able to remember the details any more. Fortunately Norman pulled through with both the knowledge and the time to do this. Norman, is this something we should put on the FG web site, or bundle with simgear or something? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
David Luff wrote: On 4/28/04 at 10:09 AM Norman Vine wrote: I have rebuilt the opeal dll and replaced the one on my site http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz This should export the required alut* funcs and it includes the Makefile I used Note you will need to use my headers instead of the ones in CVS if you want to recompile this easiest to do by % cd %OPEN_AL % tar -xzvf openal.tgz % cd win % make should just work the .a and .dll files will be left in the 'win' directory though Norman, this compiles, links, and produces the expected sound from FlightGear :-) Many thanks for sorting this - I certainly couldn't have got it working otherwise. *3 big cheers for Norman* Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
David Luff writes: On 4/28/04 at 10:09 AM Norman Vine wrote: I have rebuilt the opeal dll and replaced the one on my site http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz This should export the required alut* funcs and it includes the Makefile I used Note you will need to use my headers instead of the ones in CVS if you want to recompile this easiest to do by % cd %OPEN_AL % tar -xzvf openal.tgz % cd win % make should just work the .a and .dll files will be left in the 'win' directory though Norman, this compiles, links, and produces the expected sound from FlightGear :-) Cool ! Note this method should work with MingW32 also but one will need to recompile the libs and install them appropriately as the ones in my package are AFAICT Cygwin specific. Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On 4/28/04 at 10:09 AM Jon S Berndt wrote: This was all done under CygWin? Can someone summarize the process? Yes, under Cygwin. Here goes... Download Norman's prebuilt Cygwin openal from: http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz and place it somewhere, in this example in your home directory (~/). cd to /usr/local and extract the archive from there: tar xvfz ~/openal.tgz (the above assuming openal.tgz was in your home dir). Check out the latest SimGear and FlightGear - there have been recent matching changes. Build SimGear - if a test program fails to build in the sound dir then just remove it from the Makefile.am (ONLY if it's one of the test programs!!!). cd to the top level FlightGear dir. Modify FlightGear's src/Main/Makefile.am as follows: replace $(openal_LIBS) with -lopenal32 -lwinmm -ldsound -ldxguid -lole32 Hopefully this step should be removed in the near future when the configure script gets sorted for Cygwin. Build FlightGear, and report success or failure. Good luck! Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On Wed, 28 Apr 2004 16:00:20 +0100 David Luff [EMAIL PROTECTED] wrote: On 4/28/04 at 9:04 AM Jon S Berndt wrote: On Wed, 28 Apr 2004 13:29:08 +0100 David Luff [EMAIL PROTECTED] wrote: For those using CygWin, it's fatal at the moment. Norman's latest openal build fixes it :-) You have to admire Curt's methodology - fatally breaking the Cygwin build has certainly created a momentum to fix it, and presumably saved the time and hassle of riddling the sound code with ifdefs! This approach works only when there is a solution somewhere. From what I could tell in this case, that wasn't guaranteed - I was not confident that a viable fix would be found. My only development environment for Flightgear is CygWin. If that environment goes belly up, I'm toast. And sadly I don't have time to support any debugging efforts. I don't know who else uses CygWin exclusively, but I don't think there are many of us, so I get the feeling that the CygWin users don't have so much of a vote as the Linux guys. Thanks to Norman and yourself for getting to this point. Now will the build process integrate nicely with the normal FlightGear build procedure? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On 4/28/04 at 10:16 AM Curtis L. Olson wrote: David Luff wrote: Norman's latest openal build fixes it :-) You have to admire Curt's methodology - fatally breaking the Cygwin build has certainly created a momentum to fix it, and presumably saved the time and hassle of riddling the sound code with ifdefs! In my own defense, all indications from the openal code and the web page seemed to be that cygwin was supported. I'm not able to test every combination of every platform in advance myself, especially since I don't have easy access to a windows machine that I can tie up to do cygwin builds ... or even has enough HD space if I wanted to. Absolutely no defence is required :-) You've obviously put a lot of time and effort in to making this very worthwhile (IMHO) switch. To be perfectly honest, the OpenAL switch has generally gone more smoothly than I expected. I was bracing for much worse, but most people on most platforms seemed to have an easy time of it. Cygwin is a little bit different nut to crack. As I understand it, cygwin can link against any .dll out there so in theory it should be able to work with the standard openal SDK. But, you have to create a wrapper libopenal.a to make the cygwin linker happy since it doesn't know how to directly link against .dll's. That process isn't all that difficult, but it also isn't documented very well and most people don't know how to do it. I remember fiddling with this stuff years ago when we first started this project because there wasn't any libopen*GL*.a for cygwin at that time, but I wouldn't be able to remember the details any more. Fortunately Norman pulled through with both the knowledge and the time to do this. I guess the ideal situation as far as FlightGear is concerned would be if the openal binaries got bundled with Cygwin itself. Unfortunately I don't know nearly enough about how it fits together to confidently go on the Cygwin lists and advocate it. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
Jon S Berndt writes: You have to admire Curt's methodology - fatally breaking the Cygwin build has certainly created a momentum to fix it, and presumably saved the time and hassle of riddling the sound code with ifdefs! This approach works only when there is a solution somewhere. From what I could tell in this case, that wasn't guaranteed - I was not confident that a viable fix would be found. Nor was I, but usually one can find a way to compile Windows code with gcc but it often requires digging into the depths of the gnu linker documentation and studying the x86 specific link options for creating DLLs for WIN32. In this case the code depended on having both WIN32 and _WIN32 defined during compilation and the use of the link options -Wl,--export-all-symbols *.o $(LOCAL_PROJECT_LIBS) and -Wl,--no-whole-archive $(LIBS) which are LDs way of getting the proper linkage for symbols into a WIN32 DLL i.e. these export all local definitions and establish the 'thunks' to the imported definitions Judicous use of these flags along with compiling with the -mdll flag and linking with the -shared arguments to gcc usually results in being able to get a DLL built of course you still need to properly identify definitions with the usual DLLIMPORT DLLEXPORT macros but when compiling existing working WIN32 code you can almost always assume that this has always been done correctly. HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
David Luff writes: On 4/28/04 at 10:16 AM Curtis L. Olson wrote: Cygwin is a little bit different nut to crack. As I understand it, cygwin can link against any .dll out there so in theory it should be able to work with the standard openal SDK. This is only true for libraries with 'C' linkage, 'C++' linkage will *never* work unless the compilers concerned have a common ABI. But, you have to create a wrapper libopenal.a to make the cygwin linker happy since it doesn't know how to directly link against .dll's. works for 'C' libraries only That process isn't all that difficult, but it also isn't documented very well and most people don't know how to do it. Um.. this should help http://www.cygwin.com/cygwin-ug-net/dll.html I guess the ideal situation as far as FlightGear is concerned would be if the openal binaries got bundled with Cygwin itself. Unfortunately I don't know nearly enough about how it fits together to confidently go on the Cygwin lists and advocate it. Unfortunately I do not have the time to support the libraries I port so I do not submit them for inclusion with Cygwin but the official method of doing this is here http://cygwin.com/setup.html the-tech-part-is-done-making-it-point-and-clickable-I-leave-to-others'ly yr's Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
On Wed, 28 Apr 2004 12:12:20 -0400 Norman Vine [EMAIL PROTECTED] wrote: Nor was I, but usually one can find a way to compile Windows code with gcc but it often requires digging into the depths of the gnu linker documentation and studying the x86 specific link options for creating DLLs for WIN32. I was also concerned about the hardware/driver interface issues, and how this would be built in a Unix-like environment. There was an ominous lack of mention of CygWin on the OpenAL site. Maybe the efforts here will be beneficial if fed back to the OpenAL project ... perhaps there's a FAQ entry in this somewhere for them. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
Norman Vine wrote: Unfortunately I do not have the time to support the libraries I port so I do not submit them for inclusion with Cygwin but the official method of doing this is here http://cygwin.com/setup.html I suspect the OpenAL people should be the first ones to contact. I doubt the Cygwin folks will be interested in including a package until it builds out of the box on cygwin. Right now, the OpenAL win32 implementation (maintained by Creative, I believe) ships with a build environment for MSVC only. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
Andy Ross writes: Norman Vine wrote: Unfortunately I do not have the time to support the libraries I port so I do not submit them for inclusion with Cygwin but the official method of doing this is here http://cygwin.com/setup.html I suspect the OpenAL people should be the first ones to contact. I doubt the Cygwin folks will be interested in including a package until it builds out of the box on cygwin. Right now, the OpenAL win32 implementation (maintained by Creative, I believe) ships with a build environment for MSVC only. It is not uncommon to have specific Cygwin mods for packages shipped with Cygwin. In fact this is the norm. Instructions for how to package these are on the Cygwin link I posted in my earlier message. Of course if Creative wants to support gcc on WIN32 this would be best but I won't hold my breath Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Helicopter Animations
* Jim Wilson -- Wednesday 28 April 2004 06:17: Probably the blades are doing a lot more than just spinning around the hub. Indeed (I knew this), but for a slave machine and potentially multiplayer I do not believe it is sensible to do any more than get the propeller spinning and when it reaches full speed display a disc discolouration. Yes, indeed. Each blade consists of 5 segments which are animated in a way ... the bo105 uses 101 animations, with more to come. sample frequency. The rotor may look like standing still or spinning slowly, even in the wrong direction. That's hard (or rather impossible?) to avoid. A fair point which whistled by me... I guess I must have been immersed in the flightgear environment. I would guess once the rotor exceeds the framerate you'll have problems? Not a problem to consider after a 12 hour day at work... I'll let someone else take up the mantle. Chris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Joystick configuration file changes.
* Erik Hofman -- Wednesday 28 April 2004 10:31: After some debate on the developers mailing list we now have the possibility to adjust the _current_ configuration file to match the joystick bindings for windows. [...] axis n=2 [...] You could easily change it to the following to get it working for Windows also: axis descRudder/desc number unix2/unix windows3/windows /number Q1: Is there a policy for where to replace the old notation by the new? Should it only be done where Unix and Windows actually differ (like in sidewinder-precision-pro.xml), or everywhere (like in wingman-extreme-digital-3d-win.xml[1]) even if that means to state the same value both for unix and windows? The latter is more consistent and easier to change (for newbies :-), but also more verbose. Q2: The hats of the Cyborg-Gold-3d are accessible both as axes *and* as buttons. Does anyone know if the button numbers are also swapped under Windows, or if this only applies to the axis numbers? * Frederic Bouvier -- Tuesday 27 April 2004 20:13: axis 2 and 3 need to be exchanged Linux 2 == Windows 3 == rudder Linux 3 == Windows 2 == throttle axis 4 and 5 are hat on Linux and becomes 6 and 7 on Windows. Linux 4 == Windows 6 == left/right Linux 5 == Windows 7 == up/down So, for the Cyborg-Gold-3d: Unix Unix | Windows Windows? -- hat forward button 10axis 5/H | axis 7/H button ? hat left button 11axis 4/L | axis 6/L button ? hat right button 12axis 4/H | axis 6/H button ? hat back button 13axis 5/L | axis 7/L button ? I don't really care for the hat axes -- I'm using the equivalent buttons. Are they the same for Linux and Windows? m. [1] It was probably not intended to make the changes to the windows file which is now obsolete and should be removed from joysticks.xml. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
David Luff gave clear instructions On 4/28/04 at 10:09 AM Jon S Berndt wrote: This was all done under CygWin? Can someone summarize the process? Yes, under Cygwin. Here goes... Download Norman's prebuilt Cygwin openal from: http://www.vso.cape.com/~nhv/files/fgfs/openal.tgz and place it somewhere, in this example in your home directory (~/). cd to /usr/local and extract the archive from there: tar xvfz ~/openal.tgz (the above assuming openal.tgz was in your home dir). Check out the latest SimGear and FlightGear - there have been recent matching changes. Build SimGear - if a test program fails to build in the sound dir then just remove it from the Makefile.am (ONLY if it's one of the test programs!!!). cd to the top level FlightGear dir. Modify FlightGear's src/Main/Makefile.am as follows: replace $(openal_LIBS) with -lopenal32 -lwinmm -ldsound -ldxguid -lole32 Hopefully this step should be removed in the near future when the configure script gets sorted for Cygwin. Build FlightGear, and report success or failure. Good luck! Cheers - Dave Result - failure, I downloaded openal.gz (not openal.tgz) and extracted the archive - no problems as far as I can see. I've downloaded the latest Simgear - compiles OK, no warnings. I've downloaded the latest FlightGear, made the changes. Configure reports with: Checking for library containing alGenBuffers ... No Then fails with Config.status: creating \ .infig.status: error:cannot find input file. I think that this failure may have nothing to do with openAL, but I can't see what's wrong. My knowledge of Cygwin is vestigial. FlightGear-0.9.4 compiles without error. Any pointers? Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Segmentation fault during joystick initialization: input.cxx
I'm getting a segfault in a newly-compiled-from-cvs FlightGear: [EMAIL PROTECTED] jonathan]$ ls ~/.fgfsrc ls: /home/jonathan/.fgfsrc: No such file or directory [EMAIL PROTECTED] jonathan]$ fgfs --log-level=bulk yadda yadda Looking for bindings for joystick Saitek Saitek X45 cut Trying Saitek Saitek X45 Found bindings Initializing joystick 0 Reading all bindings normal initialization for buttons = 20 Reading all bindings Reading binding nasal Initializing button 21 Reading all bindings Reading binding nasal Initializing button 1012 Segmentation fault The X45 has a lot of buttons, but there is no button 1012, of course. I deleted my locally edited X45.xml, but the same fault occurs with the CVS one. I eliminated the possibility of something in fgfsrc settings: [EMAIL PROTECTED] jonathan]$ ls ~.fgfsrc ls: ~.fgfsrc: No such file or directory Here's what gdb has to say: [EMAIL PROTECTED] jonathan]$ gdb /usr/local/bin/fgfs GNU gdb 5.3-22mdk (Mandrake Linux) Copyright 2002 Free Software Foundation, Inc. This GDB was configured as i586-mandrake-linux-gnu... (gdb) run Starting program: /usr/local/bin/fgfs [New Thread 16384 (LWP 4043)] [New Thread 32769 (LWP 4051)] [New Thread 16386 (LWP 4052)] Initializing OpenAL sound manager [New Thread 32771 (LWP 4053)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 4043)] 0x0826b506 in FGInput::_init_button(SGPropertyNode const*, FGInput::button, std::string) (this=0xa43ee58, node=0x8a9a898, [EMAIL PROTECTED]) at input.cxx:625 625 b.is_repeatable = node-getBoolValue(repeatable, b.is_repeatable); (gdb) where #0 0x0826b506 in FGInput::_init_button(SGPropertyNode const*, FGInput::button, std::string) (this=0xa43ee58, node=0x8a9a898, [EMAIL PROTECTED]) at input.cxx:625 #1 0x082688c7 in FGInput::_init_joystick() (this=0xa43ee58) at /usr/include/c++/3.2.2/bits/stl_alloc.h:664 #2 0x08267118 in FGInput::init() (this=0xa43ee58) at input.cxx:174 #3 0x0837f860 in SGSubsystemGroup::init() (this=0x874e36c) at /usr/include/c++/3.2.2/bits/stl_vector.h:289 #4 0x0838031d in SGSubsystemMgr::init() (this=0x874e350) at subsystem_mgr.cxx:250 #5 0x080676bd in fgInitSubsystems() () at fg_init.cxx:1761 #6 0x08055b78 in fgIdleFunction () at main.cxx:1400 #7 0x0807e924 in GLUTidle () at fg_os.cxx:110 #8 0x4008ffb8 in __glutRegisterEventParser () from /usr/X11R6/lib/libglut.so.3 #9 0x080520af in main (argc=1, argv=0xb5f4) at bootstrap.cxx:148 #10 0x404de7f7 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) Running on Mandrake Linux 9.1, kernel 2.4.21, XFree86 4.3, KDE 3.1 I notice that src/Input/input.cxx is dated today... // $Id: input.cxx,v 1.45 2004/04/28 08:03:40 ehofman Exp $ Is this something to do with the changes to accommodate both unix and windows axis mappings? Regards Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Segmentation fault during joystick initialization: input.cxx
* Jonathan Richards -- Wednesday 28 April 2004 22:24:
I'm getting a segfault in a newly-compiled-from-cvs FlightGear:
Try this (sent to Erik already)
:
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Input/input.cxx,v
retrieving revision 1.45
diff -u -p -r1.45 input.cxx
--- a/input.cxx 28 Apr 2004 08:03:40 - 1.45
+++ b/input.cxx 28 Apr 2004 18:18:19 -
@@ -490,7 +490,7 @@ FGInput::_init_joystick ()
//
vectorSGPropertyNode_ptr buttons = js_node-getChildren(button);
char buf[32];
-for (j = 0; j nbuttons; j++) {
+for (j = 0; j buttons.size(); j++) {
const SGPropertyNode * button_node = buttons[j];
const SGPropertyNode * num_node = button_node-getChild(number);
size_t n_but = button_node-getIndex();
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Segmentation fault during joystick initialization: input.cxx
On Wednesday 28 Apr 2004 9:30 pm, Melchior FRANZ wrote: Try this (sent to Erik already) snip That got it! Thanks for the quick response! Regards Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] My day for segfaults...
Firstly, can I say that with OpenAL, and Erik's tip for .openalrc I get much
better sound quality from a SoundBlaster Live! and a 5.1 speaker setup.
However, if I exchange frequencies on com1, and then swap them back again, I
get a segmentation fault. I know Dave Luff reported a problem with ATIS, but
I understood that Curt had submitted a fix. This seems to be something to do
with deleting a sound sample.
[EMAIL PROTECTED] jonathan]$ gdb /usr/local/bin/fgfs
GNU gdb 5.3-22mdk (Mandrake Linux)
Copyright 2002 Free Software Foundation, Inc.
This GDB was configured as i586-mandrake-linux-gnu...
(gdb) run
Starting program: /usr/local/bin/fgfs
[New Thread 16384 (LWP 5561)]
[New Thread 32769 (LWP 5568)]
[New Thread 16386 (LWP 5569)]
Initializing OpenAL sound manager
[New Thread 32771 (LWP 5571)]
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 5561)]
0x4053bdc9 in free () from /lib/i686/libc.so.6
Current language: auto; currently c
(gdb) where
#0 0x4053bdc9 in free () from /lib/i686/libc.so.6
#1 0x083130dc in ~SGSoundSample (this=0x4e0aa008) at sample_openal.cxx:194
#2 0x0831436d in SGSoundMgr::remove(std::string const) (this=0x9694100,
[EMAIL PROTECTED])
at soundmgr_openal.cxx:188
#3 0x080a2489 in FGATC::NoRender(std::string) (this=0x4e104e58, refname=
{static npos = 4294967295, _M_dataplus = {allocatorchar = {No
data fields}, _M_p = 0x4b715954 atis}, static _S_empty_rep_storage = {0,
0, 0, 0}}) at ../../src/Main/globals.hxx:273
#4 0x080a2c9e in FGATIS::Update(double) (this=0x4e104e58,
dt=0.0083306) at atis.cxx:85
#5 0x0808979c in FGATCMgr::RemoveFromList(std::string, atc_type)
(this=0x95e3770, id=
{static npos = 4294967295, _M_dataplus = {allocatorchar = {No
data fields}, _M_p = 0x49e8d41c KSFO}, static _S_empty_rep_storage = {0,
0, 0, 0}}, tp=ATIS) at /usr/include/c++/3.2.2/bits/stl_list.h:138
#6 0x080894eb in FGATCMgr::CommRemoveFromList(std::string, atc_type, int)
(this=0x95e3770, id=
{static npos = 4294967295, _M_dataplus = {allocatorchar = {No
data fields}, _M_p = 0x49e8d41c KSFO}, static _S_empty_rep_storage = {0,
0, 0, 0}}, tp=ATIS, chan=0) at ATCmgr.cxx:349
#7 0x0808a6c7 in FGATCMgr::FreqSearch(int) (this=0x95e3770, channel=1) at
ATCmgr.cxx:549
#8 0x08087db6 in FGATCMgr::update(double) (this=0x0, dt=0.051132)
at ATCmgr.cxx:186
#9 0x08055592 in fgMainLoop () at ../../src/Main/globals.hxx:261
#10 0x0807e924 in GLUTidle () at fg_os.cxx:110
#11 0x4008ffb8 in __glutRegisterEventParser () from
/usr/X11R6/lib/libglut.so.3
#12 0x080520af in main (argc=1, argv=0xb5f4) at bootstrap.cxx:148
#13 0x404de7f7 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My day for segfaults...
Jonathan Richards writes: However, if I exchange frequencies on com1, and then swap them back again, I get a segmentation fault. I know Dave Luff reported a problem with ATIS, but I understood that Curt had submitted a fix. This seems to be something to do with deleting a sound sample. Yes, it segfaults when ATIS is switched off now, rather than when switched on as before. I haven't had time to look at it properly yet though. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Joystick configuration file changes.
Melchior FRANZ wrote: * Erik Hofman -- Wednesday 28 April 2004 10:31: After some debate on the developers mailing list we now have the possibility to adjust the _current_ configuration file to match the joystick bindings for windows. [...] axis n=2 [...] You could easily change it to the following to get it working for Windows also: axis descRudder/desc number unix2/unix windows3/windows /number Q1: Is there a policy for where to replace the old notation by the new? Should it only be done where Unix and Windows actually differ (like in sidewinder-precision-pro.xml), or everywhere (like in wingman-extreme-digital-3d-win.xml[1]) even if that means to state the same value both for unix and windows? The latter is more consistent and easier to change (for newbies :-), but also more verbose. Ideally, the new notation should replace the old in order to eliminate potential confusion. But the patch was made to be compatible with existing profile : it use the node index ( the n attribute ) if there is no 'number' node for the axis or button. Q2: The hats of the Cyborg-Gold-3d are accessible both as axes *and* as buttons. Does anyone know if the button numbers are also swapped under Windows, or if this only applies to the axis numbers? * Frederic Bouvier -- Tuesday 27 April 2004 20:13: axis 2 and 3 need to be exchanged Linux 2 == Windows 3 == rudder Linux 3 == Windows 2 == throttle axis 4 and 5 are hat on Linux and becomes 6 and 7 on Windows. Linux 4 == Windows 6 == left/right Linux 5 == Windows 7 == up/down So, for the Cyborg-Gold-3d: Unix Unix | Windows Windows? -- hat forward button 10axis 5/H | axis 7/H button ? hat left button 11axis 4/L | axis 6/L button ? hat right button 12axis 4/H | axis 6/H button ? hat back button 13axis 5/L | axis 7/L button ? I don't really care for the hat axes -- I'm using the equivalent buttons. Are they the same for Linux and Windows? I never care about buttons, because I never plugged my joystick in my Linux box. This is no more true ;-) and I am impressed to see that Mandrake recognized the Logitech stick without any manual intervention. So I can tell you that for this stick, the button layout is the same in both systems. It conforms to the numbering printed on the devices. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
David Luff wrote: You have to admire Curt's methodology - fatally breaking the Cygwin build has certainly created a momentum to fix it, and presumably saved the time and hassle of riddling the sound code with ifdefs! He has proven to be a good student :-D Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Joystick configuration file changes.
* Frederic Bouvier -- Wednesday 28 April 2004 23:22: Melchior FRANZ wrote: Q1: Is there a policy for where to replace the old notation by the new? Should it only be done where Unix and Windows actually differ (like in sidewinder-precision-pro.xml), or everywhere (like in wingman-extreme-digital-3d-win.xml[1]) even if that means to state the same value both for unix and windows? The latter is more consistent and easier to change (for newbies :-), but also more verbose. Ideally, the new notation should replace the old in order to eliminate potential confusion. But the patch was made to be compatible with existing profile : it use the node index ( the n attribute ) if there is no 'number' node for the axis or button. I know that it works both ways. Hence my question: Should we *always* use the new notation, also in cases like this: axis descAileron/desc number linux0/linux windows0/windows /number ... (real-life example from wingman-extreme-digital-3d-win.xml!) or only where there's a difference between Linux and Windows? Or should everone do as he likes? m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
Vivian Meazza writes: Result - failure, I've downloaded the latest FlightGear, made the changes. Configure reports with: Ah, you shouldn't need the src/Main/Makefile.am changes anymore, Curt has added the libs to configure.ac already. Remove your src/Main/Makefile.am, recheckout and see if that works. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] OpenAL
Erik Hofman writes: David Luff wrote: You have to admire Curt's methodology - fatally breaking the Cygwin build has certainly created a momentum to fix it, and presumably saved the time and hassle of riddling the sound code with ifdefs! He has proven to be a good student :-D Just curious - Has anyone gotten SDL working with Cygwin yet ? Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL
David Luff wrote: Vivian Meazza writes: Result - failure, I downloaded openal.gz (not openal.tgz) and extracted the archive - no problems as far as I can see. Are you *sure* that your browser isn't mangling the file extension - it was a .tgz on Norman's web page when I checked 30 seconds ago. One of my browsers appends .gz to make it openal.tgz.gz, which is of course wrong. I can confirm that : Internet Explorer is doing strange thing with Norman's link. It becomes openal.gz and the tar file is not accessible after decompression. Mozilla is fine. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My day for segfaults... still
On Wednesday 28 Apr 2004 9:00 pm, David Luff wrote: Jonathan Richards writes: However, if I exchange frequencies on com1, and then swap them back again, I get a segmentation fault. I know Dave Luff reported a problem with ATIS, but I understood that Curt had submitted a fix. This seems to be something to do with deleting a sound sample. Yes, it segfaults when ATIS is switched off now, rather than when switched on as before. I haven't had time to look at it properly yet though. Just one more, then I'll stop finding faults for the day :-) This is a SIGABRT (just for variety) that happens when I exchange frequencies on nav1 - I suspect that it is rooted in the sound changes, via the morse sound outputs... [EMAIL PROTECTED] jonathan]$ gdb /usr/local/bin/fgfs GNU gdb 5.3-22mdk (Mandrake Linux) This GDB was configured as i586-mandrake-linux-gnu... (gdb) run Starting program: /usr/local/bin/fgfs [New Thread 16384 (LWP 6229)] [New Thread 32769 (LWP 6236)] [New Thread 16386 (LWP 6237)] Initializing OpenAL sound manager [New Thread 32771 (LWP 6239)] Program received signal SIGABRT, Aborted. [Switching to Thread 16384 (LWP 6229)] 0x404f1481 in kill () from /lib/i686/libc.so.6 Current language: auto; currently c (gdb) where #0 0x404f1481 in kill () from /lib/i686/libc.so.6 #1 0x40029acd in pthread_kill () from /lib/i686/libpthread.so.0 #2 0x40029deb in raise () from /lib/i686/libpthread.so.0 #3 0x404f1224 in raise () from /lib/i686/libc.so.6 #4 0x404f276b in abort () from /lib/i686/libc.so.6 #5 0x40133ec7 in __cxxabiv1::__terminate(void (*)()) () from /usr/X11R6/lib/libGLU.so.1 #6 0x40133f14 in std::terminate() () from /usr/X11R6/lib/libGLU.so.1 #7 0x40134086 in __cxa_throw () from /usr/X11R6/lib/libGLU.so.1 #8 0x08312c8e in SGSoundSample (this=0x401499dc, _data=0x0, len=0, _freq=178907312) at sample_openal.cxx:160 #9 0x082c51d9 in FGMorse::make_ident(std::string const, int) (this=0x4ad651ad, [EMAIL PROTECTED], freq=1075091932) at morse.cxx:263 #10 0x080f5f09 in FGNavCom::search() (this=0x4ad651a8) at navcom.cxx:657 #11 0x080e7092 in FGRadioStack::search() (this=0x4ad42008) at radiostack.cxx:129 #12 0x080e720b in SGMethodCallbackFGRadioStack*, void (FGRadioStack::*)()::operator()() (this=0x40030bd8) at /usr/local/include/simgear/structure/callback.hxx:117 #13 0x0837edf3 in SGTimer::run() (this=0x9991918) at event_mgr.cxx:21 #14 0x0837f051 in SGTimerQueue::update(double) (this=0x874e39c, deltaSecs=0.0266020001) at event_mgr.cxx:70 #15 0x0837ee6d in SGEventMgr::update(double) (this=0x874e390, delta_time_sec=0.0266020001) at event_mgr.cxx:34 #16 0x080548cd in fgMainLoop () at main.cxx:1068 #17 0x0807e924 in GLUTidle () at fg_os.cxx:110 #18 0x4008ffb8 in __glutRegisterEventParser () from /usr/X11R6/lib/libglut.so.3 #19 0x080520af in main (argc=1, argv=0xb5f4) at bootstrap.cxx:148 #20 0x404de7f7 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] autogen.sh question
Hi, Over the past couple of days I've been fine tuning my gentoo ebuild scripts for CVS SimGear and FlightGear. Chris Horler has been great in answering my dumb questions about the automake and autoconf tools. So rather than just ask Chris dumb question I thought I'd come here too ;-) My problem is that if I use autotools version 1.5 or 1.6 that flightgear won't pass configure (simgear is fine past this stage at any of those 2 versions). The failure comes in that automake --add-missing does not copy over config.sub and config.guess. If I set WANT_AUTOMAKE to 1.7 or 1.8 then it preforms this process and it passes ./configure and goes to compile without any problems. My question is should autogen.sh refer to newer versions of autotools or is my Gentoo broken in this respect (however bear in mind I've compiled over 300 packages on this setup and not run into the problem as yet)? Cheers, Al ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] autogen.sh question
Al West writes: Hi, Over the past couple of days I've been fine tuning my gentoo ebuild scripts for CVS SimGear and FlightGear. Chris Horler has been great in answering my dumb questions about the automake and autoconf tools. So rather than just ask Chris dumb question I thought I'd come here too ;-) My problem is that if I use autotools version 1.5 or 1.6 that flightgear won't pass configure (simgear is fine past this stage at any of those 2 versions). The failure comes in that automake --add-missing does not copy over config.sub and config.guess. If I set WANT_AUTOMAKE to 1.7 or 1.8 then it preforms this process and it passes ./configure and goes to compile without any problems. My question is should autogen.sh refer to newer versions of autotools or is my Gentoo broken in this respect (however bear in mind I've compiled over 300 packages on this setup and not run into the problem as yet)? I've also had the config.sub/guess problem on Debian-based Linux, but not on Cygwin. I hadn't twigged before that I was using automake 1.7 on Cygwin, and 1.6 on Linux. So no, I don't think it's perculiar to your system. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My day for segfaults... still
Jonathan, I believe I fixed this one today ... Curt. Jonathan Richards wrote: On Wednesday 28 Apr 2004 9:00 pm, David Luff wrote: Jonathan Richards writes: However, if I exchange frequencies on com1, and then swap them back again, I get a segmentation fault. I know Dave Luff reported a problem with ATIS, but I understood that Curt had submitted a fix. This seems to be something to do with deleting a sound sample. Yes, it segfaults when ATIS is switched off now, rather than when switched on as before. I haven't had time to look at it properly yet though. Just one more, then I'll stop finding faults for the day :-) This is a SIGABRT (just for variety) that happens when I exchange frequencies on nav1 - I suspect that it is rooted in the sound changes, via the morse sound outputs... [EMAIL PROTECTED] jonathan]$ gdb /usr/local/bin/fgfs GNU gdb 5.3-22mdk (Mandrake Linux) This GDB was configured as i586-mandrake-linux-gnu... (gdb) run Starting program: /usr/local/bin/fgfs [New Thread 16384 (LWP 6229)] [New Thread 32769 (LWP 6236)] [New Thread 16386 (LWP 6237)] Initializing OpenAL sound manager [New Thread 32771 (LWP 6239)] Program received signal SIGABRT, Aborted. [Switching to Thread 16384 (LWP 6229)] 0x404f1481 in kill () from /lib/i686/libc.so.6 Current language: auto; currently c (gdb) where #0 0x404f1481 in kill () from /lib/i686/libc.so.6 #1 0x40029acd in pthread_kill () from /lib/i686/libpthread.so.0 #2 0x40029deb in raise () from /lib/i686/libpthread.so.0 #3 0x404f1224 in raise () from /lib/i686/libc.so.6 #4 0x404f276b in abort () from /lib/i686/libc.so.6 #5 0x40133ec7 in __cxxabiv1::__terminate(void (*)()) () from /usr/X11R6/lib/libGLU.so.1 #6 0x40133f14 in std::terminate() () from /usr/X11R6/lib/libGLU.so.1 #7 0x40134086 in __cxa_throw () from /usr/X11R6/lib/libGLU.so.1 #8 0x08312c8e in SGSoundSample (this=0x401499dc, _data=0x0, len=0, _freq=178907312) at sample_openal.cxx:160 #9 0x082c51d9 in FGMorse::make_ident(std::string const, int) (this=0x4ad651ad, [EMAIL PROTECTED], freq=1075091932) at morse.cxx:263 #10 0x080f5f09 in FGNavCom::search() (this=0x4ad651a8) at navcom.cxx:657 #11 0x080e7092 in FGRadioStack::search() (this=0x4ad42008) at radiostack.cxx:129 #12 0x080e720b in SGMethodCallbackFGRadioStack*, void (FGRadioStack::*)()::operator()() (this=0x40030bd8) at /usr/local/include/simgear/structure/callback.hxx:117 #13 0x0837edf3 in SGTimer::run() (this=0x9991918) at event_mgr.cxx:21 #14 0x0837f051 in SGTimerQueue::update(double) (this=0x874e39c, deltaSecs=0.0266020001) at event_mgr.cxx:70 #15 0x0837ee6d in SGEventMgr::update(double) (this=0x874e390, delta_time_sec=0.0266020001) at event_mgr.cxx:34 #16 0x080548cd in fgMainLoop () at main.cxx:1068 #17 0x0807e924 in GLUTidle () at fg_os.cxx:110 #18 0x4008ffb8 in __glutRegisterEventParser () from /usr/X11R6/lib/libglut.so.3 #19 0x080520af in main (argc=1, argv=0xb5f4) at bootstrap.cxx:148 #20 0x404de7f7 in __libc_start_main () from /lib/i686/libc.so.6 (gdb) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Positional sounds
I have added a way to position sounds in the cockpit via the aircraft-sound.xml file. For any sound you can add: position x-2.0/x y0.0/y z0.0/z /position This positions a sound in cockpit coordinates. -X is left, +X is right, +Y is up, -Y is down, +Z is back, -Z is forward. This should be a right hand coordinate system. Check out the c310 for an example. I put all the left engine sounds out left and the right engine sounds to the right. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire Hurricane manuals
On Wed, 28 Apr 2004 12:26:42 +0100, David wrote in message [EMAIL PROTECTED]: On 4/19/04 at 11:12 PM Vivian Meazza wrote: All you ever wanted to know about a Merlin with 2 speed, 2 stage supercharging is here: http://www.unlimitedexcitement.com/Pride%20of%20Pay%20n%20Pak/Rolls- Royce%2 0 Merlin%20V-1650%20Engine.htm Except exactly how the boost contol valve worked :-) Nice link! I've found a reference describing the BCV mechanism (Thrust for Flight by W. Thomson), apparently it consisted of a stack of metal aneroids that contract under increased pressure. This makes perfect sense - it would measure absolute pressure, and I believe is similar to the mechanism used in many barometers. ..search these for aneroid. http://naca.larc.nasa.gov/index.cgi?method=searchlimit=25offset=0mode=simpleorder=DESCkeywords=supercharger+stage http://www.cebudanderson.com/viewfromtheline.htm http://www.dallasjournal.com/articlesview.php?ID=295 http://www.aircadets.org/pdf/acp33vol3.pdf http://www.unlimitedexcitement.com/Griffon Budweiser/Rolls-Royce Griffon Engine.htm http://www.home.aone.net.au/shack_one/rolls.htm -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Slightly OT: Vector math question(s)!
On Wed, 28 Apr 2004 14:09:51 +0100, Matthew wrote in message [EMAIL PROTECTED]: I'm about to start writing something in C to calculate the heading required to maintain a track and the resultant ground speed given a wind vector. This is destined to be a simple flight planner for my Palm but I'd like to make an interface to FG so that in theory you could save a real flight and replay it in FG with the same conditions. I envisage creating a struct to hold the the polar co-ords of each of the vectors involved i.e. magnitude and angle from 0 deg. Given that the processor in a palm is not that beefy should I be storing and calculating the vectors this way or using the cartesian system? I'm a total C newbie so please go easy on me :-) ..be adviced the guys here torched me for suggesting redoing FG in C, so I guess you by C really meant C++, no? ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Positional sounds
On Wed, 28 Apr 2004 19:54:41 -0500, Curtis wrote in message [EMAIL PROTECTED]: I have added a way to position sounds in the cockpit via the aircraft-sound.xml file. For any sound you can add: position x-2.0/x y0.0/y z0.0/z /position This positions a sound in cockpit coordinates. -X is left, +X is right, +Y is up, -Y is down, +Z is back, -Z is forward. This should be a right hand coordinate system. ..by 'cockpit coordinates' you mean pilot coordinates, with the origo between the pilots ears? Wouldn't the 3D model's coordinates be easier to use? At least in the long run, when people start making everthing making noises? ..FWIW, I saw an article (waaay back) on some BangOlufsen research on audio engineering, where they wound up with a human head model as the best microfone mount platform, to recreate almost the true acoustics of the concert hall, church choir etc recordings, on playback on a stereo rig in residental living room with those kinda acoustics. Some similar approach help us simulate the somewhat different sound you hear say when moving to the right hand seat. Check out the c310 for an example. I put all the left engine sounds out left and the right engine sounds to the right. Regards, Curt. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Positional sounds
Curtis L. Olson wrote: I have added a way to position sounds in the cockpit via the aircraft-sound.xml file. For any sound you can add: position x-2.0/x y0.0/y z0.0/z /position This positions a sound in cockpit coordinates. -X is left, +X is right, +Y is up, -Y is down, +Z is back, -Z is forward. This should be a right hand coordinate system. Check out the c310 for an example. I put all the left engine sounds out left and the right engine sounds to the right. Do you plan to modify the listener position and orientation according to the view settings ? The positional effect is already great. Thanks for your efforts. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Positional sounds
Arnt Karlsen wrote: On Wed, 28 Apr 2004 19:54:41 -0500, Curtis wrote in message [EMAIL PROTECTED]: I have added a way to position sounds in the cockpit via the aircraft-sound.xml file. [...] This positions a sound in cockpit coordinates. -X is left, +X is right, +Y is up, -Y is down, +Z is back, -Z is forward. This should be a right hand coordinate system. Wouldn't the 3D model's coordinates be easier to use? At least in the long run, when people start making everthing making noises? I _strongly_ support Arnt's idea of 3D coordinates for the sound/noise sources. To complete the picture I'd suggest binding the listener's ear positions to the view direction (implemented somewhere in the viewer mechanics in order to make it work in _every_ view that might be invented in the future). In the long run people will want to hear the left engine of a C310 from the _front_ when they turn the cockpit view to the left, they will want to have a realistic noise location on a walkaround or any other view that moves relative to the aircraft. You could also add noise to any stationary object on the ground - not that I'd want to make FlightGear as noisy as the real world Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
