RE: [Flightgear-devel] Building the latest ...
Never mind. I guess the CVS repository for plib has changed/ > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Jon Berndt > Sent: Sunday, July 18, 2004 9:23 PM > To: Flightgear-Devel > Subject: [Flightgear-devel] Building the latest ... > > > I had forgotten that FlightGear has been moved over to OpenAL. I downloaded the new > base > package to see if there is an L1011 there (I didn't see one). But, now, my FlightGear > executable doesn't work with the new base package, so I tried downloading plib, but > plib > cvs doesn't seem to be up at the moment. > > I also found that I have this: > > libopenal32.a > > in /usr/local/lib. I'm wondering if this is now standard issue in a CygWin > install. Does > anyone know? > > Jon > > > ___ > 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] Building the latest ...
I had forgotten that FlightGear has been moved over to OpenAL. I downloaded the new base package to see if there is an L1011 there (I didn't see one). But, now, my FlightGear executable doesn't work with the new base package, so I tried downloading plib, but plib cvs doesn't seem to be up at the moment. I also found that I have this: libopenal32.a in /usr/local/lib. I'm wondering if this is now standard issue in a CygWin install. Does anyone know? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Plotting
Hi While trying to correctly tweak the FDM and PID controllers for the L1011-500, i though it would be really nice to have some sort of standalone app running on a remote machine, plotting selected property(es) "oscilloscope style" (in my case, i'd like to make it run in my old P133). I saw that this is not a new idea, is there anything usable at the moment? If not, i wouldn't mind to work on it, just point me in the right direction :) a little OT: What other tools might be useful in "debugging" aircrafts? Thanks in advance, Tiago ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 0.9.5 pre1 build on Fedora Core 2
Not sure if this has been reported yet, but I just built 0.9.5 pre1 on fedora core 2 and it seems that the file fg_os.cxx is missing. If I use the --enable-sdl option, the code compiles since it uses fg_os_sdl.cxx in place of fg_os.cxx. However, when I run the code it aborts with a message about an uncaught exception in Main. I've been running 0.9.4 on FC2 without problems. I've also been running code from CVS on FC1 without problems. Here's more specifics: Dell inspiron 4100 laptop with a radeon graphics chip, FC2, openal from their CVS, gcc (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7), uname -a: Linux shelley 2.6.5-1.358. AS I said, 0.9.4 works just fine. Here's the error message: [EMAIL PROTECTED] FlightGear-0.9.5-pre1]$ fgfs disabling TCL support Initializing OpenAL sound manager Unknown exception in the main loop. Aborting... [EMAIL PROTECTED] FlightGear-0.9.5-pre1]$ James - This mail sent through IMP: http://horde.org/imp/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] distance to nearby objects
Does FlightGear provide some sort of way to determine distance between the aircraft and a stationary object?... ie, building, mountain. I'm working on an autonomous flight controller and need to have this sort of feedback. If not, could anyone suggest how this could be done? Where in the source code could I extract stationary object edge info within some given range of the flying aircraft? I'm considering how real onboard sensors would determine this, ie. optics. thanks... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Navaid/navlist patch
Hi,
Sorry to have got things messed up.
Attached is the patched file against the latest CVS version.
Below is a diff -c patch.
I've attached the file as well in case line wrap screws things up too.
It's great to be able to make a contribution even if
it's only a small patch.
I also working on a joystick setup file for a Saitek P880
(2 pair analogue axes, 1 pair digital hat, 11 buttons).
Could you put me in touch with the DC3 'team/guru'?
*** navlist.cvs 2004-07-18 20:27:48.0 +0100
--- navlist.cxx 2004-07-18 20:27:53.0 +0100
***
*** 182,189
{
FGNavRecord *nav = NULL;
Point3D station;
! double dist;
! double min_dist = FG_NAV_MAX_RANGE * SG_NM_TO_METER;
// find the closest station within a sensible range
(FG_NAV_MAX_RANGE)
for ( unsigned int i = 0; i < stations.size(); ++i ) {
--- 182,190
{
FGNavRecord *nav = NULL;
Point3D station;
! double d2;
! double min_dist = FG_NAV_MAX_RANGE*SG_NM_TO_METER *
FG_NAV_MAX_RANGE*SG_NM_TO_METER ;
!
// find the closest station within a sensible range
(FG_NAV_MAX_RANGE)
for ( unsigned int i = 0; i < stations.size(); ++i ) {
***
*** 192,205
stations[i]->get_y(),
stations[i]->get_z() );
! dist = aircraft.distance3D( station );
// cout << " dist = " << sqrt(d)
// << " range = " << current->get_range() * SG_NM_TO_METER
// << endl;
! if ( dist < min_dist ) {
! min_dist = dist;
nav = stations[i];
}
}
--- 193,224
stations[i]->get_y(),config
config stations[i]->get_z() );
! d2 = aircraft.distance3Dsquared( station );
// cout << " dist = " << sqrt(d)
// << " range = " << current->get_range() * SG_NM_TO_METER
// << endl;
! // LOC or ILS must point substantially toward the aircraft
! // This is to stop finding the nearer LOC/ILS transmitter which is
facing away from the a/c
! // make this expensive check only when needed
! if ( d2 < min_dist && (stations[i]->get_type() == 4 ||
stations[i]->get_type() == 5)) {
! double az1=0.0, az2=0.0, s=0.0;
! double elev=0.0, lati=0.0, longi=0.0;
! double xyz[3] = {aircraft.x(), aircraft.y(), aircraft.z()};
! sgCartToGeod(xyz, &lati, &longi, &elev);
! geo_inverse_wgs_84(elev, lati * SG_RADIANS_TO_DEGREES, longi *
SG_RADIANS_TO_DEGREES,
! stations[i]->get_lat() , stations[i]->get_lon() ,
! &az1, &az2, &s);
! az1 = az1-stations[i]->get_multiuse();
! while (az1> 180.0) az1 -= 360.0;
! while (az1< -180.0) az1 += 360.0;
! // make d2 fail test if not pointing the right way.
! if (fabs(az1) > 30.0 ) d2 = min_dist+1.0;
! }
!
! if ( d2 < min_dist ) {
! min_dist = d2;
nav = stations[i];
}
}
--
Ed Sirett <[EMAIL PROTECTED]>
// navlist.cxx -- navaids management class
//
// Written by Curtis Olson, started April 2000.
//
// Copyright (C) 2000 Curtis L. Olson - [EMAIL PROTECTED]
//
// This program is free software; you can redistribute it and/or
// modify it under the terms of the GNU General Public License as
// published by the Free Software Foundation; either version 2 of the
// License, or (at your option) any later version.
//
// This program is distributed in the hope that it will be useful, but
// WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
// General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
//
// $Id: navlist.cxx,v 1.6 2004/06/20 18:58:45 curt Exp $
#ifdef HAVE_CONFIG_H
# include
#endif
#include
#include
#include
#include "navlist.hxx"
// Constructor
FGNavList::FGNavList( void ) {
}
// Destructor
FGNavList::~FGNavList( void ) {
}
// load the navaids and build the map
bool FGNavList::init() {
// FIXME: leaves all the individual navaid entries leaked
navaids.erase( navaids.begin(), navaids.end() );
navaids_by_tile.erase( navaids_by_tile.begin(), navaids_by_tile.end() );
ident_navaids.erase( ident_navaids.begin(), ident_navaids.end() );
return true;
}
// real add a marker beacon
static void real_add( nav_map_type &navmap, const int master_index,
FGNavRecord *n )
{
navmap[master_index].push_back( n );
}
// front end for add a marker beacon
static void tile_add( nav_map_type &navmap, F
Re: [Flightgear-devel] Next release of FlightGear
[EMAIL PROTECTED] wrote: Erik Hofman wrote: IRIX and Solaris binaries also include it by default. I'm not sure about other distributions, but I would encourage them to include it with the distribution. I include it with the slackware package too. Is there likely to be a new release of fgrun before the release of 0.9.5 or should I use the cvs version? What is in cvs is the next release of fgrun. I was testing it yesterday when my hard drive crashed. It may be some time before my system and data are fully recovered. OK, no problem - I'll use the cvs version in my test packages. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
Durk Talsma wrote: > The new scenery (the 0.9.5 release, downloaded using terrasync) > > Cheers, > Durk > > On Sunday 18 July 2004 23:08, Frederic Bouvier wrote: > > Durk Talsma wrote: > > > > Ehm, to both of you, was this using the real-weather option turned on > > > > or anything other which might be related? > > > > > > Euhhm, yes, I always have turned the real-weather option on by default. > > > > Are you using the old or the new Scenery. There was some changes in the > > animation code to support towers and beacons. It is too late here so I can't have a look right now, but I am thinking specifically of the class SGPersonalityBranch in personality.[ch]xx that stores data for each individual tower. I can't remember exactly but it occured to me that there could be a leak here, keeping states for unloaded towers, but I still have to remember how it was designed. I will look at it tomorrow if nobody beat me tonight. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
The new scenery (the 0.9.5 release, downloaded using terrasync) Cheers, Durk On Sunday 18 July 2004 23:08, Frederic Bouvier wrote: > Durk Talsma wrote: > > > Ehm, to both of you, was this using the real-weather option turned on > > > or anything other which might be related? > > > > Euhhm, yes, I always have turned the real-weather option on by default. > > Are you using the old or the new Scenery. There was some changes in the > animation code to support towers and beacons. > > -Fred > > > > ___ > 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] scenery paging memory leak
Durk Talsma wrote: > > > Ehm, to both of you, was this using the real-weather option turned on or > > anything other which might be related? > > > > Euhhm, yes, I always have turned the real-weather option on by default. Are you using the old or the new Scenery. There was some changes in the animation code to support towers and beacons. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
> Ehm, to both of you, was this using the real-weather option turned on or > anything other which might be related? > Euhhm, yes, I always have turned the real-weather option on by default. Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
FGFS and Controls Was Re: [Flightgear-devel] GUI to generate fsgs CLI options
>
> What you are looking for is called fgrun and is here :
> http://sourceforge.net/projects/fgrun
>
> -Fred
>
> PS: fgfs, not fsgs ;-)
>
Yeah... ahemm... sorry about the typo... 10 years of Flight Simulator
habits to shed on my side... ;-P
Thanks for pointing me to the existing project!
On another side note, after flying for a few hours here and there, I
noticed that something great works on FG which did not on MSFS: controls
are usable in 3d cockpit mode... I'd like to know if people would find it
useful to enable a mouse drag incrementation step feature for knobs and
similar controls... Currently, if you click on a knob (sensitive zone,
highlighted by CTRL-C), it increments or decrements as long as it is DOWN.
But what I'd like is to push this one step further, by increasing the step
of the value incrementation relatively to the distance the mouse pointer
is dragued away from the manipulated control (click sensitive zone). This
would be quite useful for heading, altitude and nav knobs, way friendlier
than the MS scheme of increasing the pace of incrementation relative to
the -time- the mouse button is DOWN, and not too hard to implement!
Say,
step = sqrt(distance - 10);
if(step < 1) {
step = 1;
}
so that within 10 pixels it is incremented by 1, but if you go away from
that, at a 110 pixels it would be incremented by 10 for each cycles, and
at a maximum of about 30-35 per cycle if you were draging away from a
leftmost control at the rightmost edge of the display in 1024x768...
I haven't looked the code yet but I see tons of features which I would be
willing to play with, from control tweaks to automatic cloud cover
generation using GOES images and precipitation from NWS and Environnement
Canada Doppler Radar...(Still looking around the existing features).
Fantastic job you guys have done so far! I hope I'll be able to contribute
soon!
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem on exiting ( was: Next release ofFlightGear )
That patch worked just fine. Hopefully it can be rolled into CVS
before the release.
Thanks!
Jonathan Polley
On Jul 18, 2004, at 7:40 AM, Frederic Bouvier wrote:
Frederic Bouvier wrote:
Jonathan Polley wrote:
Fred,
It turns out that the problem should exist on every FlightGear
system, not just the Mac. On exit(), fgExitCleanup() is called which
deletes the globals class and then calls fgOSExit(). The only thing
that fgOSExit() does is turn around and call exit(), which repeats
the
process. I changed fgExitCleanup() in main.cxx to be as follows:
void fgExitCleanup() {
delete globals;
//fgOSExit(0);
}
This prevented the recursive call to exit(), but will not work if
someone is using the fg_os_sld.cxx module, but it works for me.
I was suspecting that but was not able to reproduce this behavior on
windows.
What about this instead :
void fgExitCleanup() {
if ( globals ) {
delete globals;
globals = 0;
fgOSExit(0);
}
}
It will allow to call the function twice safely. Can you test that.
And what about this that might be better.
-Fred
--- main.cxx 15 Jul 2004 18:07:03 - 1.170
+++ main.cxx 18 Jul 2004 12:38:52 -
@@ -1495,7 +1495,6 @@
// which happens in the sound manager destructor.
void fgExitCleanup() {
delete globals;
-fgOSExit(0);
}
--- util.cxx 16 Mar 2004 20:19:08 - 1.7
+++ util.cxx 18 Jul 2004 12:35:38 -
@@ -27,6 +27,7 @@
#include
+#include "fg_os.hxx"
#include "fg_io.hxx"
#include "fg_props.hxx"
#include "globals.hxx"
@@ -107,7 +108,7 @@
SG_LOG(SG_GENERAL, SG_INFO, "Exiting FlightGear with status " <<
status);
globals->get_io()->shutdown_all();
-exit(status);
+fgOSExit(status);
}
___
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] Next release of FlightGear
I wrote > Sent: 17 July 2004 15:22 > To: 'FlightGear developers discussions' > Subject: RE: [Flightgear-devel] Next release of FlightGear > > Erik Hofman wrote > > > Sent: 17 July 2004 14:51 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] Next release of FlightGear > > > > Vivian Meazza wrote: > > > > > Once the offending entries are removed from simgear/sound, simgear > > compiles > > > correctly, but Norman's pre-built libraries were still present. I'll > > remove > > > those and try again. > > > > Nono, that's not what I meant. > > Norman once build a separate library for alut and openal, but in the end > > put them together into on library called openal. > > > > So I guess we just should remove the entries from configure.ac now. > > > > Thanks for testing this. > > > > I'm a bit confused now! > > Norman's last version put all the stuff into openal > > Unless test1 and test2 do something useful they can be easily removed from > simgear/sound/makefile.am > > V. Both Simgear-cvs and FlightGear-cvs compile without error post Eric's latest changes. Well done! First time since the introduction of OpenAL. Regards Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
Durk Talsma wrote: I do remember seeing something similar happening, on a long haul test flight between Tokyo and Sydney, which judging from the timestamp on the scenery directory, I did around the 22nd of June. Same problem: Huge memory leak, up to the point where the aircraft became uncontrollable. I reran the same route the next day, and nothing happened. Weird. Anyways, hope that the date of my problem flight may be of any help finding this bug. Actually, I'm testing long range performance right now, doing a 10 hour KSFO to EHAM trip. Memory use appears to be rock solid. Ehm, to both of you, was this using the real-weather option turned on or anything other which might be related? Erik On Sunday 18 July 2004 21:05, Curtis L. Olson wrote: Hey guys, Did we introduce a memory leak when paging scenery recently? I left FG running all night (with ATC and AI traffic disabled) and memory usage was stable. Then I went for 2-3 hour flight and just about filled up all my main RAM + Swap on my linux machine before I finally killed landed and exited. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
Curtis L. Olson wrote: Hey guys, Did we introduce a memory leak when paging scenery recently? I left FG running all night (with ATC and AI traffic disabled) and memory usage was stable. Then I went for 2-3 hour flight and just about filled up all my main RAM + Swap on my linux machine before I finally killed landed and exited. I know we were very careful when we set this all up to make sure memory usage was stable during scenery paging and that we didn't leak any memory, but something seems to have crept in along the way with one of the changes. The only thing I can remember recenly is support for terrain/object separation in the directory structure and some sort of simplistic state presorting when loading terrain. Could one of those things be doing this? It's hard to believe that the terrain/object separation has something to do with this, because it only affects the location where the scenery related files can be found. It doesn't touch the loader and or deletion of them. There was also a change in the texture loading code to allow more than one texture to be defined per material, but taking a quick look at that code (defined in mat.cxx search for \"texture\") didn't show anything obvious. And there is the code change to allow a different texture path for a 3d model but again, I find that one very unlikely to cause a memory leak. So I can't think of anything obvious right now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery paging memory leak
Curt, I do remember seeing something similar happening, on a long haul test flight between Tokyo and Sydney, which judging from the timestamp on the scenery directory, I did around the 22nd of June. Same problem: Huge memory leak, up to the point where the aircraft became uncontrollable. I reran the same route the next day, and nothing happened. Weird. Anyways, hope that the date of my problem flight may be of any help finding this bug. Actually, I'm testing long range performance right now, doing a 10 hour KSFO to EHAM trip. Memory use appears to be rock solid. Cheers, Durk On Sunday 18 July 2004 21:05, Curtis L. Olson wrote: > Hey guys, > > Did we introduce a memory leak when paging scenery recently? I left FG > running all night (with ATC and AI traffic disabled) and memory usage > was stable. Then I went for 2-3 hour flight and just about filled up > all my main RAM + Swap on my linux machine before I finally killed > landed and exited. I know we were very careful when we set this all up > to make sure memory usage was stable during scenery paging and that we > didn't leak any memory, but something seems to have crept in along the > way with one of the changes. The only thing I can remember recenly is > support for terrain/object separation in the directory structure and > some sort of simplistic state presorting when loading terrain. Could > one of those things be doing this? Has anything else changed? This is > not good if someone wants to do long flights > > Thanks, > > Curt. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI to generate fsgs CLI options
Remy Villeneuve wrote: > Hi, > > Just discovered Flight Gear last night, and it installed relatively well, > apart from the missing fs_os.cxx problem which I finally tackled by using > the file from CVS (before I had the chance of reading Erik's comment on > the tarball hickup)... Anyway, great work you guys have already done! > > But I'd be interested to know if there has been work, support or > propositions to make a GUI application to generate and pass command line > options to fsgs... Not that I'm not used to command line parameters, but > sometimes, you just want to hit ENTER and jump into the action. > > So I figured that making either an ncurse and/or X/KDE/gnome front end > user interface to generate parameters, like selecting the airport from a > list instead of typing it manually, same with airplanes, and also to > enable or disable certain options would be appreciated by "the public". > > The way I see it, I'd do a wrapper which would generate the appropriate > command line $options, call "fsgs $options", and depending on how we see > it's use, it could kill fsgs and restart it with new $options if the users > wishes so... > > This is similar to what M$ FS2X does, with a welcome splash screen where > you can set the weather, flight plans, aircraft, fuel, airport, etc. Then, > you call the flight environment itself. > > Any ideas? If not for others, I'll do it for myself in ncurses... What you are looking for is called fgrun and is here : http://sourceforge.net/projects/fgrun -Fred PS: fgfs, not fsgs ;-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] GUI to generate fsgs CLI options
Remy Villeneuve wrote: Hi, Just discovered Flight Gear last night, and it installed relatively well, apart from the missing fs_os.cxx problem which I finally tackled by using the file from CVS (before I had the chance of reading Erik's comment on the tarball hickup)... Anyway, great work you guys have already done! But I'd be interested to know if there has been work, support or propositions to make a GUI application to generate and pass command line options to fsgs... Not that I'm not used to command line parameters, but sometimes, you just want to hit ENTER and jump into the action. Any ideas? Bernie Bright already started such a program two years ago. It's called fgrun an can be found at: http://sourceforge.net/projects/fgrun Erik BTW. Most binary distributions ship with fgrun these days. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] scenery paging memory leak
Hey guys, Did we introduce a memory leak when paging scenery recently? I left FG running all night (with ATC and AI traffic disabled) and memory usage was stable. Then I went for 2-3 hour flight and just about filled up all my main RAM + Swap on my linux machine before I finally killed landed and exited. I know we were very careful when we set this all up to make sure memory usage was stable during scenery paging and that we didn't leak any memory, but something seems to have crept in along the way with one of the changes. The only thing I can remember recenly is support for terrain/object separation in the directory structure and some sort of simplistic state presorting when loading terrain. Could one of those things be doing this? Has anything else changed? This is not good if someone wants to do long flights Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] GUI to generate fsgs CLI options
Hi, Just discovered Flight Gear last night, and it installed relatively well, apart from the missing fs_os.cxx problem which I finally tackled by using the file from CVS (before I had the chance of reading Erik's comment on the tarball hickup)... Anyway, great work you guys have already done! But I'd be interested to know if there has been work, support or propositions to make a GUI application to generate and pass command line options to fsgs... Not that I'm not used to command line parameters, but sometimes, you just want to hit ENTER and jump into the action. So I figured that making either an ncurse and/or X/KDE/gnome front end user interface to generate parameters, like selecting the airport from a list instead of typing it manually, same with airplanes, and also to enable or disable certain options would be appreciated by "the public". The way I see it, I'd do a wrapper which would generate the appropriate command line $options, call "fsgs $options", and depending on how we see it's use, it could kill fsgs and restart it with new $options if the users wishes so... This is similar to what M$ FS2X does, with a welcome splash screen where you can set the weather, flight plans, aircraft, fuel, airport, etc. Then, you call the flight environment itself. Any ideas? If not for others, I'll do it for myself in ncurses... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for Navaids/navlist.cxx
Ed Sirett wrote: This patch should fix the problem with src/Navaids/navlist.cxx choosing the wrong localizer on a runway with localizers at each end on the same frequency. [There seems to be quite a few in the UK like this, EGLL, EGLC, EGSS]. Selecting the autopilot 'LOC' without this patch causes planes to turn round and flu away from the intended destination. I have arbitrarily chosen a +/- 30 degree window for selection because this seems reasonable if in reality its smaller then OK. Could you send me this in context diff format (-c) or just send the entire new file. Also the version in the header was different in your patch. Could you send the patch relative to the latest version in CVS? Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Patch for Navaids/navlist.cxx
This patch should fix the problem with src/Navaids/navlist.cxx choosing
the wrong localizer on a runway with localizers at each end on the same
frequency. [There seems to be quite a few in the UK like this, EGLL,
EGLC, EGSS]. Selecting the autopilot 'LOC' without this patch causes
planes to turn round and flu away from the intended destination.
I have arbitrarily chosen a +/- 30 degree window for selection because
this seems reasonable if in reality its smaller then OK.
--
Ed Sirett <[EMAIL PROTECTED]>
21c21
< // $Id: navlist.cxx,v 1.6 2004/06/20 18:58:45 curt Exp $
---
> // $Id: navlist.cxx,v 1.5 2004/05/28 05:24:54 curt Exp $
185,186c185,187
< double dist;
< double min_dist = FG_NAV_MAX_RANGE * SG_NM_TO_METER;
---
> double d2;
> double min_dist = FG_NAV_MAX_RANGE*SG_NM_TO_METER *
FG_NAV_MAX_RANGE*SG_NM_TO_METER ;
>
188c189
< // find the closest station within a sensible range
(FG_NAV_MAX_RANGE)
---
> // check if any of the remaining stations are closer
195c196
< dist = aircraft.distance3D( station );
---
> d2 = aircraft.distance3Dsquared( station );
201,202c202,221
< if ( dist < min_dist ) {
< min_dist = dist;
---
> // LOC or ILS must point substantially toward the aircraft
> // This is to stop finding the nearer LOC/ILS transmitter which is
facing away from the a/c
> // make this expensive check only when needed
> if ( d2 < min_dist && (stations[i]->get_type() == 4 ||
stations[i]->get_type() == 5)) {
> double az1=0.0, az2=0.0, s=0.0;
> double elev=0.0, lati=0.0, longi=0.0;
> double xyz[3] = {aircraft.x(), aircraft.y(), aircraft.z()};
> sgCartToGeod(xyz, &lati, &longi, &elev);
> geo_inverse_wgs_84(elev, lati * SG_RADIANS_TO_DEGREES, longi *
SG_RADIANS_TO_DEGREES,
> stations[i]->get_lat() , stations[i]->get_lon() ,
> &az1, &az2, &s);
> az1 = az1-stations[i]->get_multiuse();
> while (az1> 180.0) az1 -= 360.0;
> while (az1< -180.0) az1 += 360.0;
> // make d2 fail test if not pointing the right way.
> if (fabs(az1) > 30.0 ) d2 = min_dist+1.0;
> }
>
> if ( d2 < min_dist ) {
> min_dist = d2;
206d224
<
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I just crashed FlightGear using a dialog definition file / Nasal
Boris Koenig wrote: > Frederic Bouvier wrote: > > In fact, the combo's arrow is 16 pixels wide and an input must be at least 15 pixels. > > That means that every combo that are 31 pixels or less > > are causing a segfault in a function named chop_to_width > > in puInput.cxx. > > okay, makes sense - even though I seem to remember that there DID occur > some problems with controls > 31 px. > But unfortunately only on an ocassional basis. 31 px is for combos. Other limits may apply to other kind of controls -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I just crashed FlightGear using a dialog definition file / Nasal
Frederic Bouvier wrote: This is really a PUI bug. In fact, the combo's arrow is 16 pixels wide and an input must be at least 15 pixels. That means that every combo that are 31 pixels or less are causing a segfault in a function named chop_to_width in puInput.cxx. okay, makes sense - even though I seem to remember that there DID occur some problems with controls > 31 px. But unfortunately only on an ocassional basis. I don't have the time nor feel the need to provide a patch so don't hesitate to contribute one to the plib group. I'll at least report it and ask if they consider it "serious" enough to be fixed, because as I mentioned already, I don't consider it "critical" either - it's just something I stumpled over. I don't see how flightgear could prevent the use of such a width when values are hardwired inside the library and there is no check in it. Well, I've had a quick lool into the code, and if I understand things correctly one could at least provide some basic width check if one really wanted to make sure this bug doesn't occur. And the segfault is not caused by a wrong read access, but after many wrong write access, so trying to catch the fault and continue leads to a crash somewhere else because of corrupted memory. Yes, that would explain why some of these problems were not easy to reproduce, and maybe also whhy the whole thing is interpreted as a Nasal error ? You are hard to follow. What about your initial posting : # Nasal parse error: empty subexpression in , line 3 # Failed to execute command nasal # Segmentation fault As I just pointed out to Andy, this was the console output prior to the crash. and : Interesting though, the problem does not occur if there's only ONE value element specified for a combo box. ? This means exactly what I wrote: the problem did only occur if there are more than 1 elements in a combo box. At least that's what I could observe here. The width problem occurs for one or more values when width <= 31. When width > 31, there is no 'Nasal parse error' ( there is no such error when width <= 31 either ) You may be right, which would mean that I would have to check the other dialogs involved, I'll do that later - but actually I did receive that parse error only with that said dialog (which is admittedly weird). --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I just crashed FlightGear using a dialog definition file / Nasal
Andy Ross wrote: Boris Koenig wrote: There seem to be some issues regarding the XML file processing and FlightGear's stability: #Nasal parse error: empty subexpression in , line 3 #Failed to execute command nasal #Segmentation fault The XML you posted contains no Nasal script, so I'm at a loss as you how you are producing this crash... Sorry, as Frederic pointed out already the whole issue is not about Nasal itself or the XML-handling but rather a problem in PUI, I mentioned Nasal only because the error message above is exactly what you receive _mostly_ from FG when trying to deal with insufficiently sized controls. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I just crashed FlightGear using a dialog definition file / Nasal
Boris Koenig wrote: > There seem to be some issues regarding the XML file processing > and FlightGear's stability: > > #Nasal parse error: empty subexpression in , line 3 > #Failed to execute command nasal > #Segmentation fault The XML you posted contains no Nasal script, so I'm at a loss as you how you are producing this crash... Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] thread question
When I stop FG very quickly after starting it, I have often segfaults in the loader thread. I think it is because the tiles are still loading while globals is being deleted. I would like to ask the thread to stop and wait its effective terminaison before deleting globals. How can we stop this thread ? Is calling SGThread::cancel() followed by SGThread::join() the right way ? -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote: > Frederic Bouvier wrote: > > > What about calling SDL_Quit in a function installed by 'atexit', remove > > fgOSExit and only rely on exit in all the program ? > > The problem is that plib has taken the liberty to call exit() whenever > they feel like it You don't have to look into plib to find a lot of exit. jsbsim has its share and some other modules that are not willing to include fg_os.hxx. So I think it is safer not to provide our specific exit function and rely on atexit callbacks. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Frederic Bouvier wrote: What about calling SDL_Quit in a function installed by 'atexit', remove fgOSExit and only rely on exit in all the program ? The problem is that plib has taken the liberty to call exit() whenever they feel like it Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Jonathan Polley wrote:
> Fred,
>
> It turns out that the problem should exist on every FlightGear
> system, not just the Mac. On exit(), fgExitCleanup() is called which
> deletes the globals class and then calls fgOSExit(). The only thing
> that fgOSExit() does is turn around and call exit(), which repeats the
> process. I changed fgExitCleanup() in main.cxx to be as follows:
>
> void fgExitCleanup() {
> delete globals;
> //fgOSExit(0);
> }
>
> This prevented the recursive call to exit(), but will not work if
> someone is using the fg_os_sld.cxx module, but it works for me.
I proposed two patches but there is a question that maybe Andy could
answer : what is the purpose of fgOSExit ? It comes to me because
this function, is called only once in FlightGear while exit is called
at many locations. fgOSExit is just calling exit for the glut version
and SDL_Quit() + exit in the sdl version.
What about calling SDL_Quit in a function installed by 'atexit', remove
fgOSExit and only rely on exit in all the program ?
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I just crashed FlightGear using a dialog definition file / Nasal
Boris Koenig > Frederic Bouvier wrote: > > Combo arrows are 16 pixels wide, so the input is -6 pixels . ( The width is not in > > characters but in pixels ) > > > thanks for the explanation, but I was aware of that. > And NO, this problem did not only occur with a width > specification of <= 16, but rather <= 30/50 - the latter > is unfortunately not permanently reproducable (that's why > I chose to provide 10 and not the other values) This is really a PUI bug. In fact, the combo's arrow is 16 pixels wide and an input must be at least 15 pixels. That means that every combo that are 31 pixels or less are causing a segfault in a function named chop_to_width in puInput.cxx. I don't have the time nor feel the need to provide a patch so don't hesitate to contribute one to the plib group. I don't see how flightgear could prevent the use of such a width when values are hardwired inside the library and there is no check in it. And the segfault is not caused by a wrong read access, but after many wrong write access, so trying to catch the fault and continue leads to a crash somewhere else because of corrupted memory. > > >>25 > >>test > >> > >>another test > > > > > > No problem with either one or two values, when the combo width is set to > > 100. > > sure, but that wasn't what I asked :-) > Don't have any problems with a width of 100 either ! You are hard to follow. What about your initial posting : > # Nasal parse error: empty subexpression in , line 3 > # Failed to execute command nasal > # Segmentation fault and : > Interesting though, the problem does not occur if there's only ONE value > element specified for a combo box. ? The width problem occurs for one or more values when width <= 31. When width > 31, there is no 'Nasal parse error' ( there is no such error when width <= 31 either ) -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Boris Koenig wrote:
Erik Hofman wrote:
Well, if we turn all that off, people start to complain that
FlightGear looks like crap and will search for something else. At
least now they start asking questions ...
Then how about optionally offering to disable such things in the
("advanced") rendering options dialog ?
It should be there already...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Some problems that I have ran into with the latest CVS
Jacek wrote: Do you really distinguish those ... and ---? ;-) Well, to be honest only since just recently - there are some fairly decent morse code training applications available, so if you keep hearing the same stuff for an hour a day you start to get it one day ... But it's the same problem with a & n ... As to the dialog check boxes I've just checked out a few: PAUSED morse & engine is playing no is mutedyes show frame rateyes enhenced runway lightingyes Sun/Moon horizon effect yesclouds coverage yes time of dayno (yes=I can change to opposite state, no=I can't) yes, it's somehow a bit irregular - you CAN stop the morse code directly by unmuting everything and the re-muting the whole application (must not be paused then !), I guess the morse-stuff simply doesn't take the mute status into consideration yet - at least not during startup. Also, the properties dialog doesn't seem to get automatically updated (if openend !) when one changes the properties via the telnet/http interface. Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RE: Help 3D model about FlightGear.
Innis Cunningham wrote: Hi All If John is using AC3D 4.0 then there is a problem using those models in FG.There is a crease statement that FG/Plib can't handle.So to get around the problem you either have to text edit all reference to the crease statement in the AC3D file (tedious) or build the model using AC3D 3.6 or earlier.I have gone back to building the models in 3.6. You could easily automatize these steps with one or two shell commands, but if the current workaround is to simply remove all references to "crease", then how about simply accepting the crease statement programmatically but ignore it during execution ? This shouldn't be too much of a change ?! And that way one would at least have a hard-coded workaround, so no new problems with that issue and everybody could keep using AC3D. In the meanwhile the thing might be noteworthy within the FlightGear docs, though. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I just crashed FlightGear using a dialogdefinition file / Nasal
Frederic Bouvier wrote: What do you want to prove with a field so narrow ? I don't want to "prove" anything, that was just an example - e.g. I encountered the problem when I created controls whose width was insufficient for the string to be displayed. And that's exactly what I pointed out with mail. that neither FG nor PUI are protecting themselves against negative values ? well, if you want to put it that way, but actually this was at most about a crash that I encountered frequently. By the way, yesterday it locked even up the whole system... Combo arrows are 16 pixels wide, so the input is -6 pixels . ( The width is not in characters but in pixels ) thanks for the explanation, but I was aware of that. And NO, this problem did not only occur with a width specification of <= 16, but rather <= 30/50 - the latter is unfortunately not permanently reproducable (that's why I chose to provide 10 and not the other values) The only reason why I actually posted this "bug" to the mailing list is indeed, that I don't think something trivial such as dialog definition should be able to crash the whole application. EVEN though the actual usage of such a dialog definition is pretty unlikely (as I stated before). And I think, I *did* mention that this is certainly not a critical bug, because few people will ever create their own dialogs and even less would use such values - but I found it by accident and NOT to "prove" anything, if I wanted to _prove_ anything I would now start to look for other problems related to this, for example in the panel handling stuff. 25 test another test No problem with either one or two values, when the combo width is set to 100. sure, but that wasn't what I asked :-) Don't have any problems with a width of 100 either ! You seem to get me wrong here , you know, I am not posting this because I was specifically looking for bugs in FlightGear, but rather because I wanted to create a SMALL combo box (width < 50 pixels) for one of the dialogs that I am currently working on - so this all happend by accident. And as it seemed reproducable I thought it should be mentioned here - NOTHING more. regards -- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote: This is the penalty for those who want eye-candy. If specular highlighting is supported it will be enabled an make FlightGear slower. I noticed some enhancements in the new rendering dialog, and would like to ask how feasible it would be to integrate even more performance-related options into that rendering dialog. (see my other posting) So, generally I am talking about the rendering options that one can already provide via command line. It might be really useful if you could change these while the game is running - just for every user to be able to achieve a reasonable frame rate, this is just because I also noticed some decrease in FPS with the latest CVS built - and would like to be able to find the best configuration directly within the game. We could even introduce some basic kind of "rendering profiles", using comboboxes users could define their profiles and switch the profiles on the fly. Just a thought, though ... By the way: I noticed that the feature request/bug report options at sourceforge were being used at some time, is this still being maintained or at least looked at regularly ? Because, otherwise I would really suggest to separately install some kind of feature/bug database at flightgear.org - just drop me a line if you need help doing that. :-) --- Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Richard Harke wrote: On Saturday 17 July 2004 07:08 am, Innis Cunningham wrote: I had a GeForce 2 Titanium with a PIII Xeon at 550MHz getting about 15 fps over SF Video card crapped out (even has a red LED come on to tell you it has crapped out) so I bought a Geforce FX 5200 Frame rate dropped to 4 in same circumstances. Occasionally up to 6. I already had plans to upgrade so I didn't panic New system is P4 at 3.0 GHz with 1MB cache AGP runs at 8x So now my frame rate is back to 15, though it does jump into the high 20's sometimes. Same copy of the executable in all cases. (CVS from mid Feb) This is rather disappointing, to be honest. I think there IS a point to it, because I've made very similar and *weird* observations, running on a pretty decent system with a nvidia card, you would get about 15-20 (the latter rarely) FPS, while taking the same CVS stuff to an OLD system (< 1 GHZ, 1 GIG RAM, ATI RAGE128) gives usually even more than these 20 FPS, as I am currently trying to summarize which subsystems I need and which of these can be "disabled" I have also made the following attempt: - disabling pretty much all rendering stuff - => now having an empty FG window - show the framerate THEN On my (decent) main system I keep getting not more than 30 FPS, while I do get around 50+ FPS with my old ATI RAGE 128 in such a mode on the other system. So, yes - I do think there are indeed some performance issues related to the openGL stuff. And I agree it's pretty disappointing to see the game @ 15 FPS on a system which usually provides up tp 80+ FPS in other games/openGL stuff. And I really don't think that FlightGear is making THAT much use of the GPU ?! Either it's really about some specific GPU options not being enabled or made full use of or there are some other _real_ problems ? Hence, it might really be a good idea to temporarily offer disabling of more advanced rendering features or even texture-rendering in general, personally I wouldn't care that much - and I agree with Erik, that most of the texture stuff gets pointless when you are IMC. - Boris ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Erik Hofman wrote:
Innis Cunningham wrote:
It is quite possible that the new graphics card/system is not set up for
FG.I will have a play with it and see if I can improve the situation.I
think
anisotropic filtering is on.
The point I was trying to make is people trying FG for the first time
will
be dissuaded from using it because of the poor performance.
As you yourself said it is disappointing to spend money on upgrading
only to find that the sim runs at the same speed if not slower.
With the price of computer hardware getting cheaper all the time I
would think most people who are going to use FG would have reasonably
new hardware.
Well, if we turn all that off, people start to complain that FlightGear
looks like crap and will search for something else. At least now they
start asking questions ...
Then how about optionally offering to disable such things in the
("advanced") rendering options dialog ?
-
Boris
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] problem on exiting ( was: Next release ofFlightGear )
Frederic Bouvier wrote:
> Jonathan Polley wrote:
>
> > Fred,
> >
> > It turns out that the problem should exist on every FlightGear
> > system, not just the Mac. On exit(), fgExitCleanup() is called which
> > deletes the globals class and then calls fgOSExit(). The only thing
> > that fgOSExit() does is turn around and call exit(), which repeats the
> > process. I changed fgExitCleanup() in main.cxx to be as follows:
> >
> > void fgExitCleanup() {
> > delete globals;
> > //fgOSExit(0);
> > }
> >
> > This prevented the recursive call to exit(), but will not work if
> > someone is using the fg_os_sld.cxx module, but it works for me.
>
> I was suspecting that but was not able to reproduce this behavior on
> windows.
>
> What about this instead :
>
> void fgExitCleanup() {
> if ( globals ) {
> delete globals;
> globals = 0;
> fgOSExit(0);
> }
> }
>
> It will allow to call the function twice safely. Can you test that.
And what about this that might be better.
-Fred
--- main.cxx 15 Jul 2004 18:07:03 - 1.170
+++ main.cxx 18 Jul 2004 12:38:52 -
@@ -1495,7 +1495,6 @@
// which happens in the sound manager destructor.
void fgExitCleanup() {
delete globals;
-fgOSExit(0);
}
--- util.cxx 16 Mar 2004 20:19:08 - 1.7
+++ util.cxx 18 Jul 2004 12:35:38 -
@@ -27,6 +27,7 @@
#include
+#include "fg_os.hxx"
#include "fg_io.hxx"
#include "fg_props.hxx"
#include "globals.hxx"
@@ -107,7 +108,7 @@
SG_LOG(SG_GENERAL, SG_INFO, "Exiting FlightGear with status " <<
status);
globals->get_io()->shutdown_all();
-exit(status);
+fgOSExit(status);
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] problem on exiting ( was: Next release of FlightGear )
Jonathan Polley wrote:
> Fred,
>
> It turns out that the problem should exist on every FlightGear
> system, not just the Mac. On exit(), fgExitCleanup() is called which
> deletes the globals class and then calls fgOSExit(). The only thing
> that fgOSExit() does is turn around and call exit(), which repeats the
> process. I changed fgExitCleanup() in main.cxx to be as follows:
>
> void fgExitCleanup() {
> delete globals;
> //fgOSExit(0);
> }
>
> This prevented the recursive call to exit(), but will not work if
> someone is using the fg_os_sld.cxx module, but it works for me.
I was suspecting that but was not able to reproduce this behavior on
windows.
What about this instead :
void fgExitCleanup() {
if ( globals ) {
delete globals;
globals = 0;
fgOSExit(0);
}
}
It will allow to call the function twice safely. Can you test that.
-Fred
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problems with compiling FlightGear-0.9.5-pre1
I'm new to flightgear, though I allways wanted to play it. Nearly the first thing I did on my new compu, was to try to compile FG. Unluckyly I ran into three problems. First one is with the file "src/FDM/JSBSim/FGJSBBase.h". It requires "numeric_limits" included for limits.h. This is only implemented in a newer version of stdc++, which I sadly don't have. So I would have to find out the smallest possible change of a double and float variable. The second problem is that the Makefile in src/Network would like to compile a jpg-httpd.cxx. I could remove that from that makefile and also the missing src/Network/jpg-httpd.hxx from the makefile in src/Main and it would compile, though I dont know if it would be missed later on. My last problem was a missing file fg_os.cxx in /src/Main. Again I tried to replace it with fg_os_sdl.cxx.From the name of that file I guessed that this would be a bad idead, as I would like opengl and not sdl. Thanks a lot, Stefan Yahoo! Companion - Scarica gratis la toolbar di Ricerca di Yahoo! http://companion.yahoo.it ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Innis Cunningham wrote: It is quite possible that the new graphics card/system is not set up for FG.I will have a play with it and see if I can improve the situation.I think anisotropic filtering is on. The point I was trying to make is people trying FG for the first time will be dissuaded from using it because of the poor performance. As you yourself said it is disappointing to spend money on upgrading only to find that the sim runs at the same speed if not slower. With the price of computer hardware getting cheaper all the time I would think most people who are going to use FG would have reasonably new hardware. Well, if we turn all that off, people start to complain that FlightGear looks like crap and will search for something else. At least now they start asking questions ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS - latest CVS summary - no news
Alex Perry wrote: I'd observe that it would be nice to turn _off_ texturing of the models, both the aircraft I'm sitting in and the AI aircraft around the airport, and turn _on_ texturing for the head up display (needed for PLIB fonts). That would make it much easier to fly with unaccelerated 3D drivers... Hmm, that might not be a bad idea. I'm not sure how easy it would be, but I guess that is should be possible since we had an option to turn off texturing for the terrain for quite some time. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next release of FlightGear
Ampere K. Hardraade wrote: Please tell me that you don't play FlightGear in wireframe mode. =P Neh, my O2 does support filled triangles. Just kidding. Oh. ;-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
