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
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)
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
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
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo
