I have put a replacement Main / main.cxx on my site
http://www.vso.cape.com/~nhv/files/fgfs/nhv_main.tgz
You should experience a substantial increase in fps with this
I get around a ~10% speedup
There is a small problem with the Display occasionally
because I could not figure out a way to have f
If I may add my US$0.02. I prefer to have the more verbose preferences
file as well. From the perspective of someone who does not want to look
through the code (not me, but those to whom I will be giving FlightGear),
it would be nice if they can see all configurable options (without
exceptio
Tony Peden wrote:
> Andy Ross wrote:
> > You're not changing the trim settings when you do this, right?
>
> He had the autopilot on, maintaining 1000 ft. So, yes, the trim was
> changing.
Ooh, ack. You're right, I should have read more carefully. Something
is definitely wrong, adding flap
Andy,
I had the autopilot on the entire time during the test and it was
maintaining 1000' ASL the whole time. So, yes, the autopilot was
changing the trim to hold a constant altitude.
So, if I am at my max speed with 0 flaps in a straight and level
configuration, then there is *no way* that low
> so we can run for example ./configure --with-nvidia-ext
I'd like to mention that I have strong feelings against use of proprietary,
single vendor extensions in the main source tree,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
-
On Mon, 2002-03-18 at 14:41, Andy Ross wrote:
> [[Whoops, my To: line wasn't, so the first time this got sent is went
>into the moderator queue. Moderators, please ignore. My
>apologies]]
>
> [This came in private mail, but it involves questions that I think the
> rest of the list mig
I wrote:
> Right now, YASim applies all of the "extra" lift due to flap
> deflection (including control surfaces -- they're flaps too) at a
> point one third of the way up from the trailing edge.
Oops, I lied. There was a bug. One third from the edge is what I
meant. One third from the *cen
On Mon, 18 Mar 2002 14:41:55 -0800
Andy Ross <[EMAIL PROTECTED]> wrote:
>
>What you're seeing is the fact that, when you add flaps, you increase
>the nose-down pitching moment of the wing. This happens,
>qualitatively, because most of the lift you add gets
>added at the back of the wing where
Norman Vine wrote:
>
> David Megginson writes:
> >
> >Norman Vine writes:
> >
> > > IMHO the biggest obstacle to reading and developing FGFS code is
> > > the formatting
> > >
> > > We really need a mechanical formating means that is acceptable to
> > > every one as the CVS standard even if it is
David Megginson writes:
>
>Norman Vine writes:
>
> > IMHO the biggest obstacle to reading and developing FGFS code is
> > the formatting
> >
> > We really need a mechanical formating means that is acceptable to
> > every one as the CVS standard even if it is not perfect or even
> > close to what
David Megginson wrote:
>
> I have a question for the C++ heads. Let's assume that I have
> something like this:
>
> template
> T
> Binding::get_value () const
> {
> return (_obj.*_getter)();
> }
>
> assuming
>
> C &_obj;
> T (C::*_getter)() const;
>
> This always gets inst
Hi,
there's seems to be a bug under Linux that I can't reproduce under
windows.
To triger it, go to /flightgear/src/main/fg_init.cxx and "change"
WeatherDatabase = FGLocalWeatherDatabase::theFGLocalWeatherDatabase;
to
WeatherDatabase = FGLocalWeatherDatabase::theFGLocalWeatherDatabase;
Weathe
Andy Ross <[EMAIL PROTECTED]> said:
> David Megginson wrote:
> > Tony reported back to the list on a more organic test -- he un-inlined
> > the most common inline methods in JSBSim, and discovered a slight (but
> > not exciting) speed *increase*.
>
> Actually, my interest would be in a differ
David Megginson <[EMAIL PROTECTED]> said:
> Here are some tests I just ran, for 100,000,000 accesses of a double
> property (I ran each on a few times then picked the most typical user
> time; there was little variation anyway):
>
> Tied to object methods: 5.880 sec
> Internal (access only):
--- David Megginson <[EMAIL PROTECTED]> wrote:
> Andy Ross writes:
>
> > This would require changing the defaulting
> semantics, though. The
> > "default" value you fill in at parse-time should
> be true, but the
> > "default" you fill in when a non-existent
> property is queried should
> >
David Megginson writes:
>
>I have a question for the C++ heads. Let's assume that I have
>something like this:
>
> template
> T
> Binding::get_value () const
> {
>return (_obj.*_getter)();
> }
>
>assuming
>
> C &_obj;
> T (C::*_getter)() const;
>
>This always gets instantiated corre
On Mon, 18 Mar 2002 02:27:03 +0100 (CET),
Martin Spott <[EMAIL PROTECTED]> wrote in message
<[EMAIL PROTECTED]>:
> > Interesting note, the top item on the list, "Racer" is not GPL or
> > anything close to opensource ( see http://www.racer.nl/legal.htm ).
>
> I totally forgot Are you (Al
Andy Ross writes:
>
>Or, maybe better still (simpler anyway), just rename the function in
>hitlist.cxx to fgPointInTriangle and simply use that, ignoring plib
>entirely.
Already Done
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://
Andy Ross writes:
> >
>
> This is more readable to my eyes too, which is why the YASim parser
> uses attributes.
If it's any comfort, this is a general problem in XML: the more
general we make a format, the less we can use optimizations like
these, but the more specialized we make a forma
Andy Ross writes:
>
> A
> B
>
This already works as you would expect. Multiple children with the
same name are automatically numbered sequentially when there is no "n"
attribute, so the above is synonymous with
A
B
I tend often to include "n" anyway, just to help people
Andy Ross writes:
> > Tony reported back to the list on a more organic test -- he un-inlined
> > the most common inline methods in JSBSim, and discovered a slight (but
> > not exciting) speed *increase*.
>
> Actually, my interest would be in a different benchmark: how much does
> removi
David Megginson wrote:
> I'm not sure if that's a good idea -- I'd be more inclined to default
> to 0/false/empty-string. What do other people think?
Actually, thinking about this more, I'm starting to like this idea.
As you say, it's really the same thing as changing the default value
for a b
David Megginson wrote:
> In other words, you'd like
> to be the equivalent oftrue
> or 1
>
> I'm not sure if that's a good idea -- I'd be more inclined to default
> to 0/false/empty-string. What do other people think?
I'm of the same opintion. The
David Megginson wrote:
> Tony reported back to the list on a more organic test -- he un-inlined
> the most common inline methods in JSBSim, and discovered a slight (but
> not exciting) speed *increase*.
Actually, my interest would be in a different benchmark: how much does
removing all the inl
Is there currently anywhere in the code where I can say:
Here's a ssgEntity already loaded.
Here's its position, heading, roll and pitch this frame, draw as
appropriate (ie work out the appropriate transform in relation to the
viewer for me).
Allow the position, heading roll and pitch to be upd
Keith Wiley writes:
>
>I'm building straight from the cvs checkout code.
>
>Making all in Scenery
>make[2]: Entering directory `/usr/local/src/Flightgear/src/Scenery'
>c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../..
>-I../../src -I/usr/loca
>l/include -g -O2 -c hitlist.cxx
>hitlist.cxx
I'm building straight from the cvs checkout code. I completely erased my
previous flightgear directory, so there is no chance of cvs of losing
track of which files need to be updated. It still doesn't work:
Making all in Scenery
make[2]: Entering directory `/usr/local/src/Flightgear/src/Scenery
Jim,
That's the Welsh Assembly Minister for E-commerce (government bloke).
Regards
Phil
In message <[EMAIL PROTECTED]>,
"Jim Wilson" <[EMAIL PROTECTED]> writes:
> Both projects look very interesting. I've got only have one decidedly
> irrelevant question. Phillip, I always thought
Both projects look very interesting. I've got only have one decidedly
irrelevant question. Phillip, I always thought that was you in these
pictures: http://www.flightgear.org/Projects/ALTAIR/ . But now I see:
http://www.aber.ac.uk/~dcswww/Admin/staff/HTML/prs94.html . So who is the
guy in the
Norman Vine wrote:
< clarifying my earlier post >
>
>Also note that most FGFS functions are only called
at most !
>once or twice per iteration of the main loop
>
>A 'few' more 'interesting' ones are called MANY TIMES
>per iteration of the loop. IMHO these if they meet the
>above criteria are
David Megginson writes:
>
> Without
>inlined methods, we'll probably end up with a smaller fgfs executable,
>more accurate debugging information, faster build times, and more
>readable headers, etc.
>
>If we default to out-of-line code, then we can profile later and
>inline only in the spots wher
David Megginson writes:
>
>Tony Peden writes:
>
> > To get the equivalent of tieing to object methods, a
>once-per-frame data
> > copy is necessary. Did your testing take this into account?
>
>No, I was just testing access time. I checked in some optimizations
>that skip a lot of unnecessary c
On Monday 18 March 2002 10:57 pm, you wrote:
> * [EMAIL PROTECTED] (Jonathan Polley) [2002.03.18 21:44]:
> >1
>
> I'm not familiar with our XML parser, but could we get away with using
> this instead?:
>
>
>
> What we currently use seems a bit much for a simple boolean. Thanks
Thats
Jon Berndt writes:
> I've had some thoughts along those lines, too. Note that I am not so
> familiar with proper XML, but I wondered if this might be legal or
> advisable,
>
> Instead of:
>
>
> 24.5
> -49.0
>
>
> we could use:
>
>
Right now, I use attributes for meta-inf
David Findlay writes:
> Anyone getting this error with latest cvs of everything?
Yes, you're getting it because you're using the CVS plib (like many of
us). I #ifdef'd sgdPointInTriangle out locally in my hitlist.cxx, but
we need someone who knows plib better to add a general solution. This
i
Tony Peden writes:
> To get the equivalent of tieing to object methods, a once-per-frame data
> copy is necessary. Did your testing take this into account?
No, I was just testing access time. I checked in some optimizations
that skip a lot of unnecessary code when the value is held internal
In message <[EMAIL PROTECTED]>,
Greg Long <[EMAIL PROTECTED]> writes:
> OK, NOW we're talking - do you have any of that more precise data you could
> avail derived from the PEDR files? (Did you generate your own EGDR?) the
> 1/64 EGDR data is 506mb as I recall - yours would be close to 2
Andy Ross writes:
>
>Are those huge advantages? Nope. But is assert.h a much better
>choice? Nope again. No one got hurt by this thing; I got yelled at
>only because people thought it was ugly. Aesthetics alone do not a
>good design make.
>
Not quite true :-(
I wasted several DAYS spread o
> > I'm not familiar with our XML parser, but could we get away with using
> > this instead?:
> >
> >
>
> In other words, you'd like
>
>
I've had some thoughts along those lines, too. Note that I am not so
familiar with proper XML, but I wondered if this might be legal or
advisable,
In
Jon Berndt writes:
> > I had been concerned
> > that SGPropertyNode::getDoubleValue was showing up at the top of the
> > profiling output for JSBSim, but I think that that was masking the
> > object methods it was invoking in other JSBSim code.
>
> Could very well be.
>
> > properties, b
On Mon, 2002-03-18 at 04:32, David Megginson wrote:
> Andy Ross writes:
>
> > It's probably not a quirk. Inlining actually helps very little except
> > for VERY small functions. It used to be that a function call was slow
> > -- you had to spill a bunch of registers and a return value onto t
Cameron Moore writes:
> I'm not familiar with our XML parser, but could we get away with using
> this instead?:
>
>
In other words, you'd like
to be the equivalent of
true
or
1
I'm not sure if that's a good idea -- I'd be more inclined to default
to 0/false/empty-string. Wh
Andy Ross writes:
> It's probably not a quirk. Inlining actually helps very little except
> for VERY small functions. It used to be that a function call was slow
> -- you had to spill a bunch of registers and a return value onto the
> stack, and then clean them up later. But modern process
* David Findlay -- Monday 18 March 2002 12:50:
> hitlist.cxx: In function `bool sgdPointInTriangle(double *, double (*)[3])':
> hitlist.cxx:58: `sgdPointInTriangle(double *, double (*)[3])' was declared
> `extern' and later `static'
> /usr/include/plib/sg.h:2554: previous declaration of
> `sgdPoin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Anyone getting this error with latest cvs of everything?
make[2]: Entering directory `/home/david/flightgear/FlightGear/src/Scenery'
c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
- -I/usr/local/include -I/usr/X11R6/include -g
On Sun, 2002-03-17 at 19:05, David Megginson wrote:
> I've been running some experiments on the property manager today,
> retrieving different kinds of double properties in a tight loop and
> timing the results (the worst case was 6.2 seconds for 100M accesses
> of a property tied to object method
OK, NOW we're talking - do you have any of that more precise data you could
avail derived from the PEDR files? (Did you generate your own EGDR?) the
1/64 EGDR data is 506mb as I recall - yours would be close to 2gb.
I was in the proccess of downloading the PEDR's - and actually am about
halfway
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
this can speed up rendering process but if we use vertex arrays it
On Sun, Mar 17, 2002 at 10:06:46PM -0800, Andy Ross wrote:
> David Megginson wrote:
> > The biggest surprise was that inlining methods made things slower, not
> > faster, in most cases (there were a couple of exceptions). That may
> > be a quirk of G++'s code generation, but it's probably worth
>
It might also be worth saying that our terrain data was produced from
the raw PEDR tab file data (A 14gig download I think) and interpolated
to 30 arc seconds (i.e. about 1/120 degree), jeez that took a while
(just the terragear stage took 4 days on a 20 processor Sparc enterprise
and 30 Sparc 5
Greg,
Been there, done that...bit of a nightmare journey though. (See the pics
on the related projects web page (University of Wales, Aberystwyth).
As for the constants/changes, most of them are in SimGear... from off
the top of my head the following should be enough to get correctly sized
scen
51 matches
Mail list logo
