Re: [Flightgear-devel] FG version CVS: Bug in --config command line parameter handling and preferences.xml
George Patterson wrote : Hi all, I have found a bug in the parsing of the --config command line parameter. Starting Flightgear, I noticed that the menu bar is using the default(blue) menu bar rather than the alternative black one. Which indicated that my preferences.xml isn't being loaded, rendering options was reset to the default. Also probably related is when exiting from fgfs, the error Error creating directory: home/gpatterson/.fgfs. .fgfs is my home direxctor already exists with appropriate permissions. It looks like the leading slash is being dropped. Version: CVS command: fgfs --aircraft=b1900d I will send a strace if required. Does this patch improve things ? http://frbouvi.free.fr/flightsim/sg_path.patch -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG version CVS: Bug in --config command line parameter handling and preferences.xml
George Patterson wrote : On Sun, 2005-12-18 at 14:51 +0100, Frederic Bouvier wrote: George Patterson wrote : Hi all, I have found a bug in the parsing of the --config command line parameter. Starting Flightgear, I noticed that the menu bar is using the default(blue) menu bar rather than the alternative black one. Which indicated that my preferences.xml isn't being loaded, rendering options was reset to the default. Also probably related is when exiting from fgfs, the error Error creating directory: home/gpatterson/.fgfs. .fgfs is my home direxctor already exists with appropriate permissions. It looks like the leading slash is being dropped. Version: CVS command: fgfs --aircraft=b1900d I will send a strace if required. Does this patch improve things ? http://frbouvi.free.fr/flightsim/sg_path.patch -Fred Fred, I have applied the patch and rebuilt Simgear and Flightgear.. # patch sg_path.cxx sg_path.patch patching file sg_path.cxx Hunk #1 succeeded at 213 with fuzz 1. However, I am now getting this error instead (double slashes) Error creating directory: //home/gpatterson/.fgfs Why would Simgear be trying to create a directoy that already exists? Not sure you have the latest CVS. Your sg_path.cxx file should be revision 1.17. Is it the case ? Reload the patch as I made updates to remove the // at the beginning, and retrieve last version of the file from CVS so the patch will apply cleanly. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Options saving patches
Erik Hofman wrote : Stefan Seifert wrote: Also nice would be any review of the code :) and of course some info about how the chances are for inclusion. I must say I like the idea, but given it's current state (no windows support) I would like to postpone it until after FlightGear 1.0 is released. What is missing for windows ? There are a few small issues that I would like to see added (or to see changed) but that's nothing major; like the option to ignore this feature all together. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Options saving patches
Erik Hofman a écrit : Frederic Bouvier wrote: What is missing for windows ? Stefan Seifert wrote: Missing is support for Windows, where the directory should be like %PROFILE%/Application Data/FlightGear (or such). Also I don't know if Windows supports the mkdir function. Would be nice if someone could port. there is a mkdir function in windows. Well actually, there is a _mkdir function like this : #*ifdef* _MSC_VER ret = ( _mkdir( path_.c_str() ) == 0 ); #*else* ret = ( mkdir( path_.c_str(), 0755 ) == 0 ); #*endif* What's wrong in storing informations in %APPDATA%/flightgear.org just like fgrun and fgadmin ( they both use fltk for that ) ? Anyway, this is a minor effort. If you commit this patch, I will send you a windows port. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Proposal: New way to add commandline options
Erik Hofman a écrit : Hi, I was thinking, FlightGear is already able to handle way more options than advertised when running fgfs -h -v How would we all fell about minimizing the number of command line options in favor of the --prop:prop=value method and make sure all of them are explained in a document rather than the help message. As a temporary measure we could make sure the current options are still available, but not made public in the help message. How do you all feel about that? I don't see the real benefit of this naming change. I rather see the burden of changing fgrun. And there are options that are not reduced to a property assignment. Why not documenting current options in a text file ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] STL errors?
Quoting Jon S. Berndt :
In trying to rebuild FlightGear under Cygwin, I'm getting all sorts of
errors now when I get to compiling the older JSBSim code, beginning with
FGDeadband.cpp. There errors are these:
stl_deque.h:446: error: expected unqualified-id before '(' token
deque.tcc:699: error: expected unqualified-id before '(' token
streambuf.tcc:54: error: expected unqualified-id before '(' token
locale_facets.tcc:514:57: macro min requires 2 arguments, but only 1 given
istream.tcc:147: error: ISO C++ forbids comparison between pointer and
integer
...
Strange. Anyone else see things like this?
Do you have NOMINMAX defined and
#ifdef HAVE_CONFIG_H
#include config.h
#endif
at the beginning of every .cpp/.cxx file ?
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Mathias Fröhlich wrote : On Sonntag 27 November 2005 13:14, Frederic Bouvier wrote: Why not installing an X11 error handler to trap this instead of letting the default handler simply exiting ? Well, ist this possible? I was very excited about that idea, but found in the documentation that the error handler needs to call exit otherwise the calling function of the error handler will call exit past return of the error handler ... And what about a command line option, or a preferences.xml entry, that would disable the whole feature when the end user knows that there is a problem ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Win32 binary (Was: KLN89 GPS added )
There is a Win32 binary that include the KLN89 here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-win32-20051130.zip As always, it needs a matching base package ( same date ) that you can get via CVS. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Selon Ampere K. Hardraade:
On November 30, 2005 08:22 pm, Curtis L. Olson wrote:
Perhaps explain to them what our code is attempting to do, and then ask
if they know of a GLX supported way to do it.
I would do that if I can. However, I am not a programmer, and nothing in
RenderTexture.cpp makes any sense to me. :(
What exactly is our code attempting to do?
I won't look at the RenderTexture code. I'd rather do something like :
cvs -z4 -q diff -u bbcache.cxx (in directory
I:\FlightGear\cvs\SimGear\simgear\scene\sky\)
Index: bbcache.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky/bbcache.cxx,v
retrieving revision 1.7
diff -u -r1.7 bbcache.cxx
--- bbcache.cxx 5 Sep 2005 08:17:37 - 1.7
+++ bbcache.cxx 2 Dec 2005 06:58:29 -
@@ -122,7 +122,7 @@
// rt-Reset(rgba tex2D ctt);
// rt-Reset(rgba tex2D);
- if( rt-Initialize(256, 256, true) ) {
+ if( !problemOnRenderTexture rt-Initialize(256, 256, true) ) {
SG_LOG(SG_ALL, SG_INFO, bbcache:Initialize sucessfull);
if (rt-BeginCapture())
{
And at other location where RenderTexture is used.
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
[EMAIL PROTECTED] iso]$ /opt/fgfs/bin/fgfs opening file: /opt/fgfs/share/FlightGear/Navaids/carrier_nav.dat /opt/fgfs/share/FlightGear/Navaids/TACAN_freq.dat X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 40 Current serial number in output stream: 41 Why not installing an X11 error handler to trap this instead of letting the default handler simply exiting ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Selon Mathias Fröhlich [EMAIL PROTECTED]: On Sonntag 27 November 2005 13:14, Frederic Bouvier wrote: Why not installing an X11 error handler to trap this instead of letting the default handler simply exiting ? Well, ist this possible? I was very excited about that idea, but found in the documentation that the error handler needs to call exit otherwise the calling function of the error handler will call exit past return of the error handler ... This is true only if the error is a fatal I/O that would trigger the handler installed by XSetIOErrorHandler ( http://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSetIOErrorHandler.html ). This is not if the error triggers the handler installed by XSetErrorHandler ( http://tronche.com/gui/x/xlib/event-handling/protocol-errors/XSetErrorHandler.html ). -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Selon Timo Saarinen [EMAIL PROTECTED]: On Sun, 2005-11-27 at 13:14 +0100, Frederic Bouvier wrote: [EMAIL PROTECTED] iso]$ /opt/fgfs/bin/fgfs opening file: /opt/fgfs/share/FlightGear/Navaids/carrier_nav.dat /opt/fgfs/share/FlightGear/Navaids/TACAN_freq.dat X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 143 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 40 Current serial number in output stream: 41 Why not installing an X11 error handler to trap this instead of letting the default handler simply exiting ? How do I install an X11 error handler? This is completely new concept for me. Quick googling didn't help much. Is there a command line option or should I modify FlightGear source or even X11 source? A X11 error handler is a C/C++ function that is registered through the call of XSetErrorHandler or XSetIOErrorHandler functions. This is a developer task who needs to modify the existing SimGear code to do something that is not the default X11 behavior. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Quoting Erik Hofman : Hi, I might have solved the nasty RenderTexture bug for ATI cards in CVS. Anyone cares to test it? Erik, search the string '_vsnSG_LOG' in rendertexture.cpp -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Release of v0.9.9 source code
Selon Jon Stockill : Curtis L. Olson wrote: Hello everyone, FlightGear v0.9.9 is now final. The source code is propagating through to the mirrors. If you have built an 'official' binary version of FlightGear in the past, it would be great if you could build a binary for v0.9.9 as well. I'm going to make an 'official' v0.9.9 announcment in a day or two and I'd like to have precompiled binaries available for as many platforms as possible. The slackware package is now available at the usual place: http://flightgear.stockill.org.uk/ It currently *doesn't* contain fgrun, as I can't get a current cvs version to build, and the last release version was based on the older airport files, and therefore just aborts because it can't find its data. I just get the error below on the final link (have the requirements for fgrun changed since the last release?): g++ -g -O2 -L/usr/X11R6/lib -L/usr/lib -o fgrun wizard.o wizard_funcs.o advanced.o advanced_funcs.o AirportBrowser.o AirportTable.o Fl_Table.o Fl_Table_Row.o Fl_Plib.o Fl_Heading_Dial.o main.o io.o fgfsrc.o logwin.o settings.o util.o run_posix.o fgrun_pty.o -lsgprops -lsgxml -lsgmisc -lsgstructure -lsgdebug -lplibssg -lplibsg -lplibul -lfltk_gl -lfltk -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lm -lz -lutil main.o(.text+0x192): In function `main': /archive/Mirror/flightgear/FGRun-cvs/src/main.cxx:87: undefined reference to `Fl::lock()' Jon, you need to use fltk with multi-threading support. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] impending v0.9.9 release
Quoting Curtis L. Olson : Hi all, I would really like to get v0.9.9 out the door this week ... maybe committing to the final source code version on thursday or friday. However, I would like to give everyone the opportunity to mention any show stopping bugs that we should be concerned about. It's ok to report bugs, but at this point we really need people reporting *fixes*. The magic source code gods have this week off so we are going to have to fix all the bugs ourselves. :-) It is not a bug but I am trying to put the Objects/Terrain stuff in fgadmin. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] impending v0.9.9 release
Curtis L. Olson a écrit : Christian Mayer wrote: Great! Will there be a Windows binary prerelease to test it? Fred is the windows build guru. I believe he posts his latest builds someplace, although I haven't tracked the url lately. Might be able to find it if you search the archives, or maybe Fred will be willing to remind us again if he's still awake. ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-0.9.9-pre3-win32.zip -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC7.1 CVS Oct 25 - 2 compile errors
Quoting Geoff Air: Hi, My CVS update of Oct 25 pulled in lots of 'changed' files, and had two problems with the compiles. They were simple fixes ... SG/source - fastmath.cxx ... FG/source - tacan.cxx Geoff, I submitted these changes to Erik yesterday evening and he commited then few hours ago. You should cvs update again. -Fred BTW, according to your webpage, we are more or less neighbours now. I am several RER B station farther from Paris. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] cleanup of FlighGear and SimGear
Alex Romosan a écrit :
this change is okay. i am not sure what you mean by marking the
method to be const but if it's this:
inline const Point3D GetPos() const
that would mean it acts on a const object which is what we want anyway
(but not necessarily). so can we apply this patch as well:
Index: src/AIModel/AIBase.hxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/AIModel/AIBase.hxx,v
retrieving revision 1.43
diff -u -r1.43 AIBase.hxx
--- src/AIModel/AIBase.hxx 15 Oct 2005 14:55:51 - 1.43
+++ src/AIModel/AIBase.hxx 25 Oct 2005 17:15:33 -
@@ -108,7 +108,7 @@
FGAIBase();
virtual ~FGAIBase();
virtual void update(double dt);
-inline Point3D GetPos() { return(pos); }
+inline const Point3D GetPos() const { return(pos); }
enum object_type { otNull = 0, otAircraft, otShip, otCarrier, otBallistic,
otRocket, otStorm, otThermal, otStatic,
thanks.
btw, there are still some more cleanups i would like to do so get
ready for a second round (provided i manage to find some time soon).
I am not a big fan of functions that return pointers or references on
their current state. That leads to mysterious errors when the object
goes out of scope before the pointer or the reference. I think this kind
of optimisation is very dangerous and should be avoided IMO.
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: New joystick bindings XML file for WIngman Force 3D USB
Melchior FRANZ a écrit : Can you try this file? http://members.aon.at/mfranz/wingman-force-3d-usb.xml It uses the new methods, adds descriptions, fixes indentation etc. Maybe I swapped throttle and rudder. Didn't know which OS you are running fgfs on. If you insist in sending a new file, try to incorporate my changes. Melchior, the hat is also OS-specific. From Logitech/wingman-extreme-digital-3d.xml axis n=6 ! That is wrong but harmless, should be axis -- descView Direction/desc number unix4/unix mac4/mac windows6/windows /number ... axis descView Elevation/desc number unix5/unix mac5/mac windows7/windows /number ... It also use /sim/current-view/goal-pitch-offset-deg and /sim/current-view/goal-pitch-offset-deg instead of your /sim/current-view/axes/lat and /sim/current-view/axes/long. Which is best ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] contacting tower
Quoting Frank Olaf : I just tried the latest compiled snapshot at ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/ and everything work normally, so its only my own compilation that suffers from the problem :( They seemd to rely on different pthreadVC-nd.dlls. It has allways work for me with pthreadVC-nd.dll, but the snapshot required pthreadVC2-nd.dll, could this be the problem? I doubt it is related. I just migrate my own projects to a more recent pthread snapshot that induced the change in library name. The problem with non-repeating keys is certainly a problem with not current keyboard.xml. There was a change by Melchior after I reported a bug and the repeat behavior must be explicit now. Perhaps Melchior can comment as my memory is a bit short on this topic. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Cygwin - Compile errors
Quoting Vivian Meazza [EMAIL PROTECTED]: I wrote: Erik Hofman Vivian Meazza wrote: This mornings' cvs fails to compile here under Cygwin with the following error: MIDG-II.cxx: In function `uint32_t read_swab(char*, size_t, size_t)': MIDG-II.cxx:31: error: call of overloaded `ulEndianSwap(uint32_t*)' is ambiguous This should be fixed. Since I don't need MIDG-II, I've fixed it locally by removing MIDG- II.cxx from the makefile. What, again? :-) er ... as usual :-) Quickest way - and involves absolutely no thought. still problems with the accursed MIDG-II.cxx MIDG-II.cxx: In member function `bool MIDGTrack::load(const std::string)': MIDG-II.cxx:344: error: 'class SGFile' has no member named 'eof' MIDG-II.cxx: In function `int myread(SGIOChannel*, SGIOChannel*, char*, int)': MIDG-II.cxx:379: error: 'class SGFile' has no member named 'eof' MIDG-II.cxx: In member function `int MIDGTrack::next_message(SGIOChannel*, SGIOC hannel*, MIDGpos*, MIDGatt*)': MIDG-II.cxx:410: error: 'class SGFile' has no member named 'eof' Usual fix applied :-) Your SimGear doesn't seem up to date. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Cygwin - Compile errors
Quoting Vivian Meazza : Frederic Bouvier Your SimGear doesn't seem up to date. Well, I thought it was. Anyway I've updated SG again, and recompiled both it and FG - same error. Hmm ... you ought to be right ... and eof() is in SGFile.cxx, but it was before (I checked) Can't spare the time to investigate further: MIDG-II is chopped as usual. Multiple copies of SimGear then ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main renderer.cxx, 1.27, 1.28
Quoting Erik Hofman: Dave Culp wrote: This sounds more like HAA (height above airport) or HAT (height above touchdown). Height AGL should be the current height above the ground directly below the aircraft. Height AGL should change as the terrain below the aircraft changes. What would expect the HUD to display? I'm quite sure that the F-16 doesn't have a terrain database or an AGL radar. So the HUD is displaying the height for the last known QFE ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: (convert GMAX/MDL file) Flightgear-devel Digest, Vol 29, Issue 52
Steve Knoblock a écrit : The FS2000 model converted fine. You can find at the following links the converted model and texture file: http://www.spiderbark.com/fgfs/predator.ac http://www.spiderbark.com/fgfs/tblades.rgb By the time I recalled how to do the conversion I was done: There is a 3dconvert utility included with FlightGear that will read in the .mdl file and produce a .ac file (based on the extensions of the files named in the parameters e.g. 3dconvert filein.mdl fileout.ac). Then the indexed bmp file was loaded into gimp and converted to rgb (sgi) format. Finally I loaded the predator.ac into a text editor and did a global replace of the text tblades.bmp to tblades.rgb. BTW, the only textured portion of the model is the propellor disk, but since the aircraft are all white anyway...it looks fine. You could always add numbers. I have the Windows binary distribution. I do not see a 3dconvert utility. Is there somewhere I can get this? I have Gmax installed again and found my experimental aircraft model for MSFS and want to see if I can export it to FG as a MDL file. Thanks, ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/3dconvert-win32.zip -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS: data/Navaids TACAN_freq.dat.gz, NONE, 1.1
Selon Andy Ross [EMAIL PROTECTED]: Alex Romosan wrote: hmm, there seems to be a lot of junk in this file: Actually, this file is in fact a gzipped tar file containing a single TACAN_freq.txt file. Is that intended? Nevertheless, this file should be binary for us Windows users. In fact, it is (now ?), but carrier_nav.dat.gz isn't and is corrupted for me. reminder : cvs admin -kb carrier_nav.dat.gz -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS: data/Navaids TACAN_freq.dat.gz, NONE, 1.1
Erik Hofman a écrit : Frederic Bouvier wrote: Nevertheless, this file should be binary for us Windows users. In fact, it is (now ?), but carrier_nav.dat.gz isn't and is corrupted for me. reminder : cvs admin -kb carrier_nav.dat.gz It was added without the -kb flag but remembered it had to be so I issued the command prior to committing it. It looks like it doesn't work that way. It's fixed now. Yes, and you should have noticed the error message. cvs admin only works on files already in the repository, and a cvs added file is not before the first commit. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Another error: Building SimGear CVS under Cygwin
Quoting Erik Hofman: Georg Vollnhals wrote: But the bash and me get more and more friends :-) ) (not translated, I only changed the German expressions Zeichen = char Fehler = error) No need, I can read German (and understand it as well). In file included from /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/vector:72, from ../../simgear/math/sg_types.hxx:40, from ../../simgear/misc/sg_path.hxx:36, from ../../simgear/ephemeris/stardata.hxx:31, from ephemeris.hxx:45, from ephemeris.cxx:28: /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In member function `void std::vectorbool, _Alloc::_M_insert_range(std::_Bit_iterator, _ForwardIterator, _ForwardIterator, std::forward_iterator_tag)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:522: error: expected unqualified-id vor (-char /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h: In member function `void std::vectorbool, _Alloc::_M_fill_insert(std::_Bit_iterator, size_t, bool)': /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_bvector.h:823: error: expected unqualified-id vor (-char In file included from Ouch, this is a tough one. I've searched all over the place, but g++ 3.4.x seems not to accept one or more of the declarations in math/sg_types.h which is accepted by almost all other compilers. I have no clue which one it doesn't accept :-( Does it help to put #include vector *before* #include simgear/compiler.h in math/sg_types.hxx -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC build error
Selon bass pumped : On 9/22/05, Frederic Bouvier wrote: Selon bass pumped : Hi everyone, I tried to compile the latest version of flightgear today in MSVC 7. It compiled fine... but then I had problems when it tried linking. Any ideas on how to fix it would help. Thank you in advance. Start ouput Linking... LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library Don't use that option. Be sure you compiled all programs and libraries with the same 'Code Generation' options. /MT is fine if it is everywhere. You didn't use this sentence. See below. Thanks a lot for your suggestion. It helped and I managed to get rid of some of the linking errors. But I'm still stuck with another 74 errors I hope you will be able to help me locate and fixed. I've noticed the errors revolve around the gz function, the sgsoundmanager (which to me looks like an maybe an openal error??)... If you could take a quick look at the error output and point me in the right direction. Thank you very much. Start output Linking... LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification LIBCMTD.lib(dbgheap.obj) : error LNK2005: _malloc already defined in LIBCMT.lib(malloc.obj) It is clearly stated here that there is a conflict between C runtimes. LIBCMTD is used when 'Code Generation' C/C++ option is set to 'Debug Multithread (/MTd)' while LIBCMT is from 'Multithread (/MT)'. There is a suggestion to use /NODEFAULTLIB:library link option but it is a no-go and build unusable programs. You should have to hunt where you put /MTd and replace it to /MT because using a Debug version of FlightGear is the right way to have very poor framerate. new_gui.obj : error LNK2001: unresolved external symbol class puFont FONT_SANS_12B (?FONT_SANS_12B@@3VpuFont@@A) This symbol comes from PLIB's fnt.lib library. main.obj : error LNK2019: unresolved external symbol __imp__alListenerf referenced in function public: void __thiscall SGSoundMgr::set_volume(float) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]) Should come from OpenAL. SimGear.lib(zfstream.obj) : error LNK2019: unresolved external symbol _gzopen referenced in function public: class gzfilebuf * __thiscall gzfilebuf::open(char const *,int) ([EMAIL PROTECTED]@@[EMAIL PROTECTED]@Z) Comes from zlib.lib. There is a source tarball in SimGear/src-libs/ SimGear.lib(code.obj) : error LNK2019: unresolved external symbol _naUnlock referenced in function _naNewContext This is Nasal code in SimGear .\Debug/FlightGear.exe : fatal error LNK1120: 40 unresolved externals So, to summarize : 1. clear your Code Generation conflict issues 2. add fnt.lib to the solution, 3. add openal to the solution, 4. add zlib.lib to the solution, 5. add nasal files to the SimGear project 6. fly :) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC build error
Selon bass pumped : Hi everyone, I tried to compile the latest version of flightgear today in MSVC 7. It compiled fine... but then I had problems when it tried linking. Any ideas on how to fix it would help. Thank you in advance. Start ouput Linking... LINK : warning LNK4075: ignoring '/EDITANDCONTINUE' due to '/INCREMENTAL:NO' specification LINK : warning LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library Don't use that option. Be sure you compiled all programs and libraries with the same 'Code Generation' options. /MT is fine if it is everywhere. .\Debug/FlightGear.exe : fatal error LNK1120: 119 unresolved externals You have to add all the files containing the unresolved symbols in you solution in order to compile and link them to fgfs.exe For exemple, in the line : environment.obj : error LNK2019: unresolved external symbol public: bool __thiscall SGEnviro::get_turbulence_enable_state(void)const ([EMAIL PROTECTED]@@QBE_NXZ) referenced in function public: virtual double __thiscall FGEnvironment::get_turbulence_magnitude_norm(void)const ([EMAIL PROTECTED]@@UBENXZ) it is said that the SGEnviro class ( the name before :: ) is missing. A quick search in the source tree tells me that it is in simgear/environment/visual_enviro.cxx that has to be added in the simgear project file. Do that until you have no unresolved external. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear icon
Quoting Josh Babcock [EMAIL PROTECTED]: Josh Babcock wrote: I will go ahead and do a 32, 48, 64 and 128 px version of mine, though I have to say that the 48 px one looks great. Maybe it would be a better choice for the larger ones. Of course, there's nothing stopping us from including multiple options for icons. Josh Ta-Da! http://jrbabcock.home.comcast.net/flightgear/icons/index.html Josh Thanks Josh, I would use it for the next Win32 release -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear type mismatch on Solaris
Quoting Martin Spott : Now as Andy promised I could have another try on big-endian machines I decided to actually have one. But something is hindering me that wasn't there before: make[3]: Entering directory `/usr/local/src/SimGear/simgear/xml' g++ -mcpu=hypersparc -mtune=hypersparc -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../.. -I/opt/gnu/include -I/usr/local/include -I/opt/FlightGear/include -O3 -D_REENTRANT -c -o easyxml.o `test -f 'easyxml.cxx' || echo './'`easyxml.cxx In file included from easyxml.cxx:3: ../../simgear/compiler.h:473: error: conflicting declaration 'typedef signed char int8_t' /usr/include/sys/int_types.h:62: error: 'int8_t' has a previous declaration as `typedef char int8_t' ../../simgear/compiler.h:473: error: declaration of `typedef signed char int8_t' /usr/include/sys/int_types.h:62: error: conflicts with previous declaration `typedef char int8_t' ../../simgear/compiler.h:473: error: declaration of `typedef signed char int8_t' /usr/include/sys/int_types.h:62: error: conflicts with previous declaration `typedef char int8_t' ../../simgear/compiler.h:476: error: `__int64' does not name a type ../../simgear/compiler.h:480: error: `__int64' does not name a type Could the person who did the changes have a look at it and suggest what I could try to fix it ? lines 472 and after of simgear's compiler.h reads : 472 #if defined( _MSC_VER ) || defined(__MINGW32__) || defined(sun) 473 typedef signed char int8_t; 474 typedef signed short int16_t; 475 typedef signed int int32_t; 476 typedef signed __int64 int64_t; 477 typedef unsigned charuint8_t; 478 typedef unsigned short uint16_t; 479 typedef unsigned int uint32_t; 480 typedef unsigned __int64 uint64_t; 481 #endif You probably must refine the test in order to discard these statements that are already in another include file. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear icon
Arthur Wiebe a écrit : I am working on a new mac flightgear binary because of all the problems people have with the current release and want to use a better icon this time. Is there any official logo or something I should base it off? There is no official logo that fit in the 32x32 area imposed by Windows, but I like the one provided by Josh and grabbed it for the Win32 build http://jrbabcock.home.comcast.net/flightgear/scripts/flightgear.gif It is a 16x16 so I resize it ( Josh, if you have a better 32x32 version, I would be glad to use it instead ). There is a nice 48x48 here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Devel/fgfs-jims-icon.bmp, but unusable after downsizing. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
Andy Ross wrote: A J MacLeod wrote: Curtis L. Olson wrote: What would people think of abandoning our mailing lists and converting over to online/web-based forums? Personally, I very much prefer mailing lists. I can quite see the advantages of web-based forums, but I'm not convinced they outweigh the disadvantages. Ditto. Reading threaded mail with Thunderbird vs. with PHPbb or the like isn't even a fair comparison. It would be a very significant hardship for me to have to deal with web forums for flightgear stuff, and I'm not normally one to be a stubborn complainer. :) That said, I know I've seen gatewayed implementations that do both successfully. They have a registration-required, no-authorizing-stray-posts-necessary email interface for the clueful, and a more permissive environment for the browser jockeys. I'm not sure whether any of these are free software, but I'm sure someone's tried it... I am also in favor of a mailing list. If a forum is chosen, I would be happy to receive email with the content of the posts, not the AVsim style that just say once a day that there is something to read. Another aspect of the problem that wasn't brought yet. You would have to be sure that the software chosen is up-to-date with no security flaws. This summer, the forum at fr.flightgear.org has been hijacked because an exploit has been discovered, fixed and advertised just when the maintainer was off for a long time. The forum database was destroyed. ( http://forums.punbb.org/viewtopic.php?id=8553 ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Simgear
Selon Vance Souders : Has anyone tried compiling the latest simgear CVS code? The visual studio solution is looking for a bunch of source files in \scene\sky\clouds3d that seem to be missing. Is this just a case where the Visual Studio solution file is out of sync? The visual studio solutions ( for MSVC .NET ) are not in CVS and are out of sync every time a file is added to or removed from the repository. Subscribe to the flightgear-cvs and simgear-cvs list to follow the changes and modify your solutions or project files accordingly. The MSVC 6 project files are updated only before a release. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
Oliver Schroeder wrote : Andy is, of course, right. We should not send binary data over the wire and I think that using XDR for transmission is the way to go, as it will fix problems with endianess and platforms not using IEEE-format for floats/doubles. That way multiplayer mode will even work on a VAX ;) I will look into it next week. There is no native xdr implementation with MSVC. We should provide our own implementation if it is the way we want to go. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Quoting Oliver Schroeder : 1) out of reach The server receives position information of clients and thus should be able to calculate the distance of two given clients (measured in nautical miles, disregarding height) so it is able to decide if it has to send packets to a client or not. In case it is out of reach, i.e. all actions of client A do not affect anything for client B, the server can stop sending packets between those two clients. So it is possible for the server to handle hundrets of clients even though each client does only see a couple of them (at least if the clients are scattered around the world). So the question is: How can I easily calculate the distance and how many nautical miles are out of reach (thinking of e.g. radar systems) ? You can compute distance at an altitude using SimGear functions : #include simgear/math/sg_geodesy.hxx double az1, az2, distance; geo_inverse_wgs_84( altitude, lat_1, lon_1, lat_2, lon_2, az1, az2, distance ); distance = | (lon_1,lat_1), (lon_2,lat_2) | -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Couple of Windows-related questions
Quoting Drew : Hi, I'm wondering if there is a way to run FlightGear without the 'command prompt' window opening, or at least to have it minimized when it opens. Is there a way to do this? Also, I've looked for a 'borderless window' option in the OpenGL commands with no success. Is there a way to create a borderless window that *isn't* full-screen mode? Thanks for any help you can give. Do you mean for your own compiled version, or for the released win32 binary ? We found that hidding the console for the release may seems pretty but was highly unpractical when it comes to help users that are unable to see the errors messages printed on the console. So it was filed as a false good idea and now the console of fgfs is shared with the one of fgrun. If you want to do it in your own project, you just have to change a link option. Replace /subsystem:console by /subsystem:windows and relink -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Gerard Robin a écrit : noshadow.myobjectname or animationtypenoshadow are really the same. But I think Mathias is talking about the fact that some object parts were silently not casting shadows based on their name. Before the noshadow animation exist I was checking for names like 'disk' for example so a 'propeller.disk' was not casting shadows. But in the current cvs only the 'noshadow' name and the noshadow animation are used. Sorry for the confusion, I realize that I did not talk about this hidden 'feature'. Harald. I don't understand why that animation.xml does not work, i get no shadow on agl less than 150, it should not. Any idea? animation condition greater-than property/position/altitude-agl-ft/property value150/value /greater-than /condition typenoshadow/type object-nameLysander/object-name /animation Lysander is the whole Aircraft (group defined) Because the condition clause is not used by the *noshadow* kind of animation. The code in animation.cxx clearly show this. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Multiplayer crashes with unknown aircrafts, any solution?
Melchior FRANZ wrote: Some other idea? Will FGFS check/discard/revert_to_default network packets with not existing Aircraft identifications inside? I guess I fixed that in CVS. Haven't tested it, though. And I can't make binary packages ... Here is one : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-win32-20050715.zip As always, it may need an up-to-date ( I mean CVS ) base package. Just try it and report success or failure. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3dconvert.exe
Curtis L. Olson a écrit : Does anyone have a copy of 3dconvert.exe built for dos/windows that they can send me [offline]? I put a copy here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/3dconvert-win32.zip It needs glut32.dll to run. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
I noticed another artefact : http://frbouvi.free.fr/flightsim/moving-shadow.gif ( animated gif ) When moving toward the blue building, the shadow on the nearest building face is moving and it seems dependant on the viewer's position. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
The options to enable shadows are in the rendering dialog. Yep. But if I enable that option, I just get a overall darker scene. Just like Curt reports. The stencil test is always succeeding. Is there a possible interaction with the multi pass clouds. Or maybe there is no stencil buffer. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] commit checker
Quoting Melchior FRANZ: Here's a small shell script that can be used to check if files are good enough to be checked in: http://members.aon.at/mfranz/citest [1.2kb] Do you mean it is a script that could be put in CVS administrative files as commitinfo ? Head of CVSROOT/commitinfo : # The commitinfo file is used to control pre-commit checks. # The filter on the right is invoked with the repository and a list # of files to check. A non-zero exit of the filter program will # cause the commit to be aborted. # # The first entry on a line is a regular expression which is tested # against the directory that the change is being committed to, relative # to the $CVSROOT. For the first match that is found, then the remainder # of the line is the name of the filter to run. # # If the repository name does not match any of the regular expressions in this # file, the DEFAULT line is used, if it is specified. # # If the name ALL appears as a regular expression it is always used # in addition to the first matching regex or DEFAULT. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: commit checker
Quoting Melchior FRANZ: * Frederic Bouvier -- Friday 01 July 2005 14:18: Quoting Melchior FRANZ: http://members.aon.at/mfranz/citest [1.2kb] Do you mean it is a script that could be put in CVS administrative files as commitinfo ? No. It's for checking before committing. But one could do some of these checks with commitinfo (CRLF, compression). Or things like ACL on particular directories etc. (fgfs has no tradition of using any of the CVSROOT files, not even cvswrappers. syncmail.py for sending commit logs is the only exception.) No. It was hard to add the cvswrappers, but it is now in place. I am not complaining that .rgb files are not binary any more ;-) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] glut32.lib error on MSVC.net (7.0)
Quoting MICHAEL G KRIZANSKY [EMAIL PROTECTED]: I am trying to compile FG on MSVC.net (7.0) on a Windows platform. I have been sucessful through plib, simgear and now FG is providing me with a fatal LNK error 1104: cannot open file 'glut32.lib' . The 'glut32.lib' file exists in the C:\windows\system32 folder... Can anyone suggest a solution or path to examine. C:\windows\system32 is good for DLL, not lib files. Search for opengl32.lib ( not dll ) and put glut32.lib at the same place. Most likely in the C:\program files\Microsoft Visual Studio .NET tree. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Regarding buildings (was Shadows)
Ampere K. Hardraade wrote : On June 28, 2005 04:47 am, Frederic Bouvier wrote: On June 27, 2005 05:00 pm, Frederic Bouvier wrote: In the first, an oracle building cast its shadow on another one http://frbouvi.free.fr/flightsim/fgfs-shadow-1.jpg If I go forward a bit, the shadow disappear : http://frbouvi.free.fr/flightsim/fgfs-shadow-2.jpg Would it make sense to give the building a base (such as a parking lot) for future models? What do you mean ? http://ccrma.stanford.edu/~salauns/Oracle_building.jpg -Fred I mean the surroundings of the buildings within Oracle's property. Look a second time : http://fgfsdb.stockill.org/modeledit.php?id=150 ;-) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: SGPropertyNode::removeChildren()
Erik Hofman a écrit : Andy Ross wrote: Seriously: the removeChild() method is just buggy. It should never have cared about refcounting at all. Andy, I have to agree with Melchior here. If you call removeChild you have the intention that it will stay in the tree until refcount becomes zero and then it will be deleted. If you call removeChild() and it just detached from the tree (without cleaning it up at some point) you won't even be allowed to access it using the property tree, even after the first call to removeChild(). I am rather on Andy's line here. As I tried to explain to Melchior 'remove' doesn't mean 'destroy'. I think the only reason the tree wasn't actually deleted/destroyed when the reference returned by removeChild was deleted is that it was copied in the _removedChild vector before returning, hence incrementing the counter. If you don't care having aliases pointing to garbage ( something David was against ), you would just have to dump the _removedChild vector and, if the SGPropertyNode_ptr returned is not used, the tree should be destroyed. Two functions shouldn't be necessary. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: SGPropertyNode::removeChildren()
Erik Hofman a écrit : Melchior FRANZ wrote: * Frederic Bouvier -- Thursday 30 June 2005 08:51: I am rather on Andy's line here. As I tried to explain to Melchior 'remove' doesn't mean 'destroy'. We know. It was said a few times in this thread already. removeChild() just *pretended* to remove something, when it actually only detached it. Ok, since no one cares to describe the difference to me in Dutch or German, can we all agree on the following: Destroy: erase it's exsistance immidiately, no matter what (we don't even care about aliases pointing to nowhere) Remove: tell the library the node is of no use anymore, let the library decide if or when it should actually be erased from memory (it could also be called Delete, but it isn't.) Detach: make sure the node can't be referenced from the original tree anymore, it becomes it's own root node. Let the library decide of or when it should be erased from memory. At the time of implementing the functionality ( in may 2002, unfortunately the CVS repository was reset in September 2002 ), remove was meant as 'remove from tree' ( 'detach' in your proposed phraseology ) not 'remove from memory'. The smart pointer should have decided if the subtree removed from the tree should have been destroyed or not based on the reference counter. Because of the _removedChildren vector, no destroy was actually done. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SGPropertyNode::removeChildren()
Melchior FRANZ a écrit : * Frederic Bouvier -- Thursday 30 June 2005 15:34: For a reason : it is the job of SGPropertyNode_ptr destructor : [...] If the vector of children SGPropertyNode_ptr is properly cleared in the SGPropertyNode destructor, the whole tree should go away recursively. Meanwhile I know that, too. If only you had told me in one of the nine private messages about this issue. You didn't know it exactly any more, either? Well, nobody seems to have. Except probably David ... I am sorry about that, and please accept my apologies. I didn't get into the issue until you change the API, and I only understood you didn't get the idea until your last message. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: SGPropertyNode::removeChildren()
Melchior FRANZ wrote :
* Frederic Bouvier -- Thursday 30 June 2005 16:05:
Melchior FRANZ a écrit :
I am sorry about that, and please accept my apologies. I didn't get into
the issue until you change the API, and I only understood you didn't get
the idea until your last message.
Heh ... and I apologize to all for the false alarm and the needless
inconvenience, especially to Erik for dragging him into that and
(successfully :-) fooling him. I've learned a lot about the property
system now, maybe it'll at least pay in the future.
But reverting doesn't solve all problems (although I could again be wrong):
alias() and unalias() referenced pointers *without* increasing/decreasing
the refcounter. So they could lose their target and crash. I simply let
them call incrementRef/decrementRef on their target. This should then be
done with SGPropertyNode_ptr, too, right?
What about :
// The right kind of pointer...
union {
-SGPropertyNode * alias;
+SGPropertyNode_ptr alias;
SGRawValuebool * bool_val;
SGRawValueint * int_val;
I don't remember why it wasn't done that way at the first time.
And a removeChildren() (derived from the old removeChild(), not a clever
new design based on wrong assumptions :-) would also be handy.
Sure
And all callers of removeChild() should set keep to false. Only one
did so far. Mine didn't, because the documentation left me quite unclear
about why I would or would not want that.
I am not sure about the 'keep' thing. Is there any reason duplicating
the same thing. If you want to keep a subtree, hold the reference
yourself and don't destroy the returned SGPropertyNode_ptr, and dump
_removedChildren. I am afraid the alias feature is complicating the
whole design.
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Regarding buildings (was Shadows)
Quoting Ampere K. Hardraade [EMAIL PROTECTED]: On June 27, 2005 05:00 pm, Frederic Bouvier wrote: In the first, an oracle building cast its shadow on another one http://frbouvi.free.fr/flightsim/fgfs-shadow-1.jpg If I go forward a bit, the shadow disappear : http://frbouvi.free.fr/flightsim/fgfs-shadow-2.jpg Would it make sense to give the building a base (such as a parking lot) for future models? What do you mean ? http://ccrma.stanford.edu/~salauns/Oracle_building.jpg -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Regarding buildings (was Shadows)
Quoting Martin Spott : Frederic Bouvier wrote: What do you mean ? http://ccrma.stanford.edu/~salauns/Oracle_building.jpg Hey Frederic, you obviously forgot to model the basin in front of the buildings :-) I didn't lose the idea fgsd can do it one day ( I mean without addind other artefacts ). Is this a natural river in the background ? Look by yourself : http://terraserver.microsoft.com/image.aspx?T=4S=12Z=10X=706Y=5191W=3 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Harald JOHNSEN wrote :
Yes, I can see that. The markings on the Hunter are on
separate transparent object: these throw a shadow. It seems as
if I'm going to abandon that method if shadows are to be
usable with that model. Pity; it saves a huge amount of
artwork and texture.
Don't change your model for that. If it's not a problem to rename your
objects you can add
a 'noshadow' prefix to your markings, they won't caste shadow
('mydecal' = 'noshadow.mydecal').
That can makes object names a bit long. It seems to me that there are a
length limit on names in Blender.
-Fred
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Another nit picking : When an object ( say a building ) is culled because it is not in the view, its shadow is also culled even if it is in the view. 2 screen shots : In the first, an oracle building cast its shadow on another one http://frbouvi.free.fr/flightsim/fgfs-shadow-1.jpg If I go forward a bit, the shadow disappear : http://frbouvi.free.fr/flightsim/fgfs-shadow-2.jpg The FOV is exagerated because it is not easy to pause exactly when it happens, but you can clearly see the shadows poping in and out when you travel between buildings. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Vivian Meazza a écrit : I've just seen the new volumetric shadows. Brilliant!!! On a Nvidia gForce 5200, the frame rate hit is about 10 in external view (I can live with it) and no noticeable effect in internal - perhaps 1 or 2. Yes, it is very nice. I have a drop of 10 fps ( 50 - 40 ) when I enable all ( ac + ai + to ) There's a bit of a funny with the interaction between the Hurricane propeller disk and the ac shadow: it makes the shadow disappear, and there's something throwing a shadow on to the disk, which I've not seen in real life, although I might not have noticed it. Is there anything I can do within the ac model to tidy this up? 2 stranges things that I know are inherent to the shadow volume technique : 1. even when surfaces are smoothed, the shadows are hard and apply to a whole quad when a fuselage shadows itself ( try the A320, look at the airframe and press t to see what I mean ). 2. transparent surfaces ( the suspension chains of the bridges, or the metallic structures ) produce filled shadows. Let wait the hardware to catch up a hit, and we could have clouds and mountains casting shadows ;-) Good job again. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] cygwin simgear problem
There was a similar problem report not far ago. It seems cygwin switched
recently from gcc 3.3 to gcc 3.4.4, and that is the problem.
Vivian, what is your own version of gcc ?
-Fred
Vivian Meazza wrote :
tom bonnell
Not really, except to say that I’ve compiled the cvs version under
Cygwin successfully in the last couple of days.
Do you have a reasonably up-to-date version of Cygwin?
I take it that plib compiled correctly?
You might like to try the cvs version.
Vivian
In the make process of simgear 3.8 undercygwin I get these errors. can
you help?
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In
member functio
n `void std::vector_Tp,
_Alloc::_M_fill_insert(__gnu_cxx::__normal_iteratorty
pename _Alloc::pointer, std::vector_Tp, _Alloc , size_t, const _Tp)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:307:
error: expect
ed unqualified-id before '(' token
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc: In
member functio
n `void std::vector_Tp,
_Alloc::_M_range_insert(__gnu_cxx::__normal_iteratort
ypename _Alloc::pointer, std::vector_Tp, _Alloc , _ForwardIterator,
_ForwardI
terator, std::forward_iterator_tag)':
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/vector.tcc:384:
error: expect
ed unqualified-id before '(' token
make[3]: *** [ephemeris.o] Error 1
make[3]: Leaving directory `/cygdrive/c/simgear/simgear/ephemeris'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/cygdrive/c/simgear/simgear'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/cygdrive/c/simgear/simgear'
make: *** [all-recursive] Error 1
_
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Wrong coordinates with airport LICP?
You can check if fgsd is correct by importing a map that has both UTM33N and longitude/latitude markings. You calibrate the map with the UTM coordinate system, and then over the mouse on the main window to see if the reported latitude/longitude ( in the status bar ) are correct according to the second scale. I did that with a map of La Réunion french island in Indian Ocean and it worked well at that time. FGSD use functions that are extracted from a program call UTM2LL ( IIRC ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting an airport fixed
Quoting Gerard Robin : I have found something: Using taxidraw on LFPO (LFPO.btg file), i can export with TaxiDraw a file in X-plane format, i get LFPO.dat, which should give the same coordinates than the ones which the official apt.dat. -- IT IS NOT that explain the beside position of the Aircraft. Two possibilities: apt.dat is wrong -- we can modify it with a text editor LFPO.btg is wrong -- how may we modify it ? May be many others Airports have the same error. Thanks for the answer Do you have the scenery that was generated with that apt.dat. In other words, do you get the latest version of the scenery ? ( if you already have the latest version of apt.dat that is in CVS ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting an airport fixed
Quoting Gerard Robin : Using taxidraw on LFPO (LFPO.btg file), i can export with TaxiDraw a file in X-plane format, i get LFPO.dat, which should give the same coordinates than the ones which the official apt.dat. -- IT IS NOT Just curious : Taxidraw can read .btg files ? That's a big value as there is only raw triangles and fans in a .btg file, I am interested in knowing how it is possible to recreate runways and taxiways informations. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: msvc7.1 compiling problem
eagle monart wrote : thank you guys , finaly compiled the latest source : )) but still i am looking for the puffy clouds that i saw in devel mailing list. How can I enable puffy clouds??? . I played with layers types and also enable 3dclouds in fgrun but didnt succeed. It is in View Rendering options ( Flightgear menu, not fgrun's ) Also I everytime i compiled flightgear i see some rectangles on the ground and in the air..here are two screens http://s22.yousendit.com/d.aspx?id=3VSGYF2CMMS911EUK0QW4CFCSS http://s22.yousendit.com/d.aspx?id=0G451XWMBMCHN03PNCRTVFUWPA I am unable to see your images, sorry. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Le Bourget / Paris Air Show / Aero 2005
I had the chance to get a pass for Le Bourget 2005. Unfortunately, the only day I could go was a rainy day. Nevertheless, I took pictures that you can see here http://frbouvi.free.fr/photos/yappa-ng/index.php?album=Aviation%2FLeBourget2005%2F . Some may interest aircraft designers. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] msvc7.1 compiling problem
eagle monart wrote : I can succesfully compile fg.0.9.8 in release mod under msvc71 . Now I am trying to compile latest version of flightgear I . compiled latest version of simgear but in flightgear source i ve some errors first error was about config.h...compiler couldnt locate config.h and I dont understand which file it needs. I disable config.h and continue then I get gl.h errors. I didnt understand whats going on... i attach the log config.h is normally generated by the configure script. With msvc, we don't use it, so we must provide one manually tweaked. For that, copy FlightGear/src/Include/config.h-msvc6.in to config.h in the same directory, edit it and replace @VERSION@ by the current version number and tweak the options yourself. You can also look at ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/FG-ProjectFiles-msvc71.zip . There is the config.h I use. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shadows
Would the buildings cast shadows ? What about creating a new animation type that will specify objects ( branches ) that cast shadows and objects that do not ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: msvc7.1 compiling problem
eagle monart a crit : thanks for the config.h solution what about problems in gl.h ? C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1152) : error C2146: syntax error : missing ';' before identifier 'glAccum' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1152) : error C2182: 'APIENTRY' : illegal use of type 'void' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1153) : error C2144: syntax error : 'void' should be preceded by ';' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1153) : error C2501: 'WINGDIAPI' : missing storage-class or type specifiers C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1153) : error C2086: 'int WINGDIAPI' : redefinition C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1152) : see declaration of 'WINGDIAPI' __ Windows.h should always be included *before* any GL include file. There is a define somewhere : #define HAVE_WINDOWS_H 1 that condition this inclusion -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: msvc7.1 compiling problem
Frederic Bouvier a crit : eagle monart a crit : thanks for the config.h solution what about problems in gl.h ? C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1152) : error C2146: syntax error : missing ';' before identifier 'glAccum' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1152) : error C2182: 'APIENTRY' : illegal use of type 'void' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1153) : error C2144: syntax error : 'void' should be preceded by ';' C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1153) : error C2501: 'WINGDIAPI' : missing storage-class or type specifiers C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1153) : error C2086: 'int WINGDIAPI' : redefinition C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\gl\GL.h(1152) : see declaration of 'WINGDIAPI' __ Windows.h should always be included *before* any GL include file. There is a define somewhere : #define HAVE_WINDOWS_H 1 that condition this inclusion I think it is defined in my config.h . I also have HAVE_CONFIG_H defined in my project files. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RE: msvc7.1 compiling problem
Harald JOHNSEN a crit : But other files were added too in flightgear, you should check that all sources are included in the VC project. I've updated this file ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/FG-ProjectFiles-msvc71.zip that is ok for CVS. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] getting the best perfo with FG
BONNEVILLE David a crit : Hi people, I have a bi Xeon 3.2 GHz with 3.25 Go RAM and a NVidia Quadro FX 3000 on WinXP. Without any anysotropic and antialiasing, i get FG running 30 fps and sometimes 20 fps. Here are the option i use in my command line : --airport-id=LFMI --aircraft=ufo --control=mouse --enable-game-mode --enable-horizon-effect --geometry=1280x1024 --visibility=5 --bpp=32 that means i have also specular highlight and i don't have enhanced runway lighting. The FG version is the one Fred put on a webpage with the process splash screen. I had the same performances with the official 0.9.8 release. I am currently downloading the latest NVidia quadro driver for XP to check if it is the main cause. Do you have any idea, suggestion, to improve FG perfo ? Thanks This is the kind of framerate I have right now ( in fact I have numbers between 15 and 60 but average is 30 ) with my single Athlon 64 3400+, 1Gb -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: material animation and alpha channel
Selon Josh Babcock : This grouping thing keeps coming up. It is a real pain. I guess the chances of getting the plib people to fix it are about nil though. This has nothing to do with plib. It is the animation code ( in SimGear ) that reparent branches when several objects are put in the same animation element. It has its own benefits though. So I think people must be educated rather than removing this feature. Is it mentionned in the animation readme ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Jsbsim-devel] crash]
Sorry ,I probably, missed something but i have no access to CVS respective changelog entry, You can subscribe to the flightgear-cvslogs mailing list or check the archive here; http://baron.flightgear.org/pipermail/flightgear-cvslogs/ This one may interest you : http://baron.flightgear.org/pipermail/flightgear-cvslogs/2005-June/010209.html -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] poll
Dave Culp a écrit : This is a poll. Does anyone really want the FDM to allow flying under the terrain, or was that a misunderstanding by me? If nobody wants it then I think it should be disallowed. Fly under terrain : no Fly under bridges : yes Taxi under hangars : yes -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 2-sided surfaces in ac3d format
Curtis L. Olson wrote: Drew wrote: Thanks for the info. FWIW, it probably doesn't have to be that way. The shading 'math', as you put it, should already be a function of the observer's position, in which case some conditional logic might take care of that. I might try to find the code for this. In the meantime, I'll just draw two opposite single-sided surfaces. In opengl, lighting/shading is entirely dependent on the normal you define for each vertex. The orientation of the surface does not factor in. The orientation is used for backface culling, but that's something entirely different. Think about a terrain surface for instance, where the normal at any given point needs to be some average of the normals of the surrounding faces ... perhaps weighted by face size. If opengl decided to be smart and overrule what you've provided for a normal, you wouldn't have the level of control you need to do a lot of things. There are no normal defined in the AC3D file format. Normals are computed by the plib ac loader. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] visual studio optimization
tom bonnell a écrit : i am compiling FG under msvc7.1in debug mode with few performance warnings. however in release mode i get to many link errors. in debug mode the size of fgfs.exe is 5.8mb and causes very very slow loading. how can i optimize solution? Fix your Release mode linling stage. You should compile all libraries (plib, SimGear, pthreads, zlib, libjpeg,...) with the same set of options. Post an excerpt of your error listing. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Models/Airport beacon.xml, 1.8,
Melchior FRANZ a écrit : In less verbosity: this technique does only make sense for objects with high face *density*, not high face *number*. The beacon has a lot of vertical, or near vertical, faces. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Cygwin slowness
Andy Ross a écrit : // // VERY bad performance characteristics when linked against // cygwin.dll. Watch under strace, and note that every N reads, there // is an inexplicable delay of several milliseconds. Spinning in the // malloc implementation? The Debug build of MSVC has the exact same behavior : In that case, it is memory heap check that clobber performance, and not system related, but located in the C runtime library. Some numbers : it takes 5 seconds to load airport data in Release mode, and 25s ( 5x more ) in Debug mode. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Andy Ross wrote : Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? It halves the airport and nav loading time ( 9 - 5 s ) so the total loading time goes from 23s to 19s on my Athlon64 3400+ This is compiled with MSVC 7.1 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Oliver C. a crit : On Wednesday 25 May 2005 23:31, Frederic Bouvier wrote: Gerard ROBIN a crit : Wonderfull. You where using FGSD, does it mean you are working on windows. because on the linux side i could never make a compilation of that program. It is a long time ago i wondered to make sceneries of France in Provence. It is tricky but doable. Look at the release notes of version 0.3.0 on sourceforge ( click on the version in the file page ) BTW : Martin contributed an IRIX build -Fred What about offering static binary builds of FGSD for linux with everything included? This might increase the package size but is very easy to use. I found that there are more dynamic libraries under Linux than under Windows, and that they are distribution dependant. If you can compile something statically, I am ready to put it on sourceforge for download. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mountainous areas
Did you download this file in binary mode ? The basic windows ftp client is in ascii when started and corrupt binary files with line endings conversion. -Fred Corrubia, Stacie K wrote : I have been trying to build some scenery over some pretty mountainous areas in California (w117n35) using SRTM 1 arcsec data. I end up with some very strange looking scenery with HUGE cliffs. I wanted to compare the FG base scenery from the downloads but when I tried to unpack the data ended up with the following error: Under cygwin: gunzip w120n30.tgz | tar xvf - w120n30/ w120n30/w116n30/ w120n30/w116n30/1056256.btg.gz w120n30/w116n30/1056256.stg w120n30/w116n30/1056258.btg.gz tar: Skipping to next header tar: Archive contains obsolescent base-64 headers gunzip: stdin: invalid compressed data --format violated ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Quoting Roberto Inzerillo : C'è qualcuno che vuole contribuire a migliorare gli scenari del territorio italiano? Io mi stò divertendo con FGSD, i risultati li potete vedere all'indirizzo http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html . Anyone wants to help bringing a new feeling to visual flights over italian territory? I am having fun building the scenery around my town with FlightGear Scenery Designer; the results can be seen at http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html This is very impressive. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Roberto Inzerillo wrote : Von: Frederic Bouvier [EMAIL PROTECTED] Anyone wants to help bringing a new feeling to visual flights over italian territory? I am having fun building the scenery around my town with FlightGear Scenery Designer; the results can be seen at http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html This is very impressive. -Fred Fred is always very nice :-) Thx Roberto No kidding, you are the first to show a convincing scenery enhancement without using photo-scenery. Generic textures are not dead ;-) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Gerard ROBIN a crit : Le mercredi 25 mai 2005 20:56 +0200, Roberto Inzerillo a crit : Von: Frederic Bouvier [EMAIL PROTECTED] Anyone wants to help bringing a new feeling to visual flights over italian territory? I am having fun building the scenery around my town with FlightGear Scenery Designer; the results can be seen at http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html Wonderfull. You where using FGSD, does it mean you are working on windows. because on the linux side i could never make a compilation of that program. It is a long time ago i wondered to make sceneries of France in Provence. It is tricky but doable. Look at the release notes of version 0.3.0 on sourceforge ( click on the version in the file page ) BTW : Martin contributed an IRIX build -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Drew a écrit : FlightGear takes nearly a minute to start up from my Windows build, and I'm just wondering if there's an easy way to shorten this if I'm not using all of flightgear's features. Is there one particular task that takes particularly long? Do you use the Debug or the Release build ? MSVC 7.x adds a lot of debug code in memory management (assertion check, corrupted heap) that makes the Debug build **very** slow. The Release build, as in the official win32 releases, is way faster. Maybe 5x to 10x. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
It takes 23 seconds to start my build on an amd64 3400, 1Gb ram. -Fred Drew a écrit : I'm compiling a Release build. It takes me a bit under a minute to bring it up, which isn't as bad as the 5 minutes Vivian reported, but it's still longer than I'd like (and longer than I believe is necessary). I'll see what I can do about disabling navaids...that seems like it be a lot of help. I haven't found a property in preferences.xml or a command-line option for this, yet. Drew On 5/24/05, Frederic Bouvier [EMAIL PROTECTED] wrote: Drew a écrit : FlightGear takes nearly a minute to start up from my Windows build, and I'm just wondering if there's an easy way to shorten this if I'm not using all of flightgear's features. Is there one particular task that takes particularly long? Do you use the Debug or the Release build ? MSVC 7.x adds a lot of debug code in memory management (assertion check, corrupted heap) that makes the Debug build **very** slow. The Release build, as in the official win32 releases, is way faster. Maybe 5x to 10x. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Martin Spott wrote : In article [EMAIL PROTECTED] you wrote: The Release build, as in the official win32 releases, is way faster. Maybe 5x to 10x. BTW, Frederic, would you consider uploading a Win32 binary - to the 'well-known site' - that represents the current stae of development ? By popular demand ( sort of ;), I uploaded my current release build ( latest CVS ) here : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgfs-win32-20050524.zip It goes on top of a valid install, as it requires some dlls not provided here, after the usual backup, of course. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Drew a écrit : That's probably about right, but your computer is much more capable than mine (Intel Pentium M 1600 MHz laptop, 512 Megs of RAM). I just timed mine at 57 seconds. On 5/24/05, Frederic Bouvier wrote: It takes 23 seconds to start my build on an amd64 3400, 1Gb ram. Is it different under Linux ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Frederic Bouvier a écrit : It takes 23 seconds to start my build on an amd64 3400, 1Gb ram. 9 seconds to load airports and nav data, 5 seconds to init other subsystems, 9 seconds to load scenery objects. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Drew, The question was intended to the other Linux adopters, not you specifically. -Fred Drew a écrit : I don't know. I can't try it, though, because this is a work computer, and 'm not supposed to install Linux. On 5/24/05, Frederic Bouvier wrote: Drew a écrit : That's probably about right, but your computer is much more capable than mine (Intel Pentium M 1600 MHz laptop, 512 Megs of RAM). I just timed mine at 57 seconds. On 5/24/05, Frederic Bouvier wrote: It takes 23 seconds to start my build on an amd64 3400, 1Gb ram. Is it different under Linux ? -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Do you compile the last code ? Now the splash screen writes the current stage on screen and it is easier to know where time is spent. -Fred Drew a écrit : That's helpful...thanks. I just commented the call to FGNavDBInit, which shaved off about 10 seconds, so that's some good progress...I'll play with it some more to see what I can do. Thanks for all your help. On 5/24/05, Frederic Bouvier [EMAIL PROTECTED] wrote: Frederic Bouvier a écrit : It takes 23 seconds to start my build on an amd64 3400, 1Gb ram. 9 seconds to load airports and nav data, 5 seconds to init other subsystems, 9 seconds to load scenery objects. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Drew a écrit : Really? That's helpful. I wasn't able to get the CVS software to work last time I tried...it seems like that's a useful feature, so I think I'll try again. Get a taste of it by downloading the binary I posted earlier. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear startup time
Drew a écrit : Correction, that was pthreadVC-nd.dll As I said, you must install fgsetup-0.9.8a.exe before, and replace fgfs.exe -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
Selon Martin Spott [EMAIL PROTECTED]: Wesley Alden Pegden wrote: glxgears gives me 700fps (as good as it's ever given me), [...] With a working OpenGL/DRI setup you typically get far more than 1000 fps with 'glxgears'. Please run 'glxinfo' or 'gl-info' - whatever you have on your machine - and have a closer look at the OpenGL 'vendor', And there must be : direct rendering : yes -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: terrain elevation at a given position
Quoting Martin Spott [EMAIL PROTECTED]: Melchior FRANZ wrote: If I need elevation for the signs, I run fgfs solely for this purpose. Here it's easy: Just set /position/longitude-deg and /position/latitude-deg and wait until fgfs sets the appropriate /position/ground-elev-m for it.[1] It's not as much fun as it sounds, though: I know, my suggestions might sound a bit boring. Still I'm convinced that this might be a great job for a FlightGear apprentice developer. In private conversation Frederic Bouvier once suggestet to pick the appropriate FlightGear Scenery Designer sources and It shouldn't be too difficult. Just a matter of wrapping up the FGSD_TriangleObject class into a main function. The biggest problems would be to remove unwanted dependancies that this class drag, and to build a tile cache. That should be easier when the source overhaul will be finished. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] airports and scenery
BONNEVILLE David a écrit : Hi people, maybe my problem should be exposed in FG user list... I've installed from scratch the 0.9.8 win release. I've downloaded the tile e000n40 from FG scenery ftp and e000n40 airport package too. I've used fgadmin to install the scenery and i unpacked the aiports package in tha airports directory. When I start fgrun, it doesn't find the new airports ... I want to go to LFML (Marseille Provence), I've looked into my new directories, and I have this airport in the apt.dat.gz and LFML.gz in Airports/e000n40. Did I forget something ? You should Refresh the airport list in fgrun. There is a button for that. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Dialog problem
I didn't follow the property problem closely, so this may be related, but this is what I am getting today : http://frbouvi.free.fr/flightsim/fgfs-dialog.jpg I just wanted to display the rendering options a second time. First time was ok. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Simgear props dialogs
Andy Ross a écrit : Melchior FRANZ wrote: I've found the bug already. In dialog.cxx: // Remove automatically generated properties, so the layout looks // the same next time around. if(!userx) props-removeChild(x); if(!usery) props-removeChild(y); if(!userw) props-removeChild(width); if(!userh) props-removeChild(height); ... and then we happily continue to read from the just removed nodes. Come on! We can do better than that! :-) I'm confused, those properties are removed only if they did not exist originally (i.e., they were created by the layout process). That removal is important, because it is what allows us to have both user-defined absolute positioning and automatically generated layout. The properties are only removed, I believe, once the dialog is created and on the screen. They should not be read again until the dialog is displayed again (at which time they will be created again by the layout process). Is there another reader that I'm not aware of? Anyway, property nodes are reference-counted, and effective deletion is done only when counter comes back to zero. At least when SGPropertyNode_ptr is used. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Web site problems?
Ampere K. Hardraade a crit : Just an information: Linux + Mozilla no problem Konqueror has no problem either. Windows + firefox = no problem either. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Command Window
Curtis L. Olson wrote : Ben Morrison wrote: I have modified flight gear and I am getting an error that is printed to the command window but before I can read the error flightgear closes. Is there a way to keep flightgear from closing? If you start FG from a command shell (and bypass the graphical launcher) I believe the output will go to the command shell, which won't close when FG dies. That's how it used to work anyway, I'm not 100% sure about the current windows build. Perhaps Fred can make a suggestion here if I'm way off. Even when FG for windows dies, the output stay on screen because it shares its console with fgrun. This is true since 0.9.8. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
Quoting Paul Furber: On Tue, 2005-05-03 at 13:26 +0200, Melchior FRANZ wrote: * Paul Furber -- Tuesday 03 May 2005 12:50: it's just the Himalayas region which doesn't work. (doesn't work on 0.9.8 either) I'm running CVS versions from last night on amd64 Gentoo Linux. Any ideas? No. If you had posted a command line that exposes the problem, *hundreds* of fgfs developers would have tried to reproduce it, and maybe would have been able to reproduce it and to find a solution. But so ... *Smacks forehead* - ask smart questions idiot! Sorry about that - I'll be more informative in future :) Try adding --log-level=info for a possible hint, ./fgfs --lat=87 --long=28 --altitude=3 --log-level=info Classical numerical problem at tile boundary. Try that instead : ./fgfs --lat=87.0001 --long=28.0001 --altitude=3 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: AI weirdness
Melchior FRANZ wrote : * Durk Talsma -- Monday 02 May 2005 21:16: I don't know what point you're trying to make: either that there is such a big discrepancy between the number of files that are checked for their precence, and the fact that there are currently none in CVS, Well, checking for 5 files when we can probably only expect a few hundreds in the next ten years seems like a waste of performance. No big problem on Linux with normal file systems (apart from the needless noise in debugging runs). But I wouldn't be surprised if this is a problem on other operating systems, like Win95. (Or NFS?) I thought the alternative approach would be obvious. Instead of checking for the existence of 5 possible files just ask the system for actual files? I didn't see a problem yet, but if we can avoid a long startup time, it is better. Let me rephrase Melchior's suggestion : iterate on directories with plib's ulOpenDir and ulReadDir functions, possibly being recursive in the tree, and check if the name of the reported files are an existing ICAO code against the database already loaded in memory. Examples of directory scan are in fgadmin and in fgrun. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] visual smoothing of model in fgfs?
Indeed, the AC3D loader now honour the smoothing property of surfaces rather than applying a general, random smoothing strategy as it was in the past. You now have to reload your model in AC3D or Blender, and smooth surfaces as needed with the tools available in both modeler. -Fred Jeff Koppe wrote : Ahh... nevermind. I found the issue by looking at the f16.ac model. And for my fellow FGFS novices: Take a look at the SURF parameter in the .ac file. If it's SURF 0x00 the sufaces are faceted. SURF 0x10 will give you a smoother looking model. --jeff www.static-lift.net - Original Message - From: Jeff Koppe [EMAIL PROTECTED] To: flightgear-devel@flightgear.org Subject: [Flightgear-devel] visual smoothing of model in fgfs? Date: Sat, 30 Apr 2005 17:44:04 -0400 I'm working on my 2nd incarnation of a 1911 Wright EX for fgfs. All this after upgrading operating system, fgfs, etc, etc. Now, in fgfs my model seems to be much more faceted than I recall the first one (which, of course, I no longer have). I faintly recall seeing a discussion somewhere about smoothing parameters in .ac models and how it changed somewhere with a AC3D version change? And how the Blender .ac export script hadn't been updated? Or something along those lines... Can someone refresh my memory or point me in the right direction? So far I've not been able to locate anything in the dev or user lists. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: Eliminating jitter
Erik Hofman wrote : Melchior FRANZ wrote: * Erik Hofman -- Friday 29 April 2005 09:38: By teleporting I think Jim means selecting different airports across the world (one after another), i.e. KSFO, CYYR, EHAM, etc. Yes, probably. Works without the least problems. Ok, I tried it and liked it. Can we agree this should be committed? It compiles and works for me -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
