Andy Ross writes:
These are clearly related to texture loading. How long did you run
your profiler for? If it was just for a few seconds, then these might
be showing the time spent in initialization and not in the routine
frame-to-frame running of the program. Certainly, parsing and
Norman Vine writes:
Nice addition
Thanks.
No need for an 'expensive' derivation
of the rotation matrix though as you can
straight forwardly write it out all at once
Thanks! Your changes seem to make a big different -- I'm not seeing
any stuttering at the beginning, now. I've
I've committed Andy's patch for sorting the properties in the property
browser.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
David Megginson writes:
There are two important C++ APIs you have to learn for properties -- I
added extensive documentation comments to both so that contributors
won't have to guess how to use them. The low-level implementation is
declared in simgear/misc/props.hxx, and Curt has
On Tue 26. February 2002 14:52, you wrote:
Almost all of the major moving surfaces in the C172 are now animated:
It's wonderfull work.
There is a problem with propeller. With low frame rate I couldn't see
diferents between low and high RPMs. There is obvious to add instead of
rotating
Martin Dressler writes:
On Tue 26. February 2002 14:52, you wrote:
Almost all of the major moving surfaces in the C172 are now animated:
It's wonderfull work.
There is a problem with propeller. With low frame rate I couldn't see
diferents between low and high RPMs. There is obvious to
Tony Peden writes:
Is there a way to dump the entire tree to xml (whether or not the
archivable bit is set)?
Not currently, but I can modified writeProperties to take an extra,
optional argument, then make a dump-properties command.
All the best,
David
--
David Megginson
[EMAIL
I'm trying to compile FG using VC6 but this error occurs
Compiling...
atis.cxx
c:\simgear-0.0.17\simgear\metakit\include\mk4.inl(181) : error C2593:
'operator ' is ambiguous
c:\simgear-0.0.17\simgear\metakit\include\mk4.inl(187) : error C2593:
'operator ' is ambiguous
David Megginson [EMAIL PROTECTED] said:
Martin Dressler writes:
There is a problem with propeller. With low frame rate I couldn't see
diferents between low and high RPMs.
Even with a fairly good framerate the prop doesn't look so good yet.
What we need to do is switch to a
I'm now working on Ground view mode and I just go through code to fully
understand the problem. I find some small nearly cosmetic bugs.
What is the best way to rapair them. Should I make diff of affected code
or should I tar the whole file. Should I repair only one bug in one patch. Or
could I
On Wed, 27 Feb 2002 11:28:01 -0500
David Megginson [EMAIL PROTECTED] wrote:
The good news is that the JSBSim matrix support isn't
showing up on the radar screen any more.
Thanks to the work by Norman and Tony (IIRC). I think we
can still make some improvements in JSBSim and I want to
try
Martin Dressler writes:
I'm now working on Ground view mode and I just go through code to
fully understand the problem. I find some small nearly cosmetic
bugs. What is the best way to rapair them. Should I make diff of
affected code or should I tar the whole file. Should I repair only
Very nice. Please make sure it scales nicely, just by replacing the
panel graphics and hotbutton list, for one axis and three axis modes.
Third axis is autothrottle. Some notes, and additional functions.
ButtonName - Description of function
RATE - Turn rate, range of +/- 1 standard rate,
Tony Peden writes:
It seems very strange to me, however, that FGInterface::operator=
would show up at all. According to that output, it was called
almost 200,000 times. What's up with that?
Do we keep two copies and swap between them?
All the best,
David
--
David Megginson
[EMAIL
Andy Ross [EMAIL PROTECTED] said:
at all. Definitely recommended. One one caveat: it's USB response is
slower than the spec allows, so the linux driver doesn't work out of
the box. You need to enable the slow USB devices option when you
compile your kernel. The default Red Hat kernels
On Wed, 2002-02-27 at 10:59, Tony Peden wrote:
On Wed, 2002-02-27 at 10:22, David Megginson wrote:
Tony Peden writes:
It seems very strange to me, however, that FGInterface::operator=
would show up at all. According to that output, it was called
almost 200,000 times. What's up
On Wed, 27 Feb 2002 17:23:43 -
Jim Wilson [EMAIL PROTECTED] wrote:
ButtonName - Description of function
HDG - will switch heading hold over to the Bug.
Also need roll attitude hold which overrides heading
select.
Of course this means that it'll also be possible to hold
a pitch angle
On Wed, 2002-02-27 at 09:00, Vallevand, Mark K wrote:
I probably doesn't get called that many times. Most profiling
software picks up some cruft. There is probably some bit of code
located just after FGInterface::operator= that *is* called a lot,
but doesn't have any debug information
Andy Ross [EMAIL PROTECTED] said:
Jim Wilson wrote:
Andy Ross wrote:
at all. Definitely recommended. One one caveat: it's USB response
is slower than the spec allows, so the linux driver doesn't work out
of the box. You need to enable the slow USB devices option when
you
David wrote:
For example, the
program spent 2.95% of its time in ssgVtxTable::getNumVertices,
This simply calls getNum of the list, which simply returns a member
variable:
int getNum (void) { return total ; }
See ssg.h.
David
Bye bye,
Wolfram.
Curtis L. Olson wrote:
Martin Dressler writes:
I'm now working on Ground view mode and I just go through code to
fully understand the problem. I find some small nearly cosmetic
bugs. What is the best way to rapair them. Should I make diff of
affected code or should I tar the whole
On Wed, Feb 27, 2002 at 12:50:09PM -0800, Andy Ross wrote:
Curtis L. Olson wrote:
Martin Dressler writes:
I'm now working on Ground view mode and I just go through code to
fully understand the problem. I find some small nearly cosmetic
bugs. What is the best way to rapair them.
Tony Peden wrote:
Andy Ross wrote:
+ They're more human readable. Inevitably, you're going to be doing a
diff between revisions to see what's changed anyway. This just give
it to you up front. If you want to look at more surrounding code,
you certainly can, but everyone
Andy Ross writes:
Curtis L. Olson wrote:
Martin Dressler writes:
I'm now working on Ground view mode and I just go through code to
fully understand the problem. I find some small nearly cosmetic
bugs. What is the best way to rapair them. Should I make diff of
affected code or
To answer my question, I got into the code and put in
a slow motion factor. I can now fly as slowly as I
want.
-Original Message-
From: Boslough, Mark B [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, February 26, 2002 5:05 PM
To: '[EMAIL PROTECTED]'
Subject: [Flightgear-devel] Speed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, 28 Feb 2002 07:37, you wrote:
To answer my question, I got into the code and put in
a slow motion factor. I can now fly as slowly as I
want.
Shift Z should slow it down anyway. Z doubles the speed, shift-z halves the
speed, AFAIK. At
I don't quite not how to respond here, except to point out that simply
isn't the case. The diff program was always meant to be human
readable from the very beginning. And it's gotten more so over time,
You just keep thinking this way...
Do you still program on punch cards too? ;-)
Jon
Well, no, not specifically with operator=. But, my point is
that operator= might not be involved. It also depends on the
kind of profiler used. If its a profiler that is enabled with
compiler switches and code to count calls is compiled in, then
my point is not valid. However, some profilers
Jon S Berndt writes:
I don't quite not how to respond here, except to point out that simply
isn't the case. The diff program was always meant to be human
readable from the very beginning. And it's gotten more so over time,
You just keep thinking this way...
Do you still program on
On Wed, 27 Feb 2002 14:37:13 -0700
Boslough, Mark B [EMAIL PROTECTED] wrote:
To answer my question, I got into the code and put in
a slow motion factor. I can now fly as slowly as I
want.
Can you send me your latest copy of the config file? I'll
get it into CVS.
Jon
Curtis L. Olson wrote:
It does do a pretty darn good job all things considered, but it's not
magic and it can't figure the 'right' thing to do given a conflicting
situation. And the number of times conflicting situations arise is
more than most patch apologists would probably admit. :-)
On Wed, 27 Feb 2002 14:04:26 -0800
Tony Peden [EMAIL PROTECTED] wrote:
I'll certainly agree that the patch format is a good way to represent
the changes between two files -- but not to the extent that it is good
at communicating that information to humans. The simple fact is that
humans
Andy Ross writes:
Of course it can't. It's a Hard problem, and requires peoples' brains
to solve in the general case. This is no different for patch than it
is for whole-file transfers. I'm not asking you to patch blindly, and
if that's the way you've been doing it, I submit that perhaps
Jon S Berndt writes:
I don't quite not how to respond here, except to point out that simply
isn't the case. The diff program was always meant to be human
readable from the very beginning. And it's gotten more so over time,
You just keep thinking this way...
Do you still program
On Wed, Feb 27, 2002 at 01:59:27PM -0600, Vallevand, Mark K wrote:
Well, no, not specifically with operator=. But, my point is
that operator= might not be involved. It also depends on the
kind of profiler used. If its a profiler that is enabled with
compiler switches and code to count
David, all sounds like great stuff. Did you figure out how to smooth
your .ac models?
Curt.
David Megginson writes:
The DC-3 3D model now has the following surfaces animated:
- left and right propellers (it's a lot of fun watching them start
with Andy's latest YASim changes)
- left
David Megginson wrote:
Changes for gear and flaps are still abrupt, but I have great faith
that I'll be able to get the normalized gear and flap positions from
YASim very, very soon now.
Actually, now that the subject's been brought up, I realize that YASim
doesn't time-interpolate the
On Wed, 27 Feb 2002 15:10:14 -0800
Andy Ross [EMAIL PROTECTED] wrote:
And I'm being sneered at as a card-punching dinosaur
Not sneered at. Have you tried an IDE such as the one Tony
and others describe?
(by IDE jockeys who can't read man pages
because there isn't a toolbar button for
calc_magvar() is interesting ... that might be something we wouldn't
have to do every frame ...
For what this may be worth, where I work (Rockwell Collins), we do mag var
computations about once every two minutes. Even given some of the
aircraft for which we design (KC-135, B-1B, 747),
Tony Peden writes:
JSBSim is currently exporting this into /gear/position as well as other
gear info like the WoW flag.
Do we want /engine and /gear ?
We need someone with an organizational mind to look at the current
property tree and recommend ways to improve its setup.
All the
Tony Peden writes:
Gear could be trivially exported. Where do you want it? How about
/control-positions/gear[n]/extension-fraction?
JSBSim is currently exporting this into /gear/position as well as other
gear info like the WoW flag.
Do we want /engine and /gear ?
Further to
John Check wrote:
Andy Ross wrote:
One rocker axis on the throttle to simulate rudder (not very
well -- I still use my analog TM pedals for that).
Rudder control is really what I'm interested in. I tried binding the
throttle wheel of my gravis Blackhawk, but the pot is super cheesy.
Andy Ross writes:
David Megginson wrote:
Andy Ross writes:
Gear could be trivially exported. Where do you want it? How about
/control-positions/gear[n]/extension-fraction?
I want you and Tony to put it in exactly the same place, whatever that
place may be.
Heh, here's
David Megginson [EMAIL PROTECTED] said:
The DC-3 3D model now has the following surfaces animated:
Looks really cool! I think right elevator and inner right flap might not be
working. Or maybe I banged them up during my sloppy take off :-)
Best,
Jim
Hello all,
The recent animation is great. A detail or 2 from a system with limited
frame rate (about 10 initial, due to Pentium-233 probably). If the
transition to translucent disk from prop gets implemented, it might be a
thought to base the cutover on the frame rate, as us slowpokes
David Megginson wrote:
I did another run, with a flight of over one hour on autopilot.
Cumulatively, ssgEntity::cull_test and ssgBranch::cull use nearly 20%
of CPU time -- that's OK, as long as the framerate improvements
justify the work.
Yes - that's probably not too bad...but with it
I was playing around with the viewpoint code tonight and have a
question. If I have a Vec3 in opengl coords, can I translate that to
geod coords? I've looked through the simgear math functions and
couldn't find anything suitable. Thanks
--
Cameron Moore
:wq
47 matches
Mail list logo
