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) instruments,
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
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.
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 serious enough
to
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 when I
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 much
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
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.
Right ---
So
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
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
rendering the
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
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 fixes it
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
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 to
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
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
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
-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 was too
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
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
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%
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
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)
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
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 =
25 matches
Mail list logo
