One other nit: retracting the gear while sitting on the runway doesn't
work like it should. :-)
I'm happy that is works as it does now, because I don't get an airplane
crash when I forget the gear before landing :-)
Martin.
--
Unix _IS_ user friendly - it's just selective about who
snip
altimeter-datum-mb1013.25/altimeter-datum-mb
I assume that this is the setting for the WGS-84 datum.
It is the pressure setting on the altimeter, that can be
adjusted by
turning the knob on the altimeter.
I assume that it is in mm of Hg?
No, it is in millibar (mb) as
altimeter-datum-mb1013.25/altimeter-datum-mb
I assume that this is the setting for the WGS-84 datum.
It is the pressure setting on the altimeter, that can be adjusted by
turning the knob on the altimeter.
I assume that it is in mm of Hg?
It is in milibars ie 1mb=100 Pascal
Norman Vine writes:
David Megginson writes:
Norman Vine writes:
Old binary (about 2 days old, pre-property changes)
---
From 4,000 ft: 45-46 fps
From 8,000 ft: 29-30 fps
Current CVS
---
From 4,000 ft: 49-50 fps
David Findlay writes:
This might be of use to us. Could we include this sort of data in
the FGFS scenery?
No, we cannot, with our current approach -- it would create far too
many polygons. Even moving to VMap1 pretty-much kills the scenery
engine, and that just adds major regional roads
Tony Peden has been working quietly for the last couple of weeks
incorporating the property manager into JSBSim itself. He checked the
results into CVS this morning, and they are very impressive: in
FlightGear (using JSBSim, of course) open the property browser and
look under /fdm/jsbsim for an
Richard Bytheway writes:
I have noticed that when compiling --with-jpeg-factory on
cygwin (Win98) I get an error regarding redefinition of (long)
int types between the jpeg headers and win32 headers.
I can't remember the exact details, will post them tomorrow.
~ line 250 jmorecfg.h
--- David Megginson [EMAIL PROTECTED] wrote:
Tony Peden has been working quietly for the last
couple of weeks
incorporating the property manager into JSBSim
itself. He checked the
results into CVS this morning, and they are very
impressive: in
FlightGear (using JSBSim, of course) open
David Megginson wrote:
Norman Vine writes:
Current CVS with Norm's main.cxx patch added
From 4,000 ft: 49 fps
From 8,000 ft: 35 fps
Hmm...
My guess is that this has something todo with your running in
a wIndow and glut
Tony Peden wrote:
--- David Megginson [EMAIL PROTECTED] wrote:
Tony Peden has been working quietly for the last
couple of weeks
incorporating the property manager into JSBSim
itself. He checked the
results into CVS this morning, and they are very
impressive: in
FlightGear (using JSBSim, of
If David doesn't beat me to it, I'll do it when I get
home this evening.
--- Erik Hofman [EMAIL PROTECTED] wrote:
Tony Peden wrote:
--- David Megginson [EMAIL PROTECTED] wrote:
Tony Peden has been working quietly for the last
couple of weeks
incorporating the property manager into
Aaaah, that sounds interesting. Are you building FlightGear on Tru64 or on
Linux ? I have a 300 MHz AlphaServer1000 at home - yet without graphics
board - with Tru64 on it. Although my machine don't have an AGP slot (does
your's ? I believe r128 is AGP only !?) I might put some other PCI board in
Marten Stromberg wrote:
Roman Grigoriev wrote:
Guys
could you please explain me some state of things
1) plib and vertex arrays
Does this feature implement yet in plib or not
if not mybe there are some suggestions how to make it
As I understand now plib works with display lists
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.21 08:58]:
Index: panel_io.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel_io.cxx,v
retrieving revision 1.36
retrieving revision 1.37
diff -C2 -r1.36 -r1.37
I've now modified the property-manager interface to use const char *
instead of std::string throughout the public interface [...]
I have the impression that the flaps are gone. I try to set the flaps via
], I can see the lever moving over the panel but I can't 'feel' the flaps
and they don't
Tony Peden has been working quietly for the last couple of weeks
incorporating the property manager into JSBSim itself. He checked the
results into CVS this morning, and they are very impressive: in
FlightGear (using JSBSim, of course) open the property browser and
look under /fdm/jsbsim
When I try to switch to a mini-panel, I always get a segfault (I've
tested in c172 and c310). Is anyone else seeing this? I'm using a
clean CVS build from yesterday (ie. prior to David's property code
changes) with no command-line options. Thanks
It was working for me a couple of days
This is a banner week for major FlightGear code overhauls. Jim
Wilson's excellent view-code rewrite is now in the CVS. We should be
very close now to adding a tower view and a more usable 3-D cockpit,
among many other things.
I should also give additional thanks to Norman Vine, who wrote the
Sounds to me like you've got that wing section (i.e. the flap) beyond the
peak of the L/D curve, while the bulk of the wing is in front of the L/D
curve. If that is the case, it is certainly something that will often happen
in real life and your solver needs to cope with it. Without looking at
Jim Wilson wrote:
David Megginson [EMAIL PROTECTED] said:
I've fixed everything I could find in the code base (engine sound
isn't working, but it wasn't working before my mods either),
Engine sound seems to be working, but I notice on the c172-3d the volume is
quite low (and the wheel
Andy Ross [EMAIL PROTECTED] said:
Erik Hofman wrote:
While I don't see a direct improvement in framerate I notice a real
effect on the screen update. The old behaviour had a small bump in the
update every second or so, while the new code elliminates that.
This doesn't make much
I don't know, cpu cycles are cpu cycles...they're good for anything aren't
they? If you reduce per-frame-code-load then that frees time up for other tasks
like disk io. Or am I confused about this?
You are confused about that.
Most modern processors are memory bandwidth limited. That's
Curtis L. Olson writes:
Here's a couple things that have surfaced after the recent rewrites:
- The AGL instrument on the default HUD appears to now be in meters.
Altitude is still in feet. If you pop on the hud and assume the agl
is in feet, you will be way off ... this should get
Andy Ross writes:
Oooh, which reminds me: has the default logging level changed? I was
noticing last night that lots of stuff that used to be printed isn't
anymore, including the YASim solution report which I'd like to
preserve. I looked briefly for something that might have changed,
David Megginson writes:
Curtis L. Olson writes:
Here's a couple things that have surfaced after the recent rewrites:
- The AGL instrument on the default HUD appears to now be in meters.
Altitude is still in feet. If you pop on the hud and assume the agl
is in feet, you will be
David Megginson writes:
Andy Ross writes:
Oooh, which reminds me: has the default logging level changed? I was
noticing last night that lots of stuff that used to be printed isn't
anymore, including the YASim solution report which I'd like to
preserve. I looked briefly for
Curtis L. Olson writes:
I'm noticing some feet/meter problems as well. I also noticed that
--altitude= on the command line was giving me meters rather than
feet.
Could this be a side effect of the property manager overhaul? I'm not
sure what else has changed recently that could
JSBSim is no longer setting the /surface-positions/flaps-norm
property, so the flaps don't move in the animation and don't make a
sound. The position is still set correctly in /controls/flaps, and
flap animation works as usual with --aircraft=c172-yasim.
All the best,
David
--
David
Andy Ross writes:
That's exactly the idea. You take a plane of instruments (what
we're currently calling a panel XML file) and project it into 3D space
via specifying corners. It draws on top of the existing stuff, with
no problems whatsoever. If you want to have only one instrument
Jonathan Polley wrote:
I just updated to the newest SimGear and tried to build under Windows using MSVC
6.0. When I did so, I got the following errors:
I haven't tried it since the last major checkins :(
Linux was just fine. Is there a problem with MS' implementation of STD?
That's more
Andy Ross writes:
This is rapidly getting on towards voodoo coding, and I think perhaps
we should step back a bit. What, exactly, are the changes in this
patch that make it worthwhile? What does it eliminate? What is the
evidence for speedup?
gprof is your friend
Cheers
NOrman
It seems to be minor nit time, so here goes:
The tiled panel has lines between the sections - is anyone else
seeing this or is it a Windows only problem.
As someone else has pointed out, resizing the screen can cause
the panel to obscure the runway. In general the panel could be
made
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Mar 2002 22:31, you wrote:
David Findlay writes:
This might be of use to us. Could we include this sort of data in
the FGFS scenery?
No, we cannot, with our current approach -- it would create far too
many polygons. Even moving
Jon S Berndt wrote:
On Wed, 20 Mar 2002 22:55:23 +0100
Christian Mayer [EMAIL PROTECTED] wrote:
So there used to be a lot of STL problems where Linux coders wrote non
standard compliant STL code that brok on MSVC. (They are not really to
blame as they have no chance to test their code
On Wed, 20 Mar 2002 22:55:23 +0100
Christian Mayer [EMAIL PROTECTED] wrote:
So there used to be a lot of STL problems where Linux coders wrote non
standard compliant STL code that brok on MSVC. (They are not really to
blame as they have no chance to test their code on MSVC; and they are
Norman Vine writes:
This is rapidly getting on towards voodoo coding, and I think perhaps
we should step back a bit. What, exactly, are the changes in this
patch that make it worthwhile? What does it eliminate? What is the
evidence for speedup?
gprof is your friend
gprof will
Jon S Berndt writes:
I remember there was also perfectly good code that broke
under MSVC. Is this one fixed:
{
for (int i=0;i5;i++) {
// do something
}
for (int i=7;i13;i++) {
// do something else
}
}
The second for loop was causing problems with MSVC because
it choked
Norman Vine wrote:
Removed fgReshape() call from main loop
That's undoubtedly a good thing. Never mind who can see a speed benefit and who
can't. I can only imagine it was put there to work around some bug. If so, let's see
if the bug shows up again, and fix it properly if it does.
Not fixed in VC6. Fixed in VC7.
However, the STDLIB and STL implementations in VC6 and VC7 are very good.
But, they weren't written by Microsoft. They were written by P.J. Plauger's
company.
Regards.
Mark K Vallevand
Fat, dumb and happy. 2 out of 3 ain't bad.
I remember there was also
Are we finding that inlining is unneccesary? I am
wondering if Tony and I need to un-inline most of our
currently inlined items? We have a lot of access methods
that simply return a private value. Those at least seem to
be classic cases for inlining. What's everyone else doing?
Jon
David Megginson wrote:
Andy Ross writes:
That's exactly the idea. You take a plane of instruments (what
we're currently calling a panel XML file) and project it into 3D
space via specifying corners. It draws on top of the existing
stuff, with no problems whatsoever. If you want
Curtis L. Olson wrote:
In the c172-yasim external view, the rudder animation on the 3d
model is reversed. Everything else seems to go the correct
direction.
Does the YASim -set file use a different model from the JSB one? This
is probably a convention collision between YASim and JSB. My
Julian Foad wrote:
Norman Vine wrote:
Removed fgReshape() call from main loop
That's undoubtedly a good thing. Never mind who can see a speed benefit and who
can't. I can only imagine it was put there to work around some bug. If so, let's
see if the bug shows up again, and fix it
Norman Vine wrote:
The second for loop was causing problems with MSVC because
it choked on the for-block-scoped int i declaration.
AFAIK only in the new 'net' compiler
In the new .NET compiler (i.e. version 7) it's fixed, the old one (MSVC
6) has that problem.
Note however that
MSVC 6.0 still whines about
props.cxx
C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not a member of 'std'
C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol cannot be used in a using-declaration
C:\SimGear\simgear\misc\props.cxx(801) : error C2065: 'sort' :
Cameron Moore wrote:
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.21 08:58]:
Index: panel_io.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel_io.cxx,v
retrieving revision 1.36
retrieving revision
David Megginson writes:
In my (limited) tests, even inlining something like
void setFoo (double foo) { _foo = (foo 0 ? 0 : foo); }
slows things down.
Really ??
then try this both with and without optimization :-))
== cut ===
#include iostream
#include time.h
#define NUM_TESTS
Jonathan Polley wrote:
MSVC 6.0 still whines about
props.cxx
C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not a member of
'std'
C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol cannot be used
in a using-declaration
Norman Vine wrote:
Really ??
then try this both with and without optimization :-))
This program fits easily into the L1 cache. FlightGear does not. For
small programs, total instructions executed is more important than
code size. For most real programs on modern processors, just the
Norman Vine wrote:
However some code fragments run 100's or even 1000's of times per
iteration and these fragments should be studied on an individual basis
and not just automatically un-inlined because it is in 'vogue' :-)
It's even more complicated than that. If you call a function
On Wednesday, March 20, 2002, at 06:00 PM, Christian Mayer wrote:
Jonathan Polley wrote:
MSVC 6.0 still whines about
props.cxx
C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not a
member of 'std'
C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol
Here's a backtrace on this.
Best,
Jim
#0 0x82ddfba in SGPropertyNode::clear_value (this=0x9747f90) at props.cxx:464
464 delete _value.string_val;
#1 0x82de8e0 in SGPropertyNode::~SGPropertyNode (this=0x9747f90, __in_chrg=3)
at props.cxx:672
#2 0x806c0e0 in
After getting SimGear to build under MSVC 6.0 (thanks Christian), I moved
on to getting all of FlightGear to build. For some reason, MSVC does not
like JSBSim (over 1200 errors generated) but I had no problem under RH 7.1
(as usual). I expect that everything is a snow ball started from the
On Wed, 20 Mar 2002 09:32:22 +0100 (CET),
Martin Spott [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
One other nit: retracting the gear while sitting on the runway
doesn't work like it should. :-)
I'm happy that is works as it does now, because I don't get an
airplane crash
On Wed, 20 Mar 2002 09:29:39 -0800 (PST),
Alex Perry [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
I totally forgot Are you (Alex) using an Nvidia graphics
board ?
Occasionally; the E-machines chassis I support for demo usage at LWCE
SFO, for example, has a TNT2 card in
On Thu, 21 Mar 2002 08:18:17 +1000,
David Findlay [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 20 Mar 2002 22:31, you wrote:
David Findlay writes:
This might be of use to us. Could we include this sort of data in
the
Andy Ross wrote:
FWIW, my interest in un-inlining stuff has nothing to do with runtime
performance at all. What I want to see is for FlightGear to compile
in something under 20 minutes on my machine. Some parts are really
just terribly slow to build. JSBSim and UIUC are big culprits
Andy Ross writes:
FWIW, my interest in un-inlining stuff has nothing to do with runtime
performance at all.
Understood but why didn't you just say this rather then talk about
runtime performance ??? see below
What I want to see is for FlightGear to compile
in something under 20 minutes on my
nhv@SFDEV3::/src/FlightGear% time ./bootstrap.sh
..
real19m42.347s
user17m30.419s
sys 2m18.101s
So it looks like 20 minutes is a reality on somewhat 'modest' machines
And Cygwin is a slow poke :-)
FWIW_2 with above tricks for optimized YASIM build times
Tony,
I received your email to me a weaks ago.
I test it and read the source in the past 2 days.
Yes, It works very well!!! Now my plane can flying steadily with your trimming routine.
Thank you very much!
A good guy you are! :)
I belevie I almost understand how can you achieve the purpose of
60 matches
Mail list logo
