Re: [Flightgear-devel] Minor nits
D Luff wrote: And now NaN (Not-a-Nit) :-) the new engine starting sounds are excellent. Great stuff whoever came up with those. (Erik?) Yep. Thanks! Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Jonathan Polley wrote: On Wednesday, March 20, 2002, at 06:00 PM, Christian Mayer wrote: Jonathan Polley wrote: MSVC 6.0 still whines about props.cxx C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not a member of 'std' C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol cannot be used in a using-declaration C:\SimGear\simgear\misc\props.cxx(801) : error C2065: 'sort' : undeclared identifier Dunno, but have you tried to add a SG_USING_NAMESPACE(std); above the SG_USING_STD(sort); ? If I replaced SG_USING_SD(sort) with SG_USING_NAMESPACE(std) it compiled just fine. I then found errors with FlightGear proper (but that is another email). Well, that's not the solution. Irix has the same kind of problems, and the best way is something like: #if !defined(MSVC) SG_USING_SD(sort) #endif Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: valgrind: a memory error detector for x86 GNU/Linux
* Curtis L. Olson -- Wednesday 20 March 2002 22:57: I tried running this once myself and got lost in piles of errors coming out of plib. Yeah, that's the fun thing. valgrind traces =all= (de)allocations and illegal memory access through all libraries. Doing so it already detected such bugs in some very basic libs (libc, XFree, ...). Fortunately, there's a suppression facility, so you can exclude known and less interesting bugs. It should be possible to disable the output of any plib bugs. (Not that these weren't worth to be fixed. ;-) I'm not sure what it is about plib that triggers these false positives, but perhaps if you don't free memory in the same block in which it's allocated you get a gripe? Don't know yet. It looks interesting, especially since you don't have to recompile your binary and every lib it links against (i.e. opengl, x11, stdc, etc.) to make it run. Yes. There are a lot of configuration options. You can, for example, let it ask you for every bug if it should attach gdb to it right now. Lots of other stuff. And being a heavily used debugging tool in the KDE project, there is a lot of development going on. m. -- Who can afford to do professional work for nothing? What hobbyist can put three man-years into programming, finding all bugs, documenting his product, and distribute it for free? -- Bill Gates (in the mid-1970s) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] c310 lawn dart
Jon Berndt [EMAIL PROTECTED] said: engines/engine[0]/rpm = 2700 engines/engine[1]/rpm = 2700 What was the RPM reading? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Jim Wilson Sent: Wednesday, March 20, 2002 10:44 PM To: [EMAIL PROTECTED] Subject: [Flightgear-devel] c310 lawn dart With the newly accessible JSBSim properties I was able to gleen this data when the c310 does its supersonic lawn dart thing. Not sure exactly what the numbers mean, but 30983 lbsft sounds like a lot in a light twin. fbx-prop-lbs = 40.363084 fby-prop-lbs = 0.00 fbz-prop-lbs = 0.00 l-prop-lbsft = -705.996426 m-pop-lbsft = -2431.916839 n-prop-lbsft = 30983.191141 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flaps not working in JSBSim
JSBSim is no longer setting the /surface-positions/flaps-norm property, so the flaps don't move in the animation and don't make a sound. The position is still set correctly in /controls/flaps, [...] There are still no flaps in JSBSim's c310. The lever is moving on the panel but there's no feedback, neither via aerodynamical behaviour nor via model animation, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Flaps not working in JSBSim
Is this with the most recent JSBSim? Tony made some changes related to properties and perhaps there is some tweaking to do. Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Martin Spott Sent: Thursday, March 21, 2002 5:30 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] Flaps not working in JSBSim JSBSim is no longer setting the /surface-positions/flaps-norm property, so the flaps don't move in the animation and don't make a sound. The position is still set correctly in /controls/flaps, [...] There are still no flaps in JSBSim's c310. The lever is moving on the panel but there's no feedback, neither via aerodynamical behaviour nor via model animation, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgReshape redux
I did some experimenting with fgReshape, adding a simple test at the start to return if the width, height, and panel visibility were unchanged, but saw no framerate improvement. Upon closer examination, the only OpenGL-related things in the function are glViewport( 0, (GLint)(height - view_h), (GLint)(width), (GLint)(view_h) ); and ssgSetFOV( globals-get_current_view()-get_h_fov(), globals-get_current_view()-get_v_fov() ); Does glViewport have any significant overhead? Don't we have to call it every frame anyway (I know the panel code does so). 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] inlining
Norman Vine writes:
In my (limited) tests, even inlining something like
void setFoo (double foo) { _foo = (foo 0 ? 0 : foo); }
slows things down.
Really ??
then try this both with and without optimization :-))
Ah, yes, but this is a tight loop. In my tests on props.hxx, the
inlined code came in the middle of a long code block. I didn't have
time to do a lot of rewriting, but even when I did something as simple
as
double x = 100 + jnk;
jnk = 1000 + test_junk(i);
double y = 50 / x;
jnk *= y;
the speed advantage of the inlined code was cut in half.
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] New SimGear does not Build Under MSVC 6.0
On Thursday, March 21, 2002, at 06:43 AM, David Megginson wrote: Jonathan Polley writes: MSVC 6.0 still whines about props.cxx C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not a member of 'std' C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol cannot be used in a using-declaration C:\SimGear\simgear\misc\props.cxx(801) : error C2065: 'sort' : undeclared identifier OK, first let's make sure that my code is correct ANSI C++ before we beat up on MSVC. Basically, I have this: #include algorithm SG_USING_STD(sort); which is equivalent to #include algorithm using std::sort; Is this correct? I think it is, but confirmation would be nice. If this is correct, then the next step is to add #ifdef's for MSVC (yech). I tried 'using std::sort' in place of 'SG_USING_STD(sort)' and got the same errors. Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
Norman Vine writes: However some code fragments run 100's or even 1000's of times per iteration and these fragments should be studied on an individual basis and not just automatically un-inlined because it is in 'vogue' :-) It's not a question of vogue. Currently, we start with an enormous amount of inlined code by default. I'm suggesting that we start with nothing (or almost nothing) inlined, then inline only what can be proven to help through profiling and timing tests -- uninlined until proven necessary, rather than inlined until proven unnecessary. This should make the executable smaller, compile times faster, headers more readable, and debuggers more useful, all as side-effects. 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] Bug with c310
Arnt Karlsen writes: ..belly landings should be a noisy prop bending affair, but you should not total the aircraft... unless its a B-17 and you forget to dump the ball turret. In any case, you should walk away from the wreck, possibly receiving a repair bill from the insurance guy. ;-) And angry letters from the grieving family of the tail gunner. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Minor nits
* David Megginson -- Thursday 21 March 2002 13:40: * D Luff: And a long standing one that I've never heard anyone else mention - I get other colours and textures bleeding through at the runway touchdown zones and numbers, when viewed at certain shallow angles. This happens on several varieties and combinations of Windows, processor and graphics card. [...] It's more likely with a card like the Voodoo3, but I've seen it rarely on my GeForce2Go. It happened on my Voodoo3, but after a driver/XFree update I've never seen this any more. So it's obviously a driver bug. AFAIK there have been V3 driver updates recently for Windows, too. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
David Megginson writes:
Norman Vine writes:
In my (limited) tests, even inlining something like
void setFoo (double foo) { _foo = (foo 0 ? 0 : foo); }
slows things down.
Really ??
then try this both with and without optimization :-))
Ah, yes, but this is a tight loop.
Ah, good, you have a HINT at which inlines to leave alone :-
Cheers
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault on mini-panels
Jim Wilson writes: Here's a backtrace on this. I've just checked in some minor fixes to props.cxx in SimGear, and swapping panels (with 's') in FlightGear is working again. Thanks. By the way, we need to get rid of the panel_2 property; instead, we should have panel[0], panel[1], panel[2], etc. and allow 's' to cycle through the whole list. 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] Flaps not working in JSBSim
Is this with the most recent JSBSim? Tony made some changes related to properties and perhaps there is some tweaking to do. The checkout is about five hours old, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
David Megginson [EMAIL PROTECTED] said: I'm suggesting that we start with nothing (or almost nothing) inlined, then inline only what can be proven to help through profiling and timing tests -- uninlined until proven necessary, rather than inlined until proven unnecessary. This Sounds like a good plan. Not sure if we will see a big improvement on build times though. I would think a lot depends on how frequently a given inline is used. In any case, I've been slowly taking them out of the viewer code :::duck::: and haven't noticed any un-aided human detectible change. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault on mini-panels
David Megginson [EMAIL PROTECTED] said: Jim Wilson writes: Here's a backtrace on this. I've just checked in some minor fixes to props.cxx in SimGear, and swapping panels (with 's') in FlightGear is working again. Thanks. By the way, we need to get rid of the panel_2 property; instead, we should have panel[0], panel[1], panel[2], etc. and allow 's' to cycle through the whole list. Is there a method for rotating through a list in the xml? When I first set that up there wasn't any...so it just does a swap from panel2/path to the panel/path. Panel[2] might not be correct. Perhaps we should have a panel- current-idx property that defines which branch is active. This might be a useful thing to do with views as well. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
On Wed 20. March 2002 18:54, you wrote: Erik Hofman wrote: While I don't see a direct improvement in framerate I notice a real effect on the screen update. The old behaviour had a small bump in the update every second or so, while the new code elliminates that. This doesn't make much sense. All of the changes in that patch were inside the per-frame loop. They certainly couldn't cause or fix stutter over many frames, nor do I think have they been claimed to. Perhaps something happened in the tile loader to do this? Permanent window resizing can make strange artifacts and force to render frame again. If you still resize to the same dimension it is only optimalization to not make anything and some other implementation of OpenGL can make something. This is rapidly getting on towards voodoo coding, and I think perhaps we should step back a bit. What, exactly, are the changes in this patch that make it worthwhile? What does it eliminate? What is the evidence for speedup? BTW. This is probably only noticable on slower machines with a slow OpenGL implementation like the O2 I work on. The patch didn't touch any OpenGL code so far as I can tell, so I'm at a loss to explain this one, too. If glViewport() isn't OpenGL code then I don't know what is. Why are you all so definsive about deleting of code which isn't usefull for anything. IMHO when you can delete code which run every frame and replace it with code which run only at some special case then it is right to delete this code. Regards, Madr - Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
On Thu 21. March 2002 13:38, you wrote: D Luff writes: With Norman's main, maximising the window and then returning it to 800x600 leaves the external view of the plane (and probably the scenery but its hard to tell) all scrunched up. I think that we should pass on this patch for now -- I have no clear explanation of how it might help the framerate, and I cannot imagine that skipping a single glViewport call could make any difference. It also removes some existing functionality (such as resizing the view with the panel) and provides no measurable framerate change for most users. But makes 10% atleast for Norm. Did someone else tryed it under win in gamemode? Madr ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DC-3 Info
Hi All So I spent a day with three of the pilots at the SAAF Museum, talking about the DC-3 the whole day long. This is our (actually their) conclusion : 2 of the 3 are avid MSFS pilots in conjunction with their daily jobs of flying DC-3's and DC-4's. According to them, that massive DC-3 package for MSFS accurately (80%) of the aircraft's flying qualities. To minimize confusion, I'll email the .air file to everyone who's interested. They say that any more things to be added to that, is the fancy quirks of the Dak, eg : On startup, one does not just engage the starter. It has an inertia starter, which means the starter has to be "wound up", before it is engaged. Because it is a radial, it's very temperamental about taxiing the aircraft. The groundcrew has an endless battle with the pilots about taxiing procedures. One does not taxi the aircraft with rich texture, as at these low power settings a too-rich mixture actually clogs up the spark plugs, causing the engines to cough up smoke, flames out the engines and then the engine will stall after a few seconds. Landing gear retraction is quite complicated, and I'm still a little unsure about the whole process. When the landing gear is retracted, you first pull a lever to pull out a locking pin, and then the handle to raise the gear. Failure to do so will cause the gear to get stuck in the middle, and it won't budge, neither up nor down. I'm so glad I could make someone's day. They spent a good few minutes laughing at me when I asked for info on the lift coefficients etc. They said it's easier to get the pope pregnant. I'll be supplied with the performance graphs and other info only after the 13th of April unfortunately, as they are being used for the annual maintenance check on the aircraft. They have to get it done before the 13th, as it's a museum airshow then. I will be able to get the basic info for you on Saturday, things like basic operating speeds. Just so you know, we have a Douglas DC-3A-1dk. It operates with the Pratt Whitney R-1830 motors, but this one is specially modified to have the two-stage supercharger. Oh, they also asked that you incorporate accurate superchargers into the model as well I hope this helps a bit, and the pilots volunteered to do flighttesting for us, so, once you're finished and would like to have it tested, send it to me and I'll have it done for you. Regards Danie Heath Web Integrator RisC Com cc +27 12 654-5100 083 412 6904 [EMAIL PROTECTED]
Re: [Flightgear-devel] fgReshape redux
David Megginson wrote: Does glViewport have any significant overhead? Don't we have to call it every frame anyway (I know the panel code does so). No. It just sets scaling factors to turn the [-1:1] square produced by the projection matrix into screen coordinates.. On cards with hardware geometry processing, it requires a round trip on the AGP bus and probably flushes the vertex pipeline. Still, once per frame is just noise. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
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:
Compiling...
FGAerodynamics.cpp
c:\flightgear\src\fdm\jsbsim\fgmodel.h(67) : error C2059: syntax error : 'namespace'
c:\flightgear\src\fdm\jsbsim\fgmodel.h(67) : error C2238: unexpected token(s) preceding ';'
c:\program files\microsoft visual studio\vc98\include\fstream(15) : error C2059: syntax error : 'namespace'
c:\program files\microsoft visual studio\vc98\include\fstream(15) : error C2334: unexpected token(s) preceding '{'; skipping apparent function body
c:\flightgear\src\fdm\jsbsim\fgconfigfile.h(46) : error C2886: 'std::string' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgconfigfile.h(48) : error C2886: 'std::ostream' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgconfigfile.h(49) : error C2886: 'std::istream' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgconfigfile.h(50) : error C2886: 'std::ifstream' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgconfigfile.h(51) : error C2886: 'std::cerr' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgconfigfile.h(52) : error C2886: 'std::endl' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgconfigfile.h(53) : error C2886: 'std::ios' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgconfigfile.h(54) : error C2886: 'std::cout' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgmatrix33.h(30) : error C2886: 'std::string' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgmatrix33.h(32) : error C2886: 'std::ostream' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgmatrix33.h(33) : error C2886: 'std::istream' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgmatrix33.h(34) : error C2886: 'std::cerr' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgmatrix33.h(35) : error C2886: 'std::cout' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgmatrix33.h(36) : error C2886: 'std::endl' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgcolumnvector3.h(28) : error C2886: 'std::string' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgcolumnvector3.h(30) : error C2886: 'std::ostream' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgcolumnvector3.h(31) : error C2886: 'std::istream' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgcolumnvector3.h(32) : error C2886: 'std::cerr' : symbol cannot be used in a member using-declaration
c:\flightgear\src\fdm\jsbsim\fgcolumnvector3.h(33) : error C2886: 'std::cout' : symbol cannot be used in a member using-declaration
Jonathan Polley
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
The only way I can get SimGear to build is to replace SG_USING_STD(sort); with SG_USING_NAMESPACE(std); Nothing else seems to work. I have tried cleaning and rebuilding from scratch *multiple* times. Jonathan Polley On Thursday, March 21, 2002, at 06:43 AM, David Megginson wrote: Jonathan Polley writes: MSVC 6.0 still whines about props.cxx C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not a member of 'std' C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol cannot be used in a using-declaration C:\SimGear\simgear\misc\props.cxx(801) : error C2065: 'sort' : undeclared identifier OK, first let's make sure that my code is correct ANSI C++ before we beat up on MSVC. Basically, I have this: #include algorithm SG_USING_STD(sort); which is equivalent to #include algorithm using std::sort; Is this correct? I think it is, but confirmation would be nice. If this is correct, then the next step is to add #ifdef's for MSVC (yech). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
The only way I can get SimGear to build is to replace SG_USING_STD(sort); with SG_USING_NAMESPACE(std); Nothing else seems to work. I have tried cleaning and rebuilding from scratch *multiple* times. Are there any other stdlib function calls in there from std namespace? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] (no subject)
Here it is John. Description: Wilson's new u3a panel. It's not very accurate. Haven't found a picture yet. The shape and layout is fairly close and looks ok. Also linked to c310 default sound.xml and changed model so the props aren't so syncrhonous to look weird. File: http://www.spiderbark.com/fgfs/c310u3a-update-20020321.tar.gz Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
On Thursday, March 21, 2002, at 06:54 PM, Jon Berndt wrote: The only way I can get SimGear to build is to replace SG_USING_STD(sort); with SG_USING_NAMESPACE(std); Nothing else seems to work. I have tried cleaning and rebuilding from scratch *multiple* times. Are there any other stdlib function calls in there from std namespace? Jon The only thing I see it complain about is using std::sort. If I try 'using std::sort,' as is done if PROPS_STANDALONE is defined, I get the same errors. Considering the problems I am having getting JSBSim to compile, with similar complaints, I am getting concerned that something has gone terribly wrong. If I had a better understanding of C++ and/or STL, I could be more help hunting this down. I may have to attempt a re-install of MSVC tomorrow. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] (no subject)
Jim Wilson writes: Here it is John. Description: Wilson's new u3a panel. It's not very accurate. Haven't found a picture yet. The shape and layout is fairly close and looks ok. Also linked to c310 default sound.xml and changed model so the props aren't so syncrhonous to look weird. File: http://www.spiderbark.com/fgfs/c310u3a-update-20020321.tar.gz Looks great! Good work. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
On Thursday, March 21, 2002, at 08:54 PM, Bernie Bright wrote:
David Megginson wrote:
OK, first let's make sure that my code is correct ANSI C++ before we
beat up on MSVC. Basically, I have this:
#include algorithm
SG_USING_STD(sort);
which is equivalent to
#include algorithm
using std::sort;
Is this correct? I think it is, but confirmation would be nice.
This is indeed Std C++ and is correct.
The following compiles fine with MSVC6sp3:
#include algorithm
#include vector
int main() {
std::vectorint v;
std::sort( v.begin(), v.end() );
return 0;
}
Replacing std::sort() with sort() and adding using std::sort; also
works.
Cheers,
Bernie
With the irregularity that I am having problems with using XXX I get the
feeling that there is something wrong with a header someplace, or a
#define. Not all modules generate the error, and others (namely the
updates, and only the updates, to JSBSim) blow body parts across the room.
I can change the behavior of JSBSim by rearranging the #includes in some
of the modules, but I cannot get rid of the errors.
Is anyone else building under MSVC 6.0 (or other MSVC compiler)?
Thanks,
Jonathan Polley
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Jonathan Polley wrote: With the irregularity that I am having problems with using XXX I get the feeling that there is something wrong with a header someplace, or a #define. Not all modules generate the error, and others (namely the updates, and only the updates, to JSBSim) blow body parts across the room. I can change the behavior of JSBSim by rearranging the #includes in some of the modules, but I cannot get rid of the errors. Is anyone else building under MSVC 6.0 (or other MSVC compiler)? Moving using std::sort after #include algorithm fixes the problem in props.cxx. I build under MSVC6 occasionally though generally I use linux. However I was responsible for resolving some of the early portability issues. Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
On Thursday, March 21, 2002, at 11:35 PM, Bernie Bright wrote: I build under MSVC6 occasionally though generally I use linux. However I was responsible for resolving some of the early portability issues. Cheers, Bernie Could you try a build of the main FlightGear app to verify if my FDM build problems are just me? Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] framerate 1/s
The changes from yesterday turned my framerate at KSFO from about 10 to 1 per second. Ten is already painful enough, and that with clouds and panel turned off. But one is a bit weak and makes fgfs virtually unflyable. (I've only got a 266MHz processor and a V3 graphics card.) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
