Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Thursday 15 June 2006 22:35: That's why I said I would copy the necessary files (all HUD related code) to Instrumentation/HUD and rename the class(es) and leave the old code to rust away. OK. Done that. For now I've decided to make it a regular subsystem that's registered by FGInstrumentMgr (instrumentmgr.cxx) like od_gauge and annunciator. The ::update() method is empty, and there's a method ::draw() that is called from the renderer right after the old fgCockpitUpdate. I think this is the best approach for supporting the old modes (2D 3D). Later I'd like to add render-to-texture HUD instruments in the way wxradar uses od_gauge, by subclassing from the HUD. Those will then not be updated via ::draw() method by the renderer, but via ::update(). Or something. First I need to make it work at all, though. :-) I'll commit the files as soon as the basic, old functionality is restored. The new HUD will be turned off, unless an aircraft asks for it. (And I will make them ask for it. :-) The new XML configs will, of course, not be fully backward compatible. Changes: loadfnfn\become property/path/to/somewhere... data_sourcefn / data_scale becomes scale too (both exist currently for the same thing in different HUD elements, which hinders abstraction) m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Melchior FRANZ wrote: data_scale becomes scale too (both exist currently for the same thing in different HUD elements, which hinders abstraction) It think it would be best to use offset and factor just like most of the other configurations (sound/animations). Great work, so far you've processed further than I ever did. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Friday 16 June 2006 09:34: Melchior FRANZ wrote: data_scale becomes scale too (both exist currently for the same thing in different HUD elements, which hinders abstraction) It think it would be best to use offset and factor just like most of the other configurations (sound/animations). Good point. Great work, so far you've processed further than I ever did. Oh, that's just because I'm stupid enough to do it. Not very smart. :-} BTW: I'd like to move Cockpit/hud_opts.hxx elsewhere. Don't know what the assembler parts do, but the fallback implies that it's a quick rounding function. Maybe simgear/math/fastmath.hxx? It has nothing to do with HUDs, but will be used by the old and new implementation, and could be useful for others. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Melchior FRANZ -- Friday 16 June 2006 09:41: BTW: I'd like to move Cockpit/hud_opts.hxx elsewhere. Don't know what the assembler parts do, but the fallback implies that it's a quick rounding function. Or is it not worth at all to be done in assember nowadays? m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Melchior FRANZ wrote: * Melchior FRANZ -- Friday 16 June 2006 09:41: BTW: I'd like to move Cockpit/hud_opts.hxx elsewhere. Don't know what the assembler parts do, but the fallback implies that it's a quick rounding function. Or is it not worth at all to be done in assember nowadays? I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
Jon S. Berndt wrote: ..another big deal to dig up: Downwash. There may end up being some things that don't get specifically addressed, but must be defined by the user with functions and tables. What I'd like most to do is to provide all the basic building blocks needed so that the user is free to create the model they'd like to create. Isn't downwash just a matter of a high angel-of-attack? Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
* Erik Hofman -- Friday 16 June 2006 09:51: I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) lrintf is c99 according to the man page, and so it roundf(). (int)rintf() then? m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Melchior FRANZ wrote: * Erik Hofman -- Friday 16 June 2006 09:51: I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) lrintf is c99 according to the man page, and so it roundf(). (int)rintf() then? Hmm, I doubt this will be faster than the ASM code. You know, just put the code in fastmath.[ch]xx and deal with it later. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
Curt wrote Vivian Meazza wrote: There is one - nearly - as I said orientation/heading-magnetic-deg. But it's not derived from an instrument, and therefore has no supply, neither can it fail, not does it have any error. Further, use of such a property will not stop, AFAIKS, the generation of spurious and unnecessary instruments, caused by incorrect initiation, and a hack to get around this. This looks unprofessional. As has always been the case, if the current instrumentation is not sufficient for your needs, you can always create a new instrument. /orientation/heading-magnetic-deg closely approximates an advanced inertial system you might find on an advanced modern aircraft. Reliable, trust worthy, dead on. You can also get true heading if you prefer that. If you need something that is tied to the electrical system, something that has various failure modes, something that models sensor error, or if you just don't like /orientation/heading-magnetic-deg for any other reason, then you'll need to consider modeling a new heading approximation system in nasal, or create a new instrument in C++ . There are some acronyms for these sorts of things, AHRS, IMU, INS. Your jet probably has some sort of ring laser based gyro system in real life? I don't know how deep you want to get into modeling this system. My goal is to stock the kitchen so all you cooks can create your culinary masterpieces. But if you want some new vegetable, you might need to plant it yourself. As I wrote in my original posting - that's already done - I've done a fluxgate compass suitable for use at least up to the '70s. I'll submit that for inclusion in CVS shortly. An even more modern instrument is trivial, but I haven't done one yet. I also have a patch prepared which prevents xmlauto.cxx from generating spurious instruments, and which uses whichever Heading Indicator that is present. That's probably a 'fancy waistcoat', and I'm still pondering if it's worth submitting. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Erik Hofman a écrit : Melchior FRANZ wrote: * Erik Hofman -- Friday 16 June 2006 09:51: I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) lrintf is c99 according to the man page, and so it roundf(). (int)rintf() then? Hmm, I doubt this will be faster than the ASM code. You know, just put the code in fastmath.[ch]xx and deal with it later. That will ease the port to MSVC. no C99 here. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
På 16.06.2006 10:19 CEST skrev Vivian Meazza [EMAIL PROTECTED] snip... I also have a patch prepared which prevents xmlauto.cxx from generating spurious instruments, and which uses whichever Heading Indicator that is present. That's probably a 'fancy waistcoat', and I'm still pondering if it's worth submitting. As you can see the helpers in xmlauto are hardcoded to the instruments that existed and were also hardcoded at the time. I think that these helper values should be moved into the instrument code that they belong to. For example the heading error should be moved into the heading indicator instrument code. This would result in the heading error only being available when the heading indicator instrument was present in the instrumentation configuration file. Some other helper values are IMHO redundant and should be removed all together (vertical speed conversion into feet/s). -- Roy Vegard Ovesen ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Autopilot Bug/Feature
Roy Vegard Ovesen wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:flightgear- [EMAIL PROTECTED] On Behalf Of Sent: 16 June 2006 10:26 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Autopilot Bug/Feature På 16.06.2006 10:19 CEST skrev Vivian Meazza [EMAIL PROTECTED] snip... I also have a patch prepared which prevents xmlauto.cxx from generating spurious instruments, and which uses whichever Heading Indicator that is present. That's probably a 'fancy waistcoat', and I'm still pondering if it's worth submitting. As you can see the helpers in xmlauto are hardcoded to the instruments that existed and were also hardcoded at the time. I think that these helper values should be moved into the instrument code that they belong to. For example the heading error should be moved into the heading indicator instrument code. This would result in the heading error only being available when the heading indicator instrument was present in the instrumentation configuration file. Some other helper values are IMHO redundant and should be removed all together (vertical speed conversion into feet/s). I was just thinking of calculating the error values in Nasal, but I personally prefer your suggestion. V. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
On Fri, 16 Jun 2006 09:54:39 +0200, Erik wrote in message [EMAIL PROTECTED]: Jon S. Berndt wrote: ..another big deal to dig up: Downwash. There may end up being some things that don't get specifically addressed, but must be defined by the user with functions and tables. What I'd like most to do is to provide all the basic building blocks needed so that the user is free to create the model they'd like to create. Isn't downwash just a matter of a high angel-of-attack? ..think downwash for a hovering chopper, to support its weight, it pushes down a similar mass of air, give and take some for manouvering, fixed wings just move in straighter lines. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
Isn't downwash just a matter of a high angel-of-attack? Erik When air passes over the wing, an incremental downward redirection is induced, so the horizontal tail sees a different airflow than the wing. Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
Jon S. Berndt wrote: Isn't downwash just a matter of a high angel-of-attack? When air passes over the wing, an incremental downward redirection is induced, so the horizontal tail sees a different airflow than the wing. Oh, downwash of the aircraft itself. I was thinking because of wind but I think that's called windshear? If I understand it correctly it should be possible to simulate the effects of downwash by creating a function of flap-settings and airspeed (and possible alpha), no? Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] simgear cvs compile errors with gcc 3.3.6
From talking to others on IRC I understand the cvs version of simgear builds fine with gcc 4, but with gcc 3.3.6 I get these compile errors added below. Is there a simple workaround for this? In file included from mat.cxx:44: ../../../simgear/structure/SGSharedPtr.hxx: In member function `void SGSharedPtrT::get(const T*) const [with T = SGMaterialGlyph]': ../../../simgear/structure/SGSharedPtr.hxx:51: instantiated from `SGSharedPtrT::SGSharedPtr(T*) [with T = SGMaterialGlyph]' mat.hxx:212: instantiated from here ../../../simgear/structure/SGSharedPtr.hxx:91: error: no matching function for call to `SGReferenced::get(const SGMaterialGlyph*)' ../../../simgear/structure/SGReferenced.hxx:41: error: candidates are: static unsigned int SGReferenced::get(const SGReferenced*) ../../../simgear/structure/SGSharedPtr.hxx: In member function `void SGSharedPtrT::put() [with T = SGMaterialGlyph]': ../../../simgear/structure/SGSharedPtr.hxx:58: instantiated from `SGSharedPtrT::~SGSharedPtr() [with T = SGMaterialGlyph]' mat.hxx:212: instantiated from here ../../../simgear/structure/SGSharedPtr.hxx:93: error: no matching function for call to `SGReferenced::put(SGMaterialGlyph*)' ../../../simgear/structure/SGReferenced.hxx:43: error: candidates are: static unsigned int SGReferenced::put(const SGReferenced*) ../../../simgear/structure/SGSharedPtr.hxx:93: warning: possible problem detected in invocation of delete operator: ../../../simgear/structure/SGSharedPtr.hxx:93: warning: invalid use of undefined type `struct SGMaterialGlyph' mat.hxx:55: warning: forward declaration of `struct SGMaterialGlyph' ../../../simgear/structure/SGSharedPtr.hxx:93: note: neither the destructor nor the class-specific operator delete will be called, even if they are declared when the class is defined. make[4]: *** [mat.o] Error 1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
Jon S. Berndt wrote: Isn't downwash just a matter of a high angel-of-attack? When air passes over the wing, an incremental downward redirection is induced, so the horizontal tail sees a different airflow than the wing. Oh, downwash of the aircraft itself. I was thinking because of wind but I think that's called windshear? If I understand it correctly it should be possible to simulate the effects of downwash by creating a function of flap-settings and airspeed (and possible alpha), no? Erik Maybe. I haven't thought about that much, yet. Try it. ;-) Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
Jon S. Berndt wrote: If I understand it correctly it should be possible to simulate the effects of downwash by creating a function of flap-settings and airspeed (and possible alpha), no? Maybe. I haven't thought about that much, yet. Try it. ;-) I did try something like this, but for prop-wash (over the vertical stabilizer) for the DHC-6 but at that time there was no easy way to get the engine output power. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Blender to ac3d material exporting
I have created a web page with minimalistic usage instruction about the way the ac3d Blender exporter plugin works with Blender material definitions. It can be usefull for newbees who do not like to struggle with all the unnecessary Blender material attributes. I guess that will help people not spending too much time with all those useless material attributes which will never be translated into the final .ac file format. The URL: http://www.geocities.com/robitabu/blender_ac3d_material_translation/blender.html cheers, Roberto -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender to ac3d material exporting
Roberto Inzerillo schrieb: I have created a web page with minimalistic usage instruction about the way the ac3d Blender exporter plugin works with Blender material definitions. It can be usefull for newbees who do not like to struggle with all the unnecessary Blender material attributes. I guess that will help people not spending too much time with all those useless material attributes which will never be translated into the final .ac file format. The URL: http://www.geocities.com/robitabu/blender_ac3d_material_translation/blender.html cheers, Roberto Thank you Roberto, this is very useful for me! Regards Georg EDDW ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender to ac3d material exporting
Roberto Inzerillo wrote : I have created a web page with minimalistic usage instruction about the way the ac3d Blender exporter plugin works with Blender material definitions. It can be usefull for newbees who do not like to struggle with all the unnecessary Blender material attributes. I guess that will help people not spending too much time with all those useless material attributes which will never be translated into the final .ac file format. The URL: http://www.geocities.com/robitabu/blender_ac3d_material_translation/blender.html Another tip : If you can find the file named ac3d_export.cfg ( on windows, in C:\Program Files\Blender Foundation\Blender\.blender\scripts\bpydata\config ) you can set MIRCOL_AS_EMIS to True ( default False ). Then, you can change the 3 components of the emis color by changing the Mir color. There are other setting that can be tweaked in this file. There use to be a dialog box for setting these parameters, but I can't find it in 2.41 -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aerobatics using flight gear and JSBSim
Did you get the Sukhoi ? If you want I can send you a slightly updated model... rgrds Enrique ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender to ac3d material exporting
Frederic Bouvier wrote: Another tip : If you can find the file named ac3d_export.cfg ( on windows, in C:\Program Files\Blender Foundation\Blender\.blender\scripts\bpydata\config ) you can set MIRCOL_AS_EMIS to True ( default False ). Then, you can change the 3 components of the emis color by changing the Mir color. There are other setting that can be tweaked in this file. There use to be a dialog box for setting these parameters, but I can't find it in 2.41 -Fred You are right Fred, I will add that note to the web page :-) This page was meant for newbees which do not mess with script files. Anyway, of course there is more to do with the ac3d export plugin, I think I will add something more to the page. Roberto ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender to ac3d material exporting
Roberto Inzerillo wrote: I have created a web page with minimalistic usage instruction about the way the ac3d Blender exporter plugin works with Blender material definitions. It can be usefull for newbees who do not like to struggle with all the unnecessary Blender material attributes. I guess that will help people not spending too much time with all those useless material attributes which will never be translated into the final .ac file format. The URL: http://www.geocities.com/robitabu/blender_ac3d_material_translation/blender.html cheers, Roberto Which is now linked to from wiki.flightgear.org. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
On Friday 16 June 2006 10:18, Erik Hofman wrote: Melchior FRANZ wrote: * Erik Hofman -- Friday 16 June 2006 09:51: I think it's best to use the default functions supplied by the system libraries (in this case lrintf() ? ) lrintf is c99 according to the man page, and so it roundf(). (int)rintf() then? Hmm, I doubt this will be faster than the ASM code. You know, just put the code in fastmath.[ch]xx and deal with it later. Well, I doubt that fastmath is useful these days anyway. I would never use these functions for serious computations, since I doubt that they will pass any IEEE test. Compilers do a pretty good job, selecting the right asm code for that stuff. Also I would trust libm and compilers much more in terms of accuracy, behavour in corner situations and even speed. For those few computations the fastmath functions are used now, I believe that you will not even notice a change in framerates if you compute the required results twice with the most expensive function you can find compared to the fastmath stuff. Also these fastmath implementations are not aliasing safe in any way. You can expect an optimizing compiler to completely missoptimize most of the fastmath functions. I would vote for removing that fastmath stuff completely and using standard ones. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear cvs compile errors with gcc 3.3.6
Hi,
On Friday 16 June 2006 14:30, Joacim Persson wrote:
From talking to others on IRC I understand the cvs version of simgear
builds
fine with gcc 4, but with gcc 3.3.6 I get these compile errors added below.
Is there a simple workaround for this?
Given the error message, I could imagine a that the attached patch helps.
Can you please tell me if that patch helps?
... I tested with gcc-4.1.1 and gcc-3.2.3 which are both happy with the actual
code. Can you help me testing with gcc-3.3.6?
:-/
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: simgear/scene/material/mat.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/material/mat.cxx,v
retrieving revision 1.29
diff -u -r1.29 mat.cxx
--- simgear/scene/material/mat.cxx 11 Jun 2006 13:30:59 - 1.29
+++ simgear/scene/material/mat.cxx 16 Jun 2006 22:38:18 -
@@ -317,6 +317,15 @@
}
}
+SGMaterialGlyph* SGMaterial::get_glyph (const string name) const
+{
+ mapstring, SGSharedPtrSGMaterialGlyph ::const_iterator it;
+ it = glyphs.find(name);
+ if (it == glyphs.end())
+return 0;
+
+ return it-second;
+}
Index: simgear/scene/material/mat.hxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/material/mat.hxx,v
retrieving revision 1.23
diff -u -r1.23 mat.hxx
--- simgear/scene/material/mat.hxx 11 Jun 2006 13:30:59 - 1.23
+++ simgear/scene/material/mat.hxx 16 Jun 2006 22:38:18 -
@@ -207,10 +207,7 @@
/**
* Return pointer to glyph class, or 0 if it doesn't exist.
*/
- SGMaterialGlyph * get_glyph (const string name) const {
-mapstring, SGSharedPtrSGMaterialGlyph ::const_iterator it = glyphs.find(name);
-return it != glyphs.end() ? it-second : 0;
- }
+ SGMaterialGlyph * get_glyph (const string name) const;
protected:
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear cvs compile errors with gcc 3.3.6
On Sat, 17 Jun 2006, Mathias Fröhlich wrote: Given the error message, I could imagine a that the attached patch helps. Can you please tell me if that patch helps? Compiled without a warning on mat.cxx now. (Was that all? Couldn't handle that method as inline?) ... I tested with gcc-4.1.1 and gcc-3.2.3 which are both happy with the actual code. Can you help me testing with gcc-3.3.6? :-/ Too lazy to upgrade gcc, so I guess that's unavoidable. ;) (3.3.6 is the gcc version on slackware 10.2)___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] simgear cvs compile errors with gcc 3.3.6
On Sat, 17 Jun 2006 01:11:27 +0200 (CEST), Joacim wrote in message [EMAIL PROTECTED]: On Sat, 17 Jun 2006, Mathias Fr�hlich wrote: Given the error message, I could imagine a that the attached patch helps. Can you please tell me if that patch helps? Compiled without a warning on mat.cxx now. (Was that all? Couldn't handle that method as inline?) ... I tested with gcc-4.1.1 and gcc-3.2.3 which are both happy with the actual code. Can you help me testing with gcc-3.3.6? :-/ Too lazy to upgrade gcc, so I guess that's unavoidable. ;) (3.3.6 is the gcc version on slackware 10.2) ..believe me, upgrading gcc et al is the easy way for lazy bums like you and me. Thanks to Frederic, Erik, Curtis, Martin, Anders, Olaf and above all Ralf for helping me get TerrorGear built. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Memory leak
Hello all, Is anyone else seeing a memory leak in current cvs? After using all my real ram fg starts gobbling through VM at about 1 mb every 5 seconds or so, even when flying around the same area. LeeE ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
