[Flightgear-devel] Makefile.am to MSVC dsp converter. where ?
Hello, I noticed that the flightgear project file for MSVC is outdated and I updated it by hand. I've read that there is a script that can create this dsp from Makefile.am. Where can I find it ? Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Debugging Properties
Norman Vine writes: but how about having the compile time option to turn it off ie #ifdef DO_TRACE // or any good memonic #define DO_TRACE_READ(type) if(getAttribute(TRACE_READ)) trace_read(type) #define DO_TRACE_WRITE(type) if (getAttribute(TRACE_WRITE)) trace_write(type) #else #define DO_TRACE_READ(type) #define DO_TRACE_WRITE(type) #endif Do you think that there would be enough of a saving to make a difference? Currenly, the only overhead is a quick check of a bit value to see if the attribute is set (we do a similar check for read/write permissions). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Makefile.am to MSVC dsp converter. where ?
I think it's the am2dsp.pl script in the 'admin' module, which you can check out from the same CVS as flightgear. -- Ross On Wed, 2001-12-12 at 08:40, Frederic Bouvier wrote: Hello, I noticed that the flightgear project file for MSVC is outdated and I updated it by hand. I've read that there is a script that can create this dsp from Makefile.am. Where can I find it ? Thanks, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Debugging Properties
David Megginson writes: Norman Vine writes: but how about having the compile time option to turn it off ie #ifdef DO_TRACE // or any good memonic #define DO_TRACE_READ(type) if(getAttribute(TRACE_READ)) trace_read(type) #define DO_TRACE_WRITE(type) if (getAttribute(TRACE_WRITE)) trace_write(type) #else #define DO_TRACE_READ(type) #define DO_TRACE_WRITE(type) #endif Do you think that there would be enough of a saving to make a difference? Currenly, the only overhead is a quick check of a bit value to see if the attribute is set (we do a similar check for read/write permissions). I would say that the safest way would be to actually profile this to see. Curt. -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Debugging Properties
David Megginson writes: Norman Vine writes: but how about having the compile time option to turn it off ie #ifdef DO_TRACE // or any good memonic #define DO_TRACE_READ(type) if(getAttribute(TRACE_READ)) trace_read(type) #define DO_TRACE_WRITE(type) if (getAttribute(TRACE_WRITE)) trace_write(type) #else #define DO_TRACE_READ(type) #define DO_TRACE_WRITE(type) #endif Do you think that there would be enough of a saving to make a difference? Currenly, the only overhead is a quick check of a bit value to see if the attribute is set (we do a similar check for read/write permissions). WHY do we we need this except when debugging ? Does it detract from the SIM if this is removed from production code ?? quoting Antoine de Saint-Exupery You know you've achieved perfection in design, Not when you have nothing more to add, But when you have nothing more to take away. Very good advice esp in a REALTIME SIM ! Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Debugging Properties
Curtis L. Olson writes: I would say that the safest way would be to actually profile this to see. Yes, it's probably time for a good profiling run -- identify the top offenders and optimize them, like we did last time with the FGMatrix class. I am very relucant to complicate code for presumed efficiency until I know that it will make a measurable difference. Unfortunately, one thing we cannot see through conventional profiling is the fact that the 2D panel is beating up on the framerate, not because of the property manager, but because of all the texture manipulation (AGP helps an awful lot here). A good OpenGL guru needs to go through panel.cxx and see where we can make optimizations. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rudder trim
Thanks, thats pretty much the same binding I used, but did not get any effect with JSBSim. I will give that a try though in YASim. As far as JSBSim I started looking at the code. It doesn't look like JSBSim is reading that one...although the interface does seem to be (initilizing?) a property called fdm/trim/rudder. Tried changing that in the air with propPicker...no effect and besides that just did some grepping of JSBSim code. But thats about as far as I got before resigning to the fact that once you're over forty sleep becomes a necessary thing. Best, Jim Andy Ross [EMAIL PROTECTED] said: Jim Wilson wrote: Is there any support for rudder trim...partially done or otherwise? The property is there, but it's not mapped to any input keystrokes or buttons in the default configuration. Add something like this to the keyboard.xml file to map rudder trim to and : (warning, untested, check my syntax and my ASCII, etc...) key n=62 namelt;/name descRudder trim left/desc binding commandproperty-adjust/command property/controls/rudder-trim/property step type=double-0.001/step /binding /key key n=64 namegt;/name descRudder trim right/desc binding commandproperty-adjust/command property/controls/rudder-trim/property step type=double0.001/step /binding /key I'm not sure if JSBSim reads it (it probably does), but YASim gets all of its control input via the XML aircraft description. On the YASim planes, only elevator trim is currently included (I was lazy) but adding rudder and aileron trim would be really easy. In the control tags for the appropriate part (wing, hstab, vstab), simply add a new entry. Here's a modified 172 vstab entry with rudder trim: vstab x=-7.16 y=0 z=.17 taper=.5 effectiveness=3 length=1.71 chord=1.54 sweep=20 stall aoa=16 width=4 peak=1.5/ flap0 start=0 end=1 lift=1.3 drag=1.5/ control axis=/controls/rudder output=FLAP0 invert=true square=true/ control axis=/controls/rudder-trim output=FLAP0 invert=true square=true/ /vstab YASim will sum multiple entries together when calculating the control deflection. I'll be putting together a new plane set this weekend with all the control inputs mapped, including things like slats and spoilers on the planes that have them. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Debugging Properties
Norman Vine writes: WHY do we we need this except when debugging ? Does it detract from the SIM if this is removed from production code ?? You need the trace feature for debugging user configuration, not just C++ code. Again, think of FlightGear as analogous to a word processor or spreadsheet: users will always be loading new kinds of data -- designing new panels and flight models, scripting events, creating scenarios, etc. etc. The trace feature gives some (pretty minimal) support for design, testing, and debugging their work. That said, if the SGPropertyNode::get* and SGPropertyNode::set* methods ever showed up as a measurable drag on execution time during profiling, I'd be very willing to look at optimizations, including inlining (I *hate* inline methods because they bloat object code and complicate debugging, but I'll use them when they bring a real, measurable benefit). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Debugging Properties
Norman Vine writes:
Of course please feel free to consider this just another of my 'rants' on
'the basic tenant of realtime programing'
I agree that we need to keep speed in our sights, but let's put this
in context. Here's a little program that I just wrote:
#include iostream
int
main ()
{
int x = 3;
for (int i = 0; i 10; i++) {
if ((x 1) == 0)
;
}
}
This runs 1 billion conditional tests. Actually it runs 2 billion
because of the conditional test in the loop, and it also increments
the i variable 1 billion times and performs a bitwise AND 1 billion
times. Here are the results of an execution run:
david@notebook:/tmp$ time ./conditionaltest
real 0m2.308s
user 0m2.240s
sys 0m0.040s
That's 2.24 seconds user execution time for all four operations 1
billion times on my little notebook. A computer with video card
running at 100 frames per second would have time for a little over 4
million of these tests between each frame; I doubt that we'll have
more than a few dozen property accesses per frame.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] B2 Cockpit VR view.
You might want to notice a few things: 4) the lens distorts the perspective a little, the lower left and right side panels are perpendicular to the flight deck Maybe I am not understanding what you mean. The panels with instruments to the left of the pilots left arm are what I am referring to (I thought this was what you were initially referring to). There are two of them, the upper left side panel is not vertically oriented, it is canted out from the vertical perhaps about 20 degrees. The lower left side panel is canted about 20 to 30 degrees, as well. It's the same thing on the right side. The comment I made about the shuttle cockpit panels being similar is due to having spent *lots* of time in the training simulators (usually in the middle of the night, as they were reserved for astronauts during the day). The picture you supplied doesn't show the flight deck to the point you would be able to fully realize the similarities. Try these: http://www.unitedspacealliance.com/press/meds/meds01b.jpg http://www.unitedspacealliance.com/press/meds/meds15b.jpg and compare with this: http://209.41.125.134/Sightings/Icons/B2Lores.jpg I wonder if this general arrangement might be pretty standard, so I should not be surprised at the similarity. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Compilation error for a newbie
I'm building FlightGear-0.7.8, but an error occurs when compiling Main : I'm running a SUN U60 with Solaris 7, plib is v. 1.4.2 simgear is 0.0.16, compiling without network-olk, gcc is 2.95. ... Making all in Main c++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -L/usr/local/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o options.o splash.o viewer.o viewer_lookat.o viewer_rph.o viewmgr.o ../../src/Aircraft/libAircraft.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/Objects/libObjects.a ../../src/Time/libTime.a ../../src/WeatherCM/libWeatherCM.a ../../src/Input/libInput.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen-lsgmath -lsgbucket -lsg debug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibssg -lplibsg -lmk4 -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lsocket -lpthread -lm-lplibsl -lnsl -lsocket -lplibsm -lplibul -lm ld: warning: relocation error: R_SPARC_32: file ../../src/FDM/libFlight.a(LaRCsimIC.o): symbol .LLC155: external symbolic relocation against non-allocatable section .stab; cannot be processed at runtime: relocation ignored Undefined first referenced symbol in file .LLC155 ../../src/FDM/libFlight.a(LaRCsimIC.o) ld: fatal: Symbol referencing errors. No output written to fgfs collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `fgfs' Current working directory /cip41/utilis/essjr/FlightGear-0.7.8/src/Main *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /cip41/utilis/essjr/FlightGear-0.7.8/src *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Anyone can help me ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] B2 Cockpit VR view.
I guess it is all in the eye of the beholder. I see significant difference in the function and symbology of the different displays and less in the physical layout. Agreed. I was really pointing out the physical similarity in the layout and arrangement of the panel faces. The specific instruments and controls will be different, of course. For example, the manual Solid Rocket Booster sep switch is hardly noticable in the B2. ;-) In both cases there appears to be few places to hang fuzzy dice. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Compilation error for a newbie
I believe someone reported something similar a while back (perhaps on sun hardware as well.) From the looks of the error message this appears to be some kind of bug down in the compiler/linker level, not a code bug. I don't recall anyone had any good ideas before on this. Could we be overflowing some limited structure in the linker ... two many symbols, too many something? Maybe something we are doing is triggering a bug somewhere? Are you using the gnu linker or the sun linker? I think gcc by default builds against the sun linker. It's probably a pain in the butt, but might be interesting to build gcc against the gnu ld ... Curt. Jerome RENARD writes: I'm building FlightGear-0.7.8, but an error occurs when compiling Main : I'm running a SUN U60 with Solaris 7, plib is v. 1.4.2 simgear is 0.0.16, compiling without network-olk, gcc is 2.95. ... Making all in Main c++ -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O2 -L/usr/local/lib -o fgfs main.o fg_commands.o fg_init.o fg_io.o fg_props.o fgfs.o globals.o options.o splash.o viewer.o viewer_lookat.o viewer_rph.o viewmgr.o ../../src/Aircraft/libAircraft.a ../../src/Autopilot/libAutopilot.a ../../src/Cockpit/libCockpit.a ../../src/Controls/libControls.a ../../src/FDM/libFlight.a ../../src/FDM/Balloon/libBalloon.a ../../src/FDM/JSBSim/libJSBSim.a ../../src/FDM/JSBSim/filtersjb/libfiltersjb.a ../../src/FDM/LaRCsim/libLaRCsim.a ../../src/FDM/UIUCModel/libUIUCModel.a ../../src/GUI/libGUI.a ../../src/Navaids/libNavaids.a ../../src/Scenery/libScenery.a ../../src/Sound/libSound.a ../../src/Airports/libAirports.a ../../src/Network/libNetwork.a ../../src/Objects/libObjects.a ../../src/Time/libTime.a ../../src/WeatherCM/libWeatherCM.a ../../src/Input/libInput.a -lsgroute -lsgsky -lsgephem -lsgtiming -lsgio -lsgscreen-lsgmath -lsgbucket -lsg debug -lsgmagvar -lsgmisc -lsgxml -lsgserial -lplibpu -lplibfnt -lplibssg -lplibsg -lmk4 -lz -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lsocket -lpthread -lm-lplibsl -lnsl -lsocket -lplibsm -lplibul -lm ld: warning: relocation error: R_SPARC_32: file ../../src/FDM/libFlight.a(LaRCsimIC.o): symbol .LLC155: external symbolic relocation against non-allocatable section .stab; cannot be processed at runtime: relocation ignored Undefined first referenced symbol in file .LLC155 ../../src/FDM/libFlight.a(LaRCsimIC.o) ld: fatal: Symbol referencing errors. No output written to fgfs collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `fgfs' Current working directory /cip41/utilis/essjr/FlightGear-0.7.8/src/Main *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Current working directory /cip41/utilis/essjr/FlightGear-0.7.8/src *** Error code 1 make: Fatal error: Command failed for target `all-recursive' Anyone can help me ? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Curtis Olson Intelligent Vehicles Lab FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Compiler error with Cygwin SimGear 0.0.16
Gents, When compiling SimGear 0.0.16 with the latest Cygwin (Win2K) I get the following compiler error. Has anyone else seen this? This is a clean SimGear with ./configure; make. Everything goes well until... Making all in simgear/metakit/unix make[1]: Entering directory `/home/fgfs_sw/SimGear-0.0.16/simgear/metakit/unix' /bin/sh ./libtool --mode=compile c++ -c -g -O2 -DNDEBUG -I../include -I../src -I . ../src/column.cpp mkdir .libs c++ -c -g -O2 -DNDEBUG -I../include -I../src -I. ./src/column.cpp -DDLL_EXPORT -DPIC -o .libs/column.lo c++ -c -g -O2 -DNDEBUG -I../include -I../src -I. ../src/column.cpp -o column.o /dev/null 21 mv -f .libs/column.lo column.lo /bin/sh ./libtool --mode=compile c++ -c -g -O2 -DNDEBUG -I../include -I../src -I . ../src/custom.cpp rm -f .libs/custom.lo c++ -c -g -O2 -DNDEBUG -I../include -I../src -I. ./src/custom.cpp -DDLL_EXPORT -DPIC -o .libs/custom.lo c++ -c -g -O2 -DNDEBUG -I../include -I../src -I. ../src/custom.cpp -o custom.o /dev/null 21 mv -f .libs/custom.lo custom.lo /bin/sh ./libtool --mode=compile c++ -c -g -O2 -DNDEBUG -I../include -I../src -I . ../src/derived.cpp rm -f .libs/derived.lo c++ -c -g -O2 -DNDEBUG -I../include -I../src -I. ./src/derived.cpp -DDLL_EXPOR T -DPIC -o .libs/derived.lo ../src/derived.cpp: In method `c4_SortSeq::c4_SortSeq(c4_Sequence , c4_Sequence *)': ../src/derived.cpp:701: Internal compiler error. ../src/derived.cpp:701: Please submit a full bug report. ../src/derived.cpp:701: See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. make[1]: *** [derived.o] Error 1 make[1]: Leaving directory `/home/fgfs_sw/SimGear-0.0.16/simgear/metakit/unix' make: *** [all] Error 1 Can anyone shed some light on this? Thanks, Paul Paul R. Deppe Veridian Engineering (formerly Calspan) Flight Aerospace Research Group 150 North Airport Drive Buffalo, NY 14225 (716) 631-6898 (716) 631-6990 FAX [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
