Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Jonathan Polley wrote:
On Thursday, March 21, 2002, at 03:37 AM, Erik Hofman wrote:
Jonathan Polley wrote:
After getting SimGear to build under MSVC 6.0 (thanks Christian), I moved
on to getting all of FlightGear to build. For some reason, MSVC does not like JSBSim
(over 1200 errors generated) but I had no problem under RH 7.1 (as usual). I expect
that everything is a snow ball started from the errors in FGPropertyManager.h.
The full build result file can be found at:
http://homepage.mac.com/eq_fidget/FG_Dox/FlightGear.html
It's just a matter of removing (*all*) the 'FGPropertyManager::' sections
within the class (or file).
Erik
When I do that, it complains about the multiple definitions of 'Tie.' When it starts
failing the compile, it is on the second, and subsequent, definitions of
'FGPropertyManager::Tie.'
When I comment out *ALL* instances of 'Tie' (however you want to define it), I still
get a major explosion which makes absolutely NO sense:
[snip]
You're right, it doesn't make any sense. Perhaps you commented out too
much?
Anyways, I've managed to compile a recent FlightGear JSBSim. The
problems I encountered seem to be that MSVC can not deduce which
overloaded member function to call:
Compiling...
FGAerodynamics.cpp
c:\src\flightgear\src\fdm\jsbsim\fgaerodynamics.cpp(229) : error C2661:
'Tie' : no overloaded function takes 4 parameters
Adding an ugly cast fixes the problem:
PropertyManager-Tie(forces/fbx-aero-lbs, this,1,
(double (FGAerodynamics::*)(int) const) FGAerodynamics::GetForces);
A similar cast is required on every pointer to member function that
takes an index, probably because there is a similar named member
function that takes no index:
class FGAerodynamics : public FGModel {
...
FGColumnVector3 GetForces(void) {return vForces;}
inline double GetForces(int n) const {return vForces(n);}
On that note, since we are taking a pointer to a member function, the
compiler must emit a function body. Thus the member function can't be
inline. This may help decide which functions to inline.
Cheers,
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Compiling...
FGAerodynamics.cpp
c:\src\flightgear\src\fdm\jsbsim\fgaerodynamics.cpp(229) : error C2661:
'Tie' : no overloaded function takes 4 parameters
Adding an ugly cast fixes the problem:
PropertyManager-Tie(forces/fbx-aero-lbs, this,1,
(double (FGAerodynamics::*)(int) const) FGAerodynamics::GetForces);
A similar cast is required on every pointer to member function that
takes an index, probably because there is a similar named member
function that takes no index:
class FGAerodynamics : public FGModel {
...
FGColumnVector3 GetForces(void) {return vForces;}
inline double GetForces(int n) const {return vForces(n);}
On that note, since we are taking a pointer to a member function, the
compiler must emit a function body. Thus the member function can't be
inline. This may help decide which functions to inline.
Cheers,
Bernie
Are we doing something unusual, or is MSVC requiring something it shouldn't?
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
On Sun, 2002-03-24 at 06:43, Jon Berndt wrote:
Compiling...
FGAerodynamics.cpp
c:\src\flightgear\src\fdm\jsbsim\fgaerodynamics.cpp(229) : error C2661:
'Tie' : no overloaded function takes 4 parameters
Adding an ugly cast fixes the problem:
PropertyManager-Tie(forces/fbx-aero-lbs, this,1,
(double (FGAerodynamics::*)(int) const) FGAerodynamics::GetForces);
A similar cast is required on every pointer to member function that
takes an index, probably because there is a similar named member
function that takes no index:
class FGAerodynamics : public FGModel {
...
FGColumnVector3 GetForces(void) {return vForces;}
inline double GetForces(int n) const {return vForces(n);}
On that note, since we are taking a pointer to a member function, the
compiler must emit a function body. Thus the member function can't be
inline. This may help decide which functions to inline.
Cheers,
Bernie
Are we doing something unusual, or is MSVC requiring something it shouldn't?
Aside from the point about the inlines, it seems like it should be just
fine. The overload is fair and legal.
Jon
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Jon Berndt writes: Are we doing something unusual, or is MSVC requiring something it shouldn't? The latter, I think, since the pointer type can be determined unambiguously from the method signature. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] minor nits
David Megginson writes: Curtis L. Olson writes: I'm noticing some feet/meter problems as well. I also noticed that --altitude= on the command line was giving me meters rather than feet. Could this be a side effect of the property manager overhaul? I'm not sure what else has changed recently that could be related. I think so -- I'm going to take a look at options.cxx right now. The altitude value seems to be in feet but it is saying it is meters also I notice that the autopilot readout in the HUD starts off in feet but changes to meters as soon as you adjust it - The heading hold seems to hold 5-10 degrees 'left' of the heading bug location. This also is recent addition. No, this has been a problem for at least six months. No, the problem has become 5-10 degrees worse in the past couple of days. Interesting. I've seen the problem consistently for quite a few months (the AP holds the DG about 10 deg off the heading bug). Yep this changed recently. It is almost as if the magnetic deviation is being added in twice ?? I haven't really checked into this though FWIW in all of the above I am comparing anything in the CVS after March 20 with what was there as of March 2, the last time I 'CVS up'ped a backup FGFS source tree HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
On Sunday, March 24, 2002, at 04:18 AM, Bernie Bright wrote: Jonathan Polley wrote: On Thursday, March 21, 2002, at 03:37 AM, Erik Hofman wrote: Jonathan Polley wrote: After getting SimGear to build under MSVC 6.0 (thanks Christian), I moved on to getting all of FlightGear to build. For some reason, MSVC does not like JSBSim (over 1200 errors generated) but I had no problem under RH 7.1 (as usual). I expect that everything is a snow ball started from the errors in FGPropertyManager.h. The full build result file can be found at: http://homepage.mac.com/eq_fidget/FG_Dox/FlightGear.html It's just a matter of removing (*all*) the 'FGPropertyManager::' sections within the class (or file). Erik When I do that, it complains about the multiple definitions of 'Tie.' When it starts failing the compile, it is on the second, and subsequent, definitions of 'FGPropertyManager::Tie.' When I comment out *ALL* instances of 'Tie' (however you want to define it), I still get a major explosion which makes absolutely NO sense: [snip] You're right, it doesn't make any sense. Perhaps you commented out too much? I probably did. I removed teh definitions rather than the removing the 'FGPropertyManager::' portion of the definitions. Anyways, I've managed to compile a recent FlightGear JSBSim. The problems I encountered seem to be that MSVC can not deduce which overloaded member function to call: Compiling... FGAerodynamics.cpp c:\src\flightgear\src\fdm\jsbsim\fgaerodynamics.cpp(229) : error C2661: 'Tie' : no overloaded function takes 4 parameters After Tony made his updates, I sent a post that told about the problems with the 'Tie' parameter counts: http://seneca.me.umn.edu/pipermail/flightgear-devel/2002-March/005703.html Adding an ugly cast fixes the problem: PropertyManager-Tie(forces/fbx-aero-lbs, this,1, (double (FGAerodynamics::*)(int) const) FGAerodynamics::GetForces); I'll roll that change into my copy until it gets made permanently. While we are on the subject of MSVC, were you able to link with the files from CVS? In addition to the new files, I had to modify some other parts to the .dsp file(s) to make a link. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
The bigger problem, I suspect, will be main memory (or maybe disk bandwidth). An impostor scheme is going to be really tile hungry -- constantly dragging tiles off of disk, rendering them into textures, and forgetting about them. I know a sim that does what Norman suggest and it does not seem to have problems with loading tiles, although it rerenders tiles all the time (about one tile per frame). You're no longer limited by texture memory here, However, one problem is that not all gfx cards can render into a texture, so you have to do some moving of textures, which in some instances is *very* slow. There is a factor of 1000 between different moves of the same texture on my GeForce 3, as you may easily see with the readily available benchmarks. I am still not 100% sure whether the problem (texture movement sometimes leads to stutter) is a bad implementation of the idea or a basic problem of the algorithm. One certainly has to spend some thought on texture ram management. I *think* the easiest idea - if you dont need the texture any more and need memory, throw it away and when the user views again in that direction, rerender it, is also the fastest algorithm. Rendering may be faster than moving textures between texture mem and main mem. Andy Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
Wolfram Kuss writes: The bigger problem, I suspect, will be main memory (or maybe disk bandwidth). An impostor scheme is going to be really tile hungry -- constantly dragging tiles off of disk, rendering them into textures, and forgetting about them. I know a sim that does what Norman suggest and it does not seem to have problems with loading tiles, although it rerenders tiles all the time (about one tile per frame). I misunderstood Norm's original suggestion, but I still see no major problem with using a simpler scheme like I suggested in an earlier posting: 1. At distance (a), replace the tile with a single quad (or two triangles) using the texture for the most common material on the tile -- these would be similar to our current ocean tiles. 2. At distance (b), replace the tile with a single quad (or two triangles) untextured and using the ambient colour for the most common material on the tile. This probably wouldn't be hard to implement using SSG, and wouldn't have any dependencies on hardware capabilities -- we could generate the two alternative tiles at tile load time as well as the main one, since they would be very small. I think that SSG already has LOD support of some kind, so we wouldn't have to do much at all. This approach would let us experiment with different distances and see if we need Norm's imposters as an intermediate layer. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Adding an ugly cast fixes the problem: PropertyManager-Tie(forces/fbx-aero-lbs, this,1, (double (FGAerodynamics::*)(int) const) FGAerodynamics::GetForces); I'll roll that change into my copy until it gets made permanently. While We'll do a little investigating, first. I want to understand why MSVC is having problems, first, when no other compiler appears to be complaining. We want to remain as cross-platform/cross-compiler compatible as possible, but as a matter of policy, I am extremely hesitant to make crutches in our code to fix a crippled compiler - if, indeed, it turns out to be a problem with MSVC. Do you have any explanatory backup for why MSVC isn't working with this? I know this sounds rude of me, but I hope you can see where I am coming from. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New Files
HI all I have temporarily placed three tarballs at my site http://www.vso.cape.com/~nhv/files/fgfs 1) fgfs_exe.tgz24-Mar-2002 14:41 1.6M Current MingW32 executable that includes my patches below This runs on Win2k no gaurantees on anything else :-) 2) nhv_032402.tgz 24-Mar-2002 14:4139k cockpit.cxx - minor tweaks for HUD hud.cxx -- tweak for elevator trim gague to be displayed on HUD main.cxx -- effectively removed fgReshape() from the Main loop model.cxx -- major matrix simplification viewer.cxx -- matrix simplification and a fix for keyboard TILT viewmgr.cxx -- simplifications Note I consider none of these to be in 'final form' and can help integrate them more cleanly if desired however what is there should be easily adaptable to what ever 'style' the maintainer desires if they choose to incorporate any of the above Except for the 2 viewer files which should be considered one patch the other files all stand on their own and can be individulally added 3) nhv_hud.tgz 24-Mar-2002 14:41 1k Huds / Instruments / Default / hudcard.xml Huds / Instruments / Minimal / hudcard.xml Implementation of elevator trim gauge on HUD and minor tweaks to various tick marks Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Jon Berndt writes: Adding an ugly cast fixes the problem: PropertyManager-Tie(forces/fbx-aero-lbs, this,1, (double (FGAerodynamics::*)(int) const) FGAerodynamics::GetForces); I'll roll that change into my copy until it gets made permanently. While We'll do a little investigating, first. I want to understand why MSVC is having problems, first, when no other compiler appears to be complaining. We want to remain as cross-platform/cross-compiler compatible as possible, but as a matter of policy, I am extremely hesitant to make crutches in our code to fix a crippled compiler - if, indeed, it turns out to be a problem with MSVC. Do you have any explanatory backup for why MSVC isn't working with this? Jon, I don't think there is a 'conforming' compiler yet, and MSVC6 is several years old and I wonder how well the then current gnu stdlib++ would have handled that construct :-)) That said I will agree that MSVC6 even with all the service packs is a 'little' behind most of the others in being able to handle some of the more 'arcane' bits of C++. There is STLPort however that should work just with just about any compiler even MSVC :-) http://www.stlport.org Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Jon Berndt wrote:
Adding an ugly cast fixes the problem:
PropertyManager-Tie(forces/fbx-aero-lbs, this,1,
(double (FGAerodynamics::*)(int) const) FGAerodynamics::GetForces);
I'll roll that change into my copy until it gets made permanently. While
We'll do a little investigating, first. I want to understand why MSVC is
having problems, first, when no other compiler appears to be complaining. We
want to remain as cross-platform/cross-compiler compatible as possible, but
as a matter of policy, I am extremely hesitant to make crutches in our code
to fix a crippled compiler - if, indeed, it turns out to be a problem with
MSVC. Do you have any explanatory backup for why MSVC isn't working with
this? I know this sounds rude of me, but I hope you can see where I am
coming from.
I'm not sure if it is actually a problem with MSVC or if other compilers
have different rules when it comes to taking the address of an
overloaded function. I have encountered this exact same problem before,
with even gcc requiring a cast to disambiguate pointers to overloaded
member functions. Note that the cast is portable, I've tested with gcc
2.95.3 at least.
The only explanation I can offer is that FGAerodynamics::GetForces is
ambiguous given the declaration
class FGAerodynamics : public FGModel {
FGColumnVector3 GetForces(void);
double GetForces(int n) const;
...
The cast is a hint to the compiler which of the two GetForces() member
functions we are taking the address of. I have no idea why MSVC can't
deduce the correct member while other compilers can but that is the
essence of the problem as I understand it.
Cheers,
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Norman Vine wrote: Jon, I don't think there is a 'conforming' compiler yet, and MSVC6 is several years old and I wonder how well the then current gnu stdlib++ would have handled that construct :-)) I believe Comeau is 99.9% conforming but it is not free. I also believe that MSVC7 is much much better, they are using boost (http://www.boost.org) as one of their conformance acceptance tests, as are the gcc 3 crew. That said I will agree that MSVC6 even with all the service packs is a 'little' behind most of the others in being able to handle some of the more 'arcane' bits of C++. There is STLPort however that should work just with just about any compiler even MSVC :-) True, however this particular problem is compiler related not library related for once. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Change of email address
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm posting this because a number of you have in the past privately emailed me, my new email address will be [EMAIL PROTECTED] Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8nkeKF2H7v0XOYBIRAsINAJ9sC5f3n5d2zXm3UH4/Vy2Y/QiLyQCcCDwA 6/NxpCi0z3IfYsucU/rwC9c= =Nnlk -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Adding an ugly cast fixes the problem: PropertyManager-Tie(forces/fbx-aero-lbs, this,1, (double (FGAerodynamics::*)(int) const) FGAerodynamics::GetForces); I'll roll that change into my copy until it gets made permanently. While We'll do a little investigating, first. I want to understand why MSVC is having problems, first, when no other compiler appears to be complaining. We want to remain as cross-platform/cross-compiler compatible as possible, but as a matter of policy, I am extremely hesitant to make crutches in our code to fix a crippled compiler - if, indeed, it turns out to be a problem with MSVC. Do you have any explanatory backup for why MSVC isn't working with this? I know this sounds rude of me, but I hope you can see where I am coming from. Jon I'm sending this from work, since I am filling some process documentation holes and need a break. I know that MSVC can be quite strict about what is consider to be 'valid' C. The one thing that struck me when you asked your question is that some compilers are very strict about matching parameter types. What would happen if the class that defines 'PropertyManager-Tie' did not take a 'const' as the last parameter? Since I am at work, I don't have access to CVS and can not give it a try. This behavior with 'const' is not new, but it is one that I keep forgetting. Other compilers (i.e., Rational Apex's C compiler) seen to take the approach that the parameter is 'close enough' and don't raise an error. Does specifying '--pedantic' on the gcc command line cause any other warnings? Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Files
Norm, Your viewer/model work looks great. I've been doing some major work in there myself the last few days and what you've done will fit in well. If it's ok with you, I'd like to merge them in with what I've got over the next couple days. Currently where I am at is I've removed a ton of junk and cleaned up the viewer class quite a bit. Also I've got the 3d cockpit so it looks real now and fixed a couple other minor glitches. So I might submit that tonight, or I can hold off and merge in these optimizations and submit in a day or two. What do folks think? Actually, on this matrix topic, been thinking about whether we should just build a few optimized routines (for 3x3 work) into simgear. It would be good to move all the custom matrix manipulators out to simgear (was it you that suggested this last week?) so that both the model and the viewer code can use them. My thinking now is that the viewer code needs to be only concerned with the view (ie the eyepoint and vector) and the model code needs to be it's own class with its own data. This is an issue that needs to be addressed for building multiple model instances. Best, Jim Norman Vine [EMAIL PROTECTED] said: HI all I have temporarily placed three tarballs at my site http://www.vso.cape.com/~nhv/files/fgfs 1) fgfs_exe.tgz24-Mar-2002 14:41 1.6M Current MingW32 executable that includes my patches below This runs on Win2k no gaurantees on anything else :-) 2) nhv_032402.tgz 24-Mar-2002 14:4139k cockpit.cxx - minor tweaks for HUD hud.cxx -- tweak for elevator trim gague to be displayed on HUD main.cxx -- effectively removed fgReshape() from the Main loop model.cxx -- major matrix simplification viewer.cxx -- matrix simplification and a fix for keyboard TILT viewmgr.cxx -- simplifications Note I consider none of these to be in 'final form' and can help integrate them more cleanly if desired however what is there should be easily adaptable to what ever 'style' the maintainer desires if they choose to incorporate any of the above Except for the 2 viewer files which should be considered one patch the other files all stand on their own and can be individulally added 3) nhv_hud.tgz 24-Mar-2002 14:41 1k Huds / Instruments / Default / hudcard.xml Huds / Instruments / Minimal / hudcard.xml Implementation of elevator trim gauge on HUD and minor tweaks to various tick marks Enjoy Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
from: [EMAIL PROTECTED] You aren't at Flight Dynamics division, are you? error. Does specifying '--pedantic' on the gcc command line cause any other warnings? Jonathan Polley If I try using the --pedantic option I get this: --- start -- g++ -I../ --pedantic -Wall -oFGDeadBand.o -c FGDeadBand.cpp g++ -I../ --pedantic -Wall -oFGFilter.o -c FGFilter.cpp FGFilter.cpp: In method `void FGFilter::Debug(int)': FGFilter.cpp:224: warning: use proper indentation FGFilter.cpp:224: warning: you are obviously a newbie; try Visual Basic g++ -I../ --pedantic -Wall -oFGGradient.o -c FGGradient.cpp g++ -I../ --pedantic -Wall -oFGSwitch.o -c FGSwitch.cpp g++ -I../ --pedantic -Wall -oFGFCSComponent.o -c FGFCSComponent.cpp FGFCSComponent.cpp: warning: you didn't use `itBias' what's the deal!? FGFCSComponent.cpp:91: warning: This code is nauseating me g++ -I../ --pedantic -Wall -oFGGain.o -c FGGain.cpp FGGain.cpp: In method `void FGGain::Debug(int)': FGGain.cpp: error: compiler getting sick ... cannot go on ... must . Internal combustion error --- end -- So, obviously something is wrong. Not only am I perplexed, I am offended and crushed. ;-) Actually, I tried the --pedantic option and got no additional errors. My gcc version is 2.95.3-5 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
On Sun, 2002-03-24 at 18:09, Jon Berndt wrote: from: [EMAIL PROTECTED] You aren't at Flight Dynamics division, are you? error. Does specifying '--pedantic' on the gcc command line cause any other warnings? Jonathan Polley If I try using the --pedantic option I get this: --- start -- g++ -I../ --pedantic -Wall -oFGDeadBand.o -c FGDeadBand.cpp g++ -I../ --pedantic -Wall -oFGFilter.o -c FGFilter.cpp FGFilter.cpp: In method `void FGFilter::Debug(int)': FGFilter.cpp:224: warning: use proper indentation FGFilter.cpp:224: warning: you are obviously a newbie; try Visual Basic g++ -I../ --pedantic -Wall -oFGGradient.o -c FGGradient.cpp g++ -I../ --pedantic -Wall -oFGSwitch.o -c FGSwitch.cpp g++ -I../ --pedantic -Wall -oFGFCSComponent.o -c FGFCSComponent.cpp FGFCSComponent.cpp: warning: you didn't use `itBias' what's the deal!? FGFCSComponent.cpp:91: warning: This code is nauseating me g++ -I../ --pedantic -Wall -oFGGain.o -c FGGain.cpp FGGain.cpp: In method `void FGGain::Debug(int)': FGGain.cpp: error: compiler getting sick ... cannot go on ... must . Internal combustion error --- end -- Are you sure you didn't use the --whine switch? So, obviously something is wrong. Not only am I perplexed, I am offended and crushed. ;-) Actually, I tried the --pedantic option and got no additional errors. My gcc version is 2.95.3-5 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New Files
Hi all I have temporarily placed a fourth tarball at my site in addition to the earlier 3 http://www.vso.cape.com/~nhv/files/fgfs 1) fgfs_exe.tgz24-Mar-2002 21:51 1.6M Current MingW32 executable that includes my patches below including the new Mouse code This runs on Win2k no gaurantees on anything else :-) 2) nhv_032402.tgz 24-Mar-2002 14:4139k cockpit.cxx hud.cxx main.cxx model.cxx viewer.cxx viewmgr.cxx 3) nhv_hud.tgz 24-Mar-2002 14:41 1k hud xml files implementing a elevator trim gauge 4) mouse_022402.tgz24-Mar-2002 21:3913k These files finish the job of removing the quat from the Mouse code Note not all of the features of the old mouse are reinstated yet but most of them are and I will work on the remaining ones gui_local.hxx gui_local.cxx gui.cxx mouse.cxx Makefile.am Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New Files
Jim Wilson writes: Actually, on this matrix topic, been thinking about whether we should just build a few optimized routines (for 3x3 work) into simgear. It would be good to move all the custom matrix manipulators out to simgear (was it you that suggested this last week?) so that both the model and the viewer code can use them. Since these routines only run once or twice per iteration of the loop They really don't have to be 'super optimized' and I think my method of handling them as 3x3 and just filling in the 4th row and column by 'inspection' is probably good enough. Where these routines help is that I 'know' somethings about each of the matrices ahead of time that I take advantage of that a general purpose 3x3 set of routines would not be able to do. That said I am all for separating the math from the properties interface as much as possible and I think that we could probably create a 'number crunching core' SimGear 'Viewer' that was passed only numbers from the FlightGear 'Viewer' that provided the properties Interface to FGFS This SimGear Viewer would make it easier for other programs to interface to the FGFS scenery esp if and when we move the tile manager code to SimGear Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] MicroSoft Visual C++ Deficiencies
FYI http://hammer.prohosting.com/~yotam/software/msviscxx/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MicroSoft Visual C++ Deficiencies
On Sunday, March 24, 2002, at 11:32 PM, Norman Vine wrote: FYI http://hammer.prohosting.com/~yotam/software/msviscxx/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel I think that will be added to chapter 150 of my book on Why I Love Using Microsoft Products. My guess is that we have something related to the Function Template Parameter problem. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New Files
Norman Vine [EMAIL PROTECTED] said: Since these routines only run once or twice per iteration of the loop They really don't have to be 'super optimized' and I think my method of handling them as 3x3 and just filling in the 4th row and column by 'inspection' is probably good enough. Yes that's what I was noticing. What I was speculating is that there might be a way to consolidate by either passing a Vec3 or Vec4 as a parameter, but to be honest I haven't taken the time to compare the details of the various matrix functions. Probably what your doing is most efficient! That said I am all for separating the math from the properties interface as much as possible and I think that we could probably create a 'number crunching core' SimGear 'Viewer' that was passed only numbers from the FlightGear 'Viewer' that provided the properties Interface to FGFS Makes sense. It might want to be called ViewMath or something like that. It's got to go somewhere so that models can maintain their own position and rotation data (I mean for the model body itself, not the animations that are already there). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
