Re: [Flightgear-devel] runway lights
Thanx Ranga for your detailed reply using your ksfo airport I use lp tokens and turn on runway lights now i got shemes on position our russian runway lights and try to place runway lights according scheme "Ray" or "Lutch" in russian transcription as i understand rway_dir variable shows us landing direction on runway it's normalize vector rway_normal it's normal to runway or what? normal to point light? or raycasting direction in tileentry.cxx there is a code //EDGE setColor(0.0,0.0,-1.0,180.0, 1, 1, 0.5, 1); why 180 and not 360? and on vasi //VASI lights setColor(0.0,0.0,1.0,360.0, 0, 0, 0, 0); setColor2(10.0, 40.0, 1, 1, 1, 1); setColor2(6.0, 40.0, 1, 0.5, 0.5, 1); setColor2(5.0, 40.0, 1, 0, 0, 1); why here 360 and 10, 40, 6, 5 I understand Ranga that maybe you not use this code but maybe someone (Christian?) explain me this magic numbers Also I complied flightgear to see lights usung MSVC but when I use cygwin I got nothing cygwin's glut does not support opengl extensions : As I understand now you are working on Mandrake and use Nvidia linux drivers that support extensions when i compiled on linux should I simply rename wgl to xgl and all works fine? Your comments? Thanx Bye ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems with JSBSim under Win32
> > I did not find out why the QNAN ... maybe I should just do a cvs update, > > and try JSBSim again. As mentioned YASim works fine ... well, with my > > usual 'stuttering' win98 run (< 1 fps) ... > > Geoff: > > Can you step back for a minute and answer these questions: > > 1) How are you building flightgear and which version of all are you using? > JSBSim from JSBSim CVS? > > 2) Does this "problem" with JSBSim as the FDM with all JSBSIm aircraft, or > just one? > > 3) What is the command line you use when starting FlightGear and see the > ensuing crash (QNAN)? > > This is a bit perplexing, first of all because I haven't seen a thorough > explanation of what happens, and because I am not familiar with MSVC, and > also because I have seen JSBSim (standalone) work with Borland, g++ under > Irix and Linux, and have not seen this problem. I have seen some abnormal > behaviour with MSVC, however, so you can see where my suspicion lies. We > (JSBSim) use the full range of C++ and STL facilities and so with the > multiple compilers and OSes we operate under we have to be careful. The kind > of issue you briefly described leaves me to suspect the compiler. > > Jon Jon, I think that I explained a cause of this problem in my last mail (mail subject has been "QNAN on FG/JSBsim/win32 startup" or similar - I haven't it on this computer now ). Problem has been described more times by more people. Shortly, a case is a fail of "FGInitConditions" for a stationary airplane, please look to that mail. It is not a MSVS - related think. Other compilers products probably has a different behavior in case of floating point exception situation. Please, could you look if a cause that I described occur on your platform? Richard Kis ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lights
On Thursday 17 January 2002 13:35, you wrote: > using your ksfo airport I use lp tokens and turn on runway lights > now i got shemes on position our russian runway lights and try to place > runway lights according scheme "Ray" or "Lutch" in russian transcription runway x y z - define runway direction. > as i understand rway_dir variable shows us landing direction on runway it's > normalize vector Yes > rway_normal it's normal to runway or what? normal to point light? or > raycasting direction It is direction of the light. (yes, raycasting dirn.). for allround lights it becomes the runway normal. for red/green threshold lights its the runway direction. for vasi it is again the runway direction (red/white elliptical beams centered about the runway direction vector emanating from the light.) The setclor() and setcolor2() functions produce texture maps about these directions. > in tileentry.cxx there is a code > //EDGE > setColor(0.0,0.0,-1.0,180.0, 1, 1, 0.5, 1); > why 180 and not 360? > and on vasi > //VASI lights > setColor(0.0,0.0,1.0,360.0, 0, 0, 0, 0); > setColor2(10.0, 40.0, 1, 1, 1, 1); > setColor2(6.0, 40.0, 1, 0.5, 0.5, 1); > setColor2(5.0, 40.0, 1, 0, 0, 1); > why here 360 > and 10, 40, 6, 5 Sorry, I never bothered to troubleshoot this, because it was not worth the effort as long as it works. setcolor2 divides angles by 2, I discovered. So this hack. 10 gives 5 degrees in elevation (2.5 up and 2.5 down about the horizontal) and 40 gives total 20 degrees arc in azimuth. So you see red from 0 to 2.5 degrees and white when glideslope greater than 2.5 degrees wrt to the vasi lightpoint. > Also I complied flightgear to see lights usung MSVC but when I use cygwin I > got nothing cygwin's glut does not support opengl extensions : > As I understand now you are working on Mandrake and use Nvidia linux > drivers that support extensions > when i compiled on linux should I simply rename wgl to xgl and all works > fine? Your comments? No I use the gl-extensions only on Win2k machines, not on linux. You tell me how to make it work with Linux. To begin with gl.h from nvidia distribution does not seem to support the point parameter extension, which is supported on win2k with the help of glext.h. Regards Ranga _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lights
- Original Message - From: "VS Renganathan" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, January 17, 2002 11:45 AM Subject: Re: [Flightgear-devel] runway lights > On Thursday 17 January 2002 13:35, you wrote: > > using your ksfo airport I use lp tokens and turn on runway lights > > now i got shemes on position our russian runway lights and try to place > > runway lights according scheme "Ray" or "Lutch" in russian transcription > > runway x y z - define runway direction. > > > as i understand rway_dir variable shows us landing direction on runway it's > > normalize vector > > Yes > > > rway_normal it's normal to runway or what? normal to point light? or > > raycasting direction > It is direction of the light. (yes, raycasting dirn.). for allround lights it > becomes the runway normal. for red/green threshold lights its the runway > direction. for vasi it is again the runway direction (red/white elliptical > beams centered about the runway direction vector emanating from the light.) > The setclor() and setcolor2() functions produce texture maps about these > directions. > > > in tileentry.cxx there is a code > > //EDGE > > setColor(0.0,0.0,-1.0,180.0, 1, 1, 0.5, 1); > > why 180 and not 360? > > and on vasi > > //VASI lights > > setColor(0.0,0.0,1.0,360.0, 0, 0, 0, 0); > > setColor2(10.0, 40.0, 1, 1, 1, 1); > > setColor2(6.0, 40.0, 1, 0.5, 0.5, 1); > > setColor2(5.0, 40.0, 1, 0, 0, 1); > > why here 360 > > and 10, 40, 6, 5 > > Sorry, I never bothered to troubleshoot this, because it was not worth the > effort as long as it works. setcolor2 divides angles by 2, I discovered. So > this hack. 10 gives 5 degrees in elevation (2.5 up and 2.5 down about the > horizontal) and 40 gives total 20 degrees arc in azimuth. So you see red from > 0 to 2.5 degrees and white when glideslope greater than 2.5 degrees wrt to > the vasi lightpoint. > > > Also I complied flightgear to see lights usung MSVC but when I use cygwin I > > got nothing cygwin's glut does not support opengl extensions : > > As I understand now you are working on Mandrake and use Nvidia linux > > drivers that support extensions > > when i compiled on linux should I simply rename wgl to xgl and all works > > fine? Your comments? > > No I use the gl-extensions only on Win2k machines, not on linux. You tell me > how to make it work with Linux. To begin with gl.h from nvidia distribution > does not seem to support the point parameter extension, which is supported on > win2k with the help of glext.h. > ok I try to make it another problem is to calculate positions of runway lights I think I sould write a small program to calculat light position based on ranway corner points. All I need is know 3 corner points and landing direction So I try to make it Also I propose use RWY_LIGHTS token in tile description to load runway lights. If no any objections I try to make it. Also i think that calculating position of each light in real time is hardly expensive so needa make offline tool to calculate positions. if someone works in this area please contact me. Thanx Bye > Regards > Ranga > > > > _ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lights
>>Also I complied flightgear to see lights usung MSVC but when I use cygwin I
>>got nothing cygwin's glut does not support opengl extensions :
>>As I understand now you are working on Mandrake and use Nvidia linux
>>drivers that support extensions
>>when i compiled on linux should I simply rename wgl to xgl and all works
>>fine? Your comments?
>No I use the gl-extensions only on Win2k machines, not on linux. You tell me
>how to make it work with Linux. To begin with gl.h from nvidia distribution
>does not seem to support the point parameter extension, which is supported
>on win2k with the help of glext.h.
further to my earlier mail on this thread
gl.h on linux/nvidia machines does seem to have the GL_EXT_point_parameters
functions, but how do you obtain the entry address to these functions in the
api library. I mean what is the equivalent of wglGetProcAddress("xxx").
Regards
Ranga
_
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] runway lights
- Original Message -
From: "VS Renganathan" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, January 17, 2002 12:25 PM
Subject: Re: [Flightgear-devel] runway lights
>
>
> >> Also I complied flightgear to see lights usung MSVC but when I use
cygwin I
> >> got nothing cygwin's glut does not support opengl extensions :
> >> As I understand now you are working on Mandrake and use Nvidia linux
> >> drivers that support extensions
> >> when i compiled on linux should I simply rename wgl to xgl and all
works
> >> fine? Your comments?
>
>
> >No I use the gl-extensions only on Win2k machines, not on linux. You tell
me
> >how to make it work with Linux. To begin with gl.h from nvidia
distribution
> >does not seem to support the point parameter extension, which is
supported
> >on win2k with the help of glext.h.
>
> further to my earlier mail on this thread
>
> gl.h on linux/nvidia machines does seem to have the
GL_EXT_point_parameters
> functions, but how do you obtain the entry address to these functions in
the
> api library. I mean what is the equivalent of wglGetProcAddress("xxx").
use glXGetProcAdress
with same parameters
to get working gl exetnsions you should install nvidia drivers and nvidia
glx
so you got glext.h and libopengl with supported extensions
also you sould have glut 3.7 that support extensions
>
> Regards
> Ranga
>
> _
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
>
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] version of cygwin glut
Hi ALL! how to know version of glut in cygwin? or any versions of packages in cygwin Thanx Bye ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with JSBSim under Win32 - MSVC
> 1) How are you building flightgear and which version of all are you
using?
> JSBSim from JSBSim CVS?
Using FlightGear.dsw/dsp (msvc6) - daily cvs updates from repository
:pserver:[EMAIL PROTECTED]:/var/cvs/FlightGear-0.7
That is 0.7.9 ...
I also do daily cvs updates from the repoisitory
:pserver:[EMAIL PROTECTED]:/cvsroot/jsbsim
as this often gives me a heads-up on changes I can expect
in fg shortly ...
So I decided to compare the two -
That is %HOME%\JSBSim, and %HOME%\FlightGear\src\fdm\jsbsim.
Of the 230 files in the left, 115 are only in the left, and
of the 118 files in the right, 3 are only in the right.
Of the 115 that exist in BOTH repositories, most are exactly the same
except for the file date stamp - sometimes many days different - and the
size is
a few bytes different caused by who checked it in, like say
// Compare [%HOME%\jsbsim\FGAerodynamics.h]
// Size: 5,527 15/01/02 10:46
// With[%HOME%\FlightGear\src\fdm\jsbsim\FGAerodynamics.h]
// Size: 5,525 17/12/01 17:39
// Time: Left is newer - Update?
=
67 #define ID_AERODYNAMICS "$Id: FGAerodynamics.h,v 1.24 2001/12/17
14:36:21 david Exp $"
=
87 @version $Id: FGAerodynamics.h,v 1.24 2001/12/17 14:36:21
david Exp $
In only ONE(1) file did I find a code change. And that was in -
// Compare [d:\fg78cvs\jsbsim\FGConfigFile.cpp]
// Size: 12,139 15/01/02 10:46
// With[d:\fg78cvs\FlightGear\src\fdm\jsbsim\FGConfigFile.cpp]
// Size: 12,027 25/12/01 09:01
// Time: Left is newer - Update?
=
24 static const char *IdSrc = "$Id: FGConfigFile.cpp,v 1.24
2001/12/24 12:54:55 david Exp $";
=
... etc
But I would expect this update to eventually 'migrate' to the fg
repository, no?
> 2) Does this "problem" with JSBSim as the FDM with all JSBSIm aircraft,
or
> just one?
Have never tried the other aircraft, but will try that and advise ...
> 3) What is the command line you use when starting FlightGear and see the
> ensuing crash (QNAN)?
Usually none. My FG_ROOT is set during os boot, presently
d:\fg79\fgfsbase.
I switch to the YASim fdm through my system.fgfsrc file in the base.
> This is a bit perplexing, ...
I agree with that ...
> not familiar with MSVC
For my WIN32 machine the compiler must write Intel code using COFF -
common object file format. The linker joins the some 700 odd objects
(COFF's) that comprise FlightGear.exe and writes a simple WIN32
(CONSOLE) executable.
One 'difference' repeated many many time here is how memory is
initialised.
The debug version of the MS compiler uses allocated memory set to
something like cdcdcdcdcdcdcdcdcdcdcd. And to check stack overflow,
fills ALL stack variables with cc.
Of course if you write foo{ int i = 0 } then after the above stack fill
there
will be specific code like
movdword ptr [ebp-4] , 0; set i = 0
In fact just so you fully understand in intel code this is
00412360 55 pushebp
00412361 8B ECmov ebp,esp
00412363 83 EC 60 sub esp,60h ; total of all stack locals
00412366 53 pushebx
00412367 56 pushesi
00412368 57 pushedi
00412369 8D 7D A0 lea edi,[ebp-60h]
0041236C B9 18 00 00 00 mov ecx,18h
00412371 B8 CC CC CC CC mov eax,0h
00412376 F3 AB rep stosdword ptr [edi] ; stuff eax, incing edi
706: int i = 0;
00412378 C7 45 FC 00 00 00 00 mov dword ptr [ebp-4],0
And concerning allocation, if you write something like -
class foo {
int iSpeed;
}
void main()
{
foo * pf = new foo;
...
Now iSpeed will contain the value cdcdcdcd, since it is made of allocated
memory.
> Borland, g++ under Irix and Linux, ...
These compilers may not have these debug 'features' ... Although I
have not specifically checked I think the release version of
the MS compiler/linker will not set the stack at all, except for
the i=0 case, and allocated memory is zero init'ed.
> of issue you briefly described leaves me to suspect the compiler.
So yes and no. It may or may not be the compiler, or a 'feature'
of the compiler ... Then again ...
I must say that in general I have found your fdm code to
always have a class instantiate and destroy functions. One time
I even set debug_lvl = 3, and looked through the massive debug
output that results ... That is your code would have a
foo::foo()
{
iSpeed = 0;
htab[7]=259186.352; //ft.
}
so I can not see that either of the above 'debug' features should
harm your code.
And this snippet of the log shows that you have already done
some 'correct' calculation before we get to the QNAN case -
...
Panel visible = 1
Loading deferred texture
Finally initializing fdm
Starting and initializing JSBsim
Start common FDM init
...initializing position...
F
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Julian Foad writes: > The first thing globals->saveInitialState() does is "delete > initial_state;" but initial_state was initialised to 0 (i.e. a null > pointer) in the constructor. Is "delete p;" a synonym for "if (p) > delete p;" according to your compiler's manual? Is it according to > the current version of the C++ standard? There are many, many places in FlightGear and SimGear where we delete a pointer without checking for 0 first -- that's been standard C++ for a long time (i.e. well before ANSI C++). I don't think even MSVC has a problem with it. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] altitude hold problem
Jon S. Berndt writes: > > From: Andy Ross > > > In fact, this is a good example: a "real" F-16A (Dunno about the C) > > flight control computer takes its input from a set of gyros and from > > the position of the stick, and that's it > > The F-16 DFCS (beginning with Block 40) - and I suspect to some degree also > the F-16A model - also requires the inputs of a rather lot of switch > positions (commonly referred to as "notes"), e.g. pitch switch position, > absolute value of phi greater than some value, WOW, roll switch position, > standby gains enabled, control stick steering force greater than some value, > other notes, etc. These are very aircraft specific. So, as you state below, > yes the FCS needs to know some very specific aircraft information. That's actually a counter-example: this is all information that FlightGear will have to have by default, but FDMs like JSBSim will not (necessarily) -- since FlightGear owns the panel and the UI, it is the component that tracks the position of every switch, stick, and so on. > 1) The FCS is already being modeled. We want to do it. We like > doing it. I think that's harmless enough, but we might also want to consider adding an option to use an external FCS. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems with JSBSim under Win32 - MSVC
> And this snippet of the log shows that you have already done > some 'correct' calculation before we get to the QNAN case - > ... > Panel visible = 1 > Loading deferred texture > Finally initializing fdm > Starting and initializing JSBsim > Start common FDM init > ...initializing position... > FGJSBsim::set_Longitude: -2.13554 > FGJSBsim::set_Latitude: 0.65648 > cur alt (ft) = 0 > FGJSBsim::set_Altitude: 0.367205 > lat (deg) = 37.6135 > ...initializing ground elevation to 0.367205ft... > common_init(): set ground elevation 0.367205 > FGJSBsim::set_Runway_altitude: 0.367205 > ...initializing sea-level radius... > lat = 37.6135 alt = 0.367205 > FGJSBsim::set_Sea_level_radius: 2.08997e+007 > ...initializing velocities... > FGJSBsim::set_V_calibrated_kts: 0 > ...initializing Euler angles... > FGJSBsim::set_Euler_Angles: 0, 0.0074002, 5.19934 > End common FDM init > > Touchdown report for NOSE > ...etc > > This looks picture perfect, doesn't it? Yes, it Is OK, it is position and velocities part of JSB initialization, the problems coming soon in the next: > Why after a few more "Touchdown reports ... " I > get ... > > fgGeodToGeoc(): Domain error > sqrt(1.#QNAN) > Initialized JSBSim with: > Indicated Airspeed: 0 knots > Bank Angle: -1.#IND deg > Pitch Angle: 1.#QNAN deg > True Heading: -1.#IND deg > Latitude: 1.#QNAN deg > Longitude: 1.#QNAN deg > Altitude: -1.#IND feet > loaded initial conditions > set dt > Finished initializing JSBSim > FGControls::get_gear_down()= 1 > FGJSBsim::set_Euler_Angles: 0, 1.#QNAN, -1.#IND > FGJSBsim::set_Euler_Angles: -1.#IND, 0.0074002, -1.#IND > FGJSBsim::set_Euler_Angles: -1.#IND, 1.#QNAN, 5.19934 Here problems starting - it is an euler angles JSBsim initialization part: FGJSBsim::set_Euler_Angles() FGInitialCondition::SetPitchAngleRadIC(theta) FGInitialCondition::getAlpha(void) FGInitialCondition::solve(&alpha,0) FGInitialCondition::GammaEqOfAlpha() GammaEqOfAlpha here returning 0.0 (because all velocity components are 0.0) Both f1 and f3 FGInitialCondition::solve() locals gets 0.0 therefore and there is division by zero on line: x2 = x1-d*d0*f1/(f3-f1). We made a "patches" for avoiding of that, but problem is that GammaEqOfAlpha() returns 0.0 for true air velocities == 0.0 Richard Kis ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
> Geoff McLane wrote: > > YASim, and it all went well ... I had a 'reasonable' flight, > > 'stuttering' along, but some moments when it came together ... > Andy asked: > YASim shouldn't be stuttering, certainly. Which aircraft were you > using? What were the symptoms? I was using the c172-yasim, and more recently c310-yasim ... but 'stuttering' here means that the exe (flightgear) here in my pc system has more disk io work to do than there is real time ... So while 'real' time marches forward, my next visual update might show me ten's of metres down the runway, and the speed past v1. Unfortunatel my js input is not read for several more seconds, after more disk io, and just one video io, then I am in the air with a left roll, but more disk io prevents the right js input to be read until ... Sometimes, after accidently establishing a relatively smooth climb, and outside is mostly sky, while there is still continuous disk io the video update re-acts gentle and immediately to a small js l input ... the model is humming ... i mean flying ... :- bliss ... This begins at a modest fps of abt 5 and can be sustained, sometimes for many real time seconds, until perhaps we have climbed or moved such that another pieces of scenery must be located and loaded ... into the big-io-chache already kept ... An idea I have is for the model to have a mode to not to calculate the next 'position', 'height', lat, lon, etc in relation to system clock time, but from time kept only by cycles through fgMainLoop, thus includes sound and video updates (// redraw display = fgRenderFrame(); ). I will call this m_time. So if fgMainLoop fps is greater than say 5, then model time (m_time) would march forward exactly per system clock time (+warp). But when the fps falls below this then model time (m_time) slows up ... m_time could be kept in say 100 ns units, or usecs, or ... The current speed and heading times m_time would be less than real. That means engine thrust times m_time would be less, thus accellerating the aircraft less ... The left roll vector I mentioned above is only applied for this smaller amount of m_time so the model will have a chance to 'see' my small js correction ... Of course this should be an on/off switch. Such 'slowing' of real time is like have a less than 1 rate in MSFS, and is only used to show how software can co-operate with the pc system around it and produce smooth model animation, albiet at the cost of running 'slow' ... I originally thought porting threads to WIN32 might help, but I now think 'not really'. I have tried say running the 'sound'.update() on a separate thread, but unless I elevate its priority it will simply not receive enough cpu cycles to run at some minimum chosen hz. Anyway, at this point still mainly try to reach a stable msvc6 0.7.9 exe with available fdm's and aircraft ... Rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems with JSBSim under Win32 - MSVC
ok, have now tried the c310 - added --aircraft=c310 to my system.fgfsrc file ... The log ends almost identically ... In amongst it all I can see - [36m Reading Flight Control[39m Control System Name: FGFCS:c310 so it was with the c310 ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] version of cygwin glut
Roman Grigoriev writes:
>Hi ALL!
>how to know version of glut in cygwin?
>or any versions of packages in cygwin
Nothing special about Cygwin Glut is Glut
don't think there is a runtime call for this but
#include
main()
{
printf(GLUT_API_VERSION)
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems with JSBSim under Win32
> Jon, > > I think that I explained a cause of this problem in my last mail (mail > subject has been "QNAN on FG/JSBsim/win32 startup" or similar - I > haven't it on this computer now ). > Problem has been described more times by more people. Shortly, a case is > a fail of "FGInitConditions" for a stationary airplane, please look to > that mail. > It is not a MSVS - related think. Other compilers products probably has > a different behavior in case of floating point exception situation. > Please, could you look if a cause that I described occur on your > platform? Well, I have never seen this problem using Borland's compilers, g++, or IRIX. I've never gotten a floating point exception in that area, though during development I have seen floating point exceptions elsewhere. Tony has addressed this problem before, stating that the condition should never happen that causes the problem in the first place, so the real culprit is further upstream. We *do* need to investigate it, however, but since I cannot reproduce it I cannot debug it. I'll look into it as time permits, but what I really need is to work with someone who has MSVC on their machine. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] altitude hold problem
> That's actually a counter-example: this is all information that > FlightGear will have to have by default, but FDMs like JSBSim will not > (necessarily) -- since FlightGear owns the panel and the UI, it is the > component that tracks the position of every switch, stick, and so on. JSBSim will need to have all this information to model the aircraft in standalone mode. Additionally, if JSBSim does have all this information, the aircraft should still fly even if FlightGear is started up using the C-172 panel, the FCS using default values. The aircraft modeler will have intimate knowledge (we hope) of the FCS for an aircraft, and the FCS definition for a unique aircraft best resides in the config file along with the rest of the aircraft specific characteristics. JSBSim is not only a FlightGear FDM, as I have mentioned before. We have an excuse to include the FCS (and autopilot and other non-visual but still flight related models) in that JSBSim also serves (and aims to serve) aero engineering students. It's meant to be a flight dynamics tool for study and FCS experimenting. In general, I might agree with you. You could split out the FCS, the autopilot, the EOM, the propulsion, etc. Then, at some point, you might say, "Hey! Let's put all of these classes under a base class that gives us some utility, some generality, and it just makes sense." Then you'd put it altogether and you'd have basically what we have. JSBSim has not been put together in a vacuum, nor without industry precedent. Given ten different people (from ten different backgrounds) you'd get ten different flight models. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear autogen.sh,1.1,1.2
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.01.17 09:25]: > ! echo -n "Running automake" > ! if [ $OSTYPE = "IRIX" -o $OSTYPE = "IRIX64" ]; then > ! echo " --add-missing --include-deps" > ! automake --add-missing --include-deps > ! else > ! echo " --add-missing" > ! automake --add-missing > ! fi > > echo "Running autoconf" > autoconf > + > + # fixup Makefiles for Irix > + if test "$OS" = "IRIX" -o "$OS" = "IRIX64"; then Should that line have $OSTYPE instead of $OS? > + echo "Fixing Makefiles for Irix" > + for n in `find . -name Makefile.in`; do \ > + mv -f $n $n.ar-new; \ > + sed 's/$(AR) cru /$(AR) -o /g' $n.ar-new > $n; \ > + rm -f $n.ar-new; \ > + done; > + fi > > echo "" Thanks -- Cameron Moore [ Do people in Australia, call the rest of the world, "Up Over" ? ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] embedded screenshot httpd server
On Wednesday 16 January 2002 04:49, you wrote: > Is someone saving these so us poor schmucks behind frothing corporate > firewalls can view them too? :) You bet! :) jpeg's, archived jpegs, and an mpg movie of the screenshots here: http://24.116.72.89/fgfs/escreen/ Wm -- William L. Riley [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Breaking OpenGL's hold to ease debugging
In my experience, debugging FG (single-stepping, run-to-here, etc.) is almost impossible under GDB and I believe the OpenGL "I'm in charge of the main loop" philosophy is the main cause. Could we abuse OpenGL by making the idle function always request OpenGL to terminate its loop? If we can do this, then do our FG processing (that is currently done in the idle callback), then run OpenGL again to render one more frame, etc, the result might be too flickery for normal use but might be infinitely better for debugging. I expect there's a good reason why this won't work. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Breaking OpenGL's hold to ease debugging
Julian Foad writes: > >In my experience, debugging FG (single-stepping, run-to-here, >etc.) is almost impossible under GDB and I believe the OpenGL >"I'm in charge of the main loop" philosophy is the main cause. This is GLUT not OpenGL > Could we abuse OpenGL by making the idle function always >request OpenGL to terminate its loop? Only by abandoning GLUT Do you have LOTS of RAM ? In my experience Debugging FlightGear with gdb is much less painful with >256 meg this is on Win2k with Cygwin. then again I have everything compiled with -g including the Cygwin DLL < libc libstdc++ > ect Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Breaking OpenGL's hold to ease debugging
Julian Foad wrote: > In my experience, debugging FG (single-stepping, run-to-here, etc.) is > almost impossible under GDB and I believe the OpenGL "I'm in charge of > the main loop" philosophy is the main cause. I've successfully and productively run fgfs under gdb just fine. I'm not sure there's anything particularly strange about the GLUT main loop; it's actually pretty standard C. There's deep voodoo inside of the glXSwapBuffers() call, but that's not part of the event loop (nor has it caused any trouble for me that I couldn't blame on driver bugs). I *have* had difficulties getting GDB to recognize symbol names, however. Starting it up and trying to set a breakpoint for YASim::init() doesn't work, but YASim.cxx:123 (that is, the line number in the file) works just fine, so I never bothered trying to track this down. My suspicions, though, point to gcc/gdb being a little off on their name mangling conventions and/or my use of namespaces getting in the way. I've never had trouble with the OpenGL-ness of the thing, anyway. Are there particular symptoms you're seeing? > Could we abuse OpenGL by making the idle function always request > OpenGL to terminate its loop? Strictly, you're talking about GLUT, not the OpenGL libraries. And unfortunately, no. The GLUT licence doesn't allow redistribution of modified versions. There's a FreeGLUT clone that is supposed to work, I think Norman mentioned a while back that he'd run FlightGear under this. Frankly, if we really want to move away from GLUT, for whatever reason, I'd suggest SDL instead. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
> Geoff McLane wrote: > > When running your fgfs.exe the log ends abruptly with > > * Before globals->saveInitialState() > ... first thing ... is "delete initial_state;" but initial_state ... 0 > Q Can you delete a NULL pointer? > A ... deleting a pointer with a value of zero... > is guaranteed to be harmless." (ibid., Page 499) Wow? What is programming about? It should not be a question as to whether it is ok to delete a null! Any allocator/deallocator of memory can or may not have such 'testing' before commitment ... entirely implementation dependant. You programmed the machine - you 'know' if it is the 1st time thru, or an iteration - clean up your own mess. Do not trust the 'compiler' to do what you want!!! Write what you want in code ... A function should not conceptually begin with, well I better try to clean up what I didn't clean up before, before I start ... Even if(p) delete p; is horrific if you do not know what is in p! As mentioned msvc debug will fill an unitialised class ptr p with a value cdcdcdcdcd! Like the man who took his dog for a walk, only to find out he did not have a dog :-)) Its ok, I'll just delete him that does not exist! I really look forward to an exe update I can try. I have now had a chance to try a few other FDM's, and am now totally sold on 'magic'. This is 'flying'. --fdm=magic My exe crashed on ada and just 'sat' on the runway in 'balloon'. But with magic the system soared. For the very first time I saw sustained fps rates in excess of - dare I say it - 20s+. Fluid js actions ... the works. Those of you who have machines that do this all the time must be bored with my whining about 'stuttering' ... sorry. There is a GREAT flight simulator here, but how to make it 'co-operatively' work on the current pc system it is running in? A step closer we hope ... rgds, Geoff. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Geoff McLane wrote: > > My exe crashed on ada and just 'sat' on the runway > in 'balloon'. But with magic the system soared. Well, the balloon lacks one significant thing for an FDM: enable the "plane" to move around. The balloon model works nicely for raising and sinking (just give full throttle...), but as I wrote it I didn't have a clue how to change my horizontal position (and still haven't got one). But that's open source. Eventually there might be someone who knows how to do it and just implements it. I had my fun figuring out all these formulas so the balloon model did everything *I* intended it to do :) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] msvc6 - 0.7.9 release
Christian Mayer writes: >Geoff McLane wrote: >> >> My exe crashed on ada and just 'sat' on the runway >> in 'balloon'. But with magic the system soared. > >Well, the balloon lacks one significant thing for an FDM: enable the >"plane" to move around. The balloon model works nicely for raising and >sinking (just give full throttle...), but as I wrote it I didn't have a >clue how to change my horizontal position (and still haven't got one). Well if you just wanted to drift with the wind and be 'cheesy' you could use the simgear direct geodetic solver to get a new lat lon based on current position speed and course distance below = windspeed * time /** * Given a starting position and an offset radial and distance, * calculate an ending positon on a wgs84 ellipsoid. * @param alt (in) meters * @param lat1 (in) degrees * @param lon1 (in) degrees * @param az1 (in) degrees * @param s (in) distance in meters * @param lat2 (out) degrees * @param lon2 (out) degrees * @param az2 (out) return course in degrees */ int geo_direct_wgs_84 ( double alt, double lat1, double lon1, double az1, double s, double *lat2, double *lon2, double *az2 ); Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Breaking OpenGL's hold to ease debugging
Julian Foad writes: > In my experience, debugging FG (single-stepping, run-to-here, etc.) > is almost impossible under GDB It is very difficult. > and I believe the OpenGL "I'm in charge of the main loop" > philosophy is the main cause. No, the problem is the heavy use of inline functions both in FlightGear (and associated libraries) and in the Gnu standard C++ library. They confuse gdb to no end. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ummm...anyone read this?
Hi all, Was thinking it'd be nice to have a least a minimal heading and altitude hold autopilot working for LWCE. What would be the best file and property tree location to put these values in so that the existing autopilot routine is somewhat adjustable by aircraft? See notes below. Best, Jim Jim Wilson <[EMAIL PROTECTED]> said: > I've got some values that seem to work in the current autopilot code with the > c310. They are: > > min_climb = 85.0 kts > best_climb = 107.0 kts > TargetClimbRate = 1500 fpm > > Also there is this adjustment factor (code snippet from newauto.cxx aprox line > 697): > > // calculate proportional error > prop_error = error; > prop_adj = prop_error / 4000.0; > > The numbers for the c172 are 70, 75, 500, 2000.0 (in the same order as those > listed above). > > If someone could spec the XML (which file and keywords) I'd be glad to modify > the autopilot code to use them. What should this adjustment factor be called? > It basically strikes a balance in a simplistic way between over and under > adjusting elevator trim. > > It's not as good as it could be, but it'll provide a basic altitude hold > function for now. > > Best, > > Jim > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > -- Jim Wilson - IT Manager Kelco Industries PO Box 160 58 Main Street Milbridge, ME 04658 207-546-7989 - FAX 207-546-2791 http://www.kelcomaine.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] msvc6 - 0.7.9 release
Geoff McLane writes: > > A ... deleting a pointer with a value of zero... > > is guaranteed to be harmless." (ibid., Page 499) > > Wow? What is programming about? > > It should not be a question as to whether it is ok to > delete a null! Any allocator/deallocator of memory > can or may not have such 'testing' before commitment ... > entirely implementation dependant. No it's not -- I think you might be confusing it with C/Posix free. In C++, delete is an operator specified to be a no-op with a 0 argument. On every platform. Period. We use this standard C++ idiom a lot in SimGear and FlightGear, and I haven't heard of any problems to date. In classes with lazy implementations (i.e. the pointer may or may not be zero), it might make me more of a man to write if (foo != 0) delete foo; if (bar != 0) delete bar; and so on, but it doesn't accomplish anything; I might as well type if (foo > 3 && foo > 5) do_something(); Both are redundant. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ummm...anyone read this?
> > Was thinking it'd be nice to have a least a minimal heading and altitude > hold autopilot working for LWCE. What would be the best file and > property tree location to put these values in so that the existing autopilot > routine is somewhat adjustable by aircraft? See notes below. > Well, I've cobbled together a 3-axis autopilot I'm using to fly the c310 while working on the glass cockpit displays. It has a attitude hold mode, heading hold mode and a few keyboard commands to change the command values. Bad news it runs over a LAN, and would need a little work to stick into the FG autopilot code. FWIW if interested I'll be glad to send along the control laws and gains. Inputs are the FDM state variables, control surface positions, a couple of state derivatives, and command values. Output is commanded control surface deflections. Has a rudder trim and yaw damper function to handle pFactor. The whole package includes the network interfaces (UDP/TCP/IP) needed to get the state variables and return the command inputs via sockets. You could run it on a second machine to control FG. The tar file is about 200K. Regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ummm...anyone read this?
What I was looking for right now was the simple autopilot that is already in FG...ie something to keep the plane in the air when I let go of the yoke (besides pause :)). I agree it should be done right, but I can get the existing one (which is very basic) working for both c172 and c310 with very few changes. All I need to know is where the XML settings should go. They can always be expanded on. The values I have to able to set per aircraft (to start with) are: min_climb_speed, best_climb_speed, target_climb_rate, and something which for lack of a better term is an elevator_adjustment_factor (controls the severity of adjustment to elevator-trim for a given error). Best, Jim John Wojnaroski <[EMAIL PROTECTED]> said: > > > > > Was thinking it'd be nice to have a least a minimal heading and altitude > > hold autopilot working for LWCE. What would be the best file and > > property tree location to put these values in so that the existing > autopilot > > routine is somewhat adjustable by aircraft? See notes below. > > > Well, I've cobbled together a 3-axis autopilot I'm using to fly the c310 > while working on the glass cockpit displays. It has a attitude hold mode, > heading hold mode and a few keyboard commands to change the command values. > > Bad news it runs over a LAN, and would need a little work to stick into the > FG autopilot code. FWIW if interested I'll be glad to send along the > control laws and gains. Inputs are the FDM state variables, control surface > positions, a couple of state derivatives, and command values. Output > is commanded control surface deflections. Has a rudder trim and yaw damper > function to handle pFactor. > > The whole package includes the network interfaces (UDP/TCP/IP) needed to get > the state variables and return the command inputs via sockets. > You could run it on a second machine to control FG. The tar file is about > 200K. > > Regards > John W. > > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ummm...anyone read this?
> What I was looking for right now was the simple autopilot that is already in > FG...ie something to keep the plane in the air when I let go of the yoke > (besides pause :)). I agree it should be done right, but I can get the > existing one (which is very basic) working for both c172 and c310 with very > few changes. > > All I need to know is where the XML settings should go. They can always be > expanded on. > Well, okay. sorry I can't help you with the XML stuff or the numbers. The network interface code is in the CVS and the package includes a simple makefile. Just need to add a *--socket=* to the command line or whatever to set the sockets (assuming you have a network) so if you change your mind give a holler. regards John W. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
