Hello Everyone.
I've recently gone full time linux running Mandrake 8.2, I've been
running linux since 0.91 but not as a full time desktop machine :-). I
don't have all the answers, but I generally can find them :-) and
sometimes I can also be dense :-). Been programming since the IBM 1401
:-
Jim
This is a fairly old one - the file date is 26 Feb this year. I think it was
compiled on RH7.2 before I upgraded the box to RH7.3. It still works for me.
Darren
On Wednesday 10 Jul 2002 5:03 am, Jim Wilson wrote:
> Got my new machine pretty much the way I want it...but rebuilding atlas
On Tue, Jul 09, 2002 at 10:47:42PM -0400, William Earnest wrote:
> Hi all,
>
> For the past couple of weeks I have been unable to get a clean
> compile of plib, although SimGear and FlightGear have given no trouble. I
> get a series of nearly identical errors from ssg such as this:
I also rebuilt for my other two platforms, and here are the results:
OS = Red Hat 7.3
CPU = Athlon 1.2 GHz
GFX = GeForce 2Ti
Default location went from 32 FPS to 38 FPS = 19%
Default orientation
OS = Mac OS X 10.1.5
CPU = G4 867 MHz
GFX = GeForce 3
Default location went from 12 FPS to 34 FPS = 1
Got my new machine pretty much the way I want it...but rebuilding atlas is one
of those little things that are left. It looks like there's some issues with
Atlas and simgear that haven't been fixed in CVS yet (well as far as I've
looked). Anyone have a working "Atlas" binary that will probably
OS = Linux 2.4.18
CPU = P3-500
GFX = GF2 GTS 32MB
VER = CVS from yesterday
Default startup went from 13 fps to 16 fps = +23%
I should note that I compiled everything with no optimizations and no
in-lines since I've been using valgrind a lot lately.
* [EMAIL PROTECTED] (Norman Vine) [2002.07.0
I've been doing really well recently with my A-4 landings, so I wrote
up a putative "Flight Operations Manual" to record the stuff I've
learned:
http://www.plausible.org/a4-ops/
Obviously, I've never actually trained with the Navy, so lots of this
is guesswork based on data points I've picked
One more thing, the command line is configured as:
--fdm=ufo --disable-clouds --disable-panel --visibility-miles=50
On Tuesday, July 9, 2002, at 10:00 PM, Jonathan Polley wrote:
> OS = Windows ME
> CPU = Athlon 1.2 GHz
> GFX = GeForce 2Ti
> Default location went from 67 FPS to 74 FPS = 10%
> De
OS = Windows ME
CPU = Athlon 1.2 GHz
GFX = GeForce 2Ti
Default location went from 67 FPS to 74 FPS = 10%
Default orientation
I also did some testing around both Seattle and Denver, mainly for the
complex terrain, and saw the following:
KSEA went from 18 FPS to 27 FPS = 50% improvement
KDEN went
Hi all,
For the past couple of weeks I have been unable to get a clean compile of
plib, although SimGear and FlightGear have given no trouble. I get a
series of nearly identical errors from ssg such as this:
ssgLoadBGL.cxx:2103: no matching function for call to
`ssgVtxArray::ssgVtxArra
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED]]On Behalf Of Paul Deppe
>Sent: Tuesday, July 09, 2002 4:31 PM
>To: FGFS-Devel
>Subject: RE: [Flightgear-devel] GS needle sensitivity.
>
>
>> I had someone recently comment that they thought the glide slope
>> needle wa
Hi All
I got a considerable boost in the frame rate from the following
patch to PLib. < ~25% at default startup location >
I am trying to determine if this also true for 'most' systems
before advocating it's inclusion into PLib
If you do test this please report back with your results
and system
> The localizer beam width is designed to produce +/- 2 dots deviation at +/-
> 700 feet deviation from centerline at the runway threshold. The localizer
> scale sensitivity in degrees per dot is therefore a function of the distance
> from the threshold to the localizer antenna.
I agree with the
Curt, what is your position on the remaining SourceForge facilities? In particular I
am thinking of the bug tracker, and the project info page
"http://sourceforge.net/projects/flightgear/";. Personally I hardly ever look at it
because I have what I need and know nothing is there, but I would
The SourceForge Bug Tracker has the following outstanding bug reports:
ID SummaryDate Assigned To
Submitted By
433286 Sun lights plane at night. 2001-06-14 17:33 nobody
dmegginson (still a bug)
433288 Swit
Paul Deppe writes:
> Glideslope beams are designed to be 1.4 degrees "tall", that is, +/- 2 dots
> (full scale) deviation on the gauge is equal to +/- 0.7 degrees glidesope
> deviation, or 0.35 degrees per dot. This is the same for all standard
> ILS's.
>
> The localizer beam width is designed t
Paul Deppe writes:
> Glideslope beams are designed to be 1.4 degrees "tall", that is, +/- 2 dots
> (full scale) deviation on the gauge is equal to +/- 0.7 degrees glidesope
> deviation, or 0.35 degrees per dot. This is the same for all standard
> ILS's.
That makes an awful lot of sense. On
> I had someone recently comment that they thought the glide slope
> needle was too sensitive in FG. Can anyone comment on this? What
> sort of needle range relative to how many degrees off the target glide
> slope should we be seeing? This person suggested 2 'dots' per degree
> off the glide s
Curtis L. Olson wrote:
> I had someone recently comment that they thought the glide slope
> needle was too sensitive in FG. Can anyone comment on this?
I think the glideslope needle is too sensitive in FG. :)
I don't have any harder evidence either, but I'll throw in my 2ยข
anyway. I've been pr
Andy Ross <[EMAIL PROTECTED]> writes:
> What size depth buffer are you using? The default is to use the same
> depth as the color bits, so if you're in 16 bit color mode, you're
> probably using a shallow depth buffer. You could try a depth of 24 in
> your XF86Config-4 file, and see if that fix
I had someone recently comment that they thought the glide slope
needle was too sensitive in FG. Can anyone comment on this? What
sort of needle range relative to how many degrees off the target glide
slope should we be seeing? This person suggested 2 'dots' per degree
off the glide slope (but
Alex Romosan wrote:
> just took a look at the outside view with the cessna and i noticed you
> can see the instrument panel through the fuselage. this is on linux
> with a geforce card. picture at:
What size depth buffer are you using? The default is to use the same
depth as the color bits, so i
Jim Wilson writes:
>
>Norman Vine <[EMAIL PROTECTED]> said:
>
>> Andy Ross writes:
>> >
>> > Just adding an offset to the camera is what's already being
>> >done, and it runs into precision problems. The trick is to make sure
>> >that the camera is *never* moved to the scenery centroid before
>>
just took a look at the outside view with the cessna and i noticed you
can see the instrument panel through the fuselage. this is on linux
with a geforce card. picture at:
http://caliban.lbl.gov/fgfs_panel.ppm
also, the engine is at 0 rpm but the propeller is spinning in the
animation. all this
Norman Vine <[EMAIL PROTECTED]> said:
> Andy Ross writes:
> >
> > Just adding an offset to the camera is what's already being
> >done, and it runs into precision problems. The trick is to make sure
> >that the camera is *never* moved to the scenery centroid before
> >rendering the model.
>
>
Andy Ross writes:
> Is this on the 3D panel or 2D? In 3D, the texture layers are drawn
> with GL_POLYGON_OFFSET, which by default does not apply to lines. For
> reasons having to do with a metaphor collision (lines are "thick" in
> screenspace, while polygons aren't) lines don't work well with
>
Andy Ross writes:
> I honestly thought it was a joke, but the website looks serious
> enough to believe. Good grief.
People have been proposing this kind of thing right from the start.
> But it's not the first -- XSLT is a full XML-based programming
> language, thankfully tailored to a muc
Martin Dressler wrote:
> I wan to draw lines in instruments layer. I made a new subclass of
> FGInstrumentLayer and in draw method I do
> glDisable ( GL_TEXTURE_2D );
> glBegin(GL_LINES);
> glVertex2f(-100,0);
> glVertex2f(100,0);
> glEnd();
>
> but it doesn't draw anything. But
Andy Ross writes:
> Jonathan Polley wrote:
> > Jon Berndt wrote:
> > > Just because something *can* be done doesn't mean it *should* be!
> >
> > Actually, I was going to say that it was another solution in search of
> > a problem.
>
> I honestly thought it was a joke, but the website looks seriou
Jonathan Polley wrote:
> Jon Berndt wrote:
> > Just because something *can* be done doesn't mean it *should* be!
>
> Actually, I was going to say that it was another solution in search of
> a problem.
I honestly thought it was a joke, but the website looks serious enough
to believe. Good grief.
I need some help.
I wan to draw lines in instruments layer. I made a new subclass of
FGInstrumentLayer and in draw method I do
glDisable ( GL_TEXTURE_2D );
glBegin(GL_LINES);
glVertex2f(-100,0);
glVertex2f(100,0);
glEnd();
but it doesn't draw anything. But when I draw someth
David Megginson wrote:
>
> /instrumentation/altimeter/
> /instrumentation/airspeed-indicator/
> /instrumentation/vor-gauge/
> /instrumentation/transponder/
>
> etc., with indexes as appropriate. Inside each branch, we have a
> collection of properties, some common to many (or all) instr
32 matches
Mail list logo
