Dear all,
I am trying to follow JSBSIM flow with GDB using cygwin (under cygwin
you get some kind of an Insight debugger). What I do not understand is
why the debugger keeps jumping to the file bastring.h on lines 190 and
147 when I press Next (There is no breakpoint on this line and I
definitely
Jim Wilson writes:
>
>So far (on my system 750mhz (100 Bus) and voodoo3)
>the frame rate seems to be about the same as it was before
>these changes.
FWIW
A Voodoo3 is so 'fill bound' that I doubt if anything not putting
pixels on the screen would would have 'much' affect on your
frame rate. T
Currently I'm testing a new scheme for caching tiles. See the changes listed
below for details on how it is different. The goal is to stabilize the new
viewer code's interaction with the flightgear scenery code.
As many have observed there are numerous problems that have come up since
incorpora
Ooops!
This just happen if you copy FlightGear\src\include\config.h.msvc6 to
config.h
- Original Message -
From: "Marcio Shimoda" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 02, 2002 7:37 PM
Subject: Reset Problem part 2
> Hey, the problem of the 2nd reset is back!
>
Alex Perry <[EMAIL PROTECTED]> said:
> > > fgfs --wind=270@15 --prop:/environment/params/gust-wind-speed-kt=25
>
> I can't try it right now; the 3D panel is broken for me and the 2D view
> environment sets the clip planes to be unusable for 16 bit depth buffering
> when I get close to ground e
> > fgfs --wind=270@15 --prop:/environment/params/gust-wind-speed-kt=25
I can't try it right now; the 3D panel is broken for me and the 2D view
environment sets the clip planes to be unusable for 16 bit depth buffering
when I get close to ground effect. Disconcerting ... I'll try later again.
David Megginson <[EMAIL PROTECTED]> said:
> The gust function is simplistic, but at least it is unpredictable, and
> I find that it messes up my landings just like to real thing. To get
> winds from 270 @ 15kt gusting to 25kt, try
>
> fgfs --wind=270@15 --prop:/environment/params/gust-wind-sp
> In real life, I've been having a hard time with my landings on the
> circuit ('suck' might be the most appropriate term).
Minor suggestions ...
(1) Ask to have a night lesson. The air will be a lot smoother and
you can practice things like roundout and ground effect operations.
(2) Wait a
In real life, I've been having a hard time with my landings on the
circuit ('suck' might be the most appropriate term).
Practicing with FlightGear has helped a bit, but it didn't really feel
right. When I'm landing a real C172, there are almost always wind
gusts, turbulence, and other nasty thin
[EMAIL PROTECTED] writes:
>
>I've tried both and I've got the same error.
>
>Has anyone been able to compile the latest version on
>win32/cygwin platform ?
YES
My guess is that you do not have the Cygwin OpenGL link libraries
installed. Try reruning the Cygwin setup program and make sure
that
I've tried both and I've got the same error.
Has anyone been able to compile the latest version on win32/cygwin platform ?
Francisco
-Original Message-
From: Julian Foad [mailto:[EMAIL PROTECTED]]
Sent: Monday, May 06, 2002 2:28 PM
To: [EMAIL PROTECTED]
Subject: Re: [Flightgear-devel]
It seems to be caused by a recent change in CygWin. Here is Norman's answer to the
same question:
Norman Vine wrote (on Tue, 23 Apr 2002):
>
> The opengl libs got moved to
>
> / lib / w32api / directory
>
> don't ask me why ?
>
> I just made a link to these in my '/ lib' dirrectory
>
> y
Marcio:
I've been trying to compile the latest version, but I've encountered some
problems linking against the opengl library.
I'm trying to compile it in windows XP and using:
gcc version 2.95.3-5.
Opengl 1.1.0-6
SimGear 0.0.18
Plib-1.4.2
No problems compiling simgear and plib.
Ha
At 09:47 PM 5/4/2002 -0500, you wrote:
> http://www.cs.unc.edu/~harrism/SkyWorks/
>
>If any of our developers out there are looking for their next project
>to work on, this could be a really interesting one to look at. This
>will probably be a fairly good sized chunk to bite off, but if we c
Simon,
I haven't noticed any performance degradation (similar to what you
describe) on nVidia hardware.
It sounds like maybe the radeon driver does ok drawing alpha quads (or
quads with an alpha component) from back to front, but perhaps there
is an inefficiency in the pipeline when the alpha qu
Erik Hofman writes:
> Particles (in OpenGL) are a large number of polygons which have the
> same characteristics. By updating the particles in one shot you
> should be able to get the best perfomance out of the hardware.
Do you mean that all of the billboarded trees would be under the same
tr
David Megginson wrote:
> Erik Hofman writes:
>
> > > Norm: which do you think would be more efficient for a forest of, say,
> > > 500 trees?
> >
> > I would say, billboarded spherical trees handled as particles.
>
> I don't understand 'particles'.
Particles (in OpenGL) are a large number o
17 matches
Mail list logo