Re: [Flightgear-devel] New Release of Lake Constance custom scenery
Hello, Georg Vollnhals schrieb: Hi Ralf, thank you and all the Lake Constance Team Members for improving that wonderful piece of (scenery) cake for VFR flyers. I just managed due to lack of freetime to make a freeflight around LOIR (to the south and north) and could clearly see what you improved when passing the borders of the scenery in the south (barrier). Flying further it really looks very odd! Hm, this actually is due to the fact that I generated all scenery tiles within the bounding box around our data. This means that we have some tiles where nothing than airports and hills and mountains covered by forest are present. I should remove the empty tiles so that the standard scenery can come through there. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] cleanup of FlighGear and SimGear
Vassilii Khachaturov [EMAIL PROTECTED] writes: Surely that's a beneficial change, so please submit, whether you're talking about just the ATCutils module cleanup or of something with a wider scope. i haven't seen my previous patches (the message was blocked because of its size and it was waiting the moderator's approval). anyway, i've updated the patches and put them on the web. you can get them from: http://caliban.lbl.gov/fgfs_patches/flightgear.diff http://caliban.lbl.gov/fgfs_patches/simgear.diff --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] [BUG] tmp-ly disable buggy mag compass jamming code (fwd)
reply from David -- Forwarded message -- Date: Mon, 24 Oct 2005 17:55:31 -0400 From: David Megginson To: Vassilii Khachaturov Subject: Re: [PATCH] [BUG] tmp-ly disable buggy mag compass jamming code (fwd) On 23/10/05, Vassilii Khachaturov [EMAIL PROTECTED] wrote: i've sent the letter below to your old address and it bounced; Erik Hofman has kindly given me this gmail address instead to contact you about the flightgear affairs. If you're still reading the Flightgear-devel@flightgear.org list, sorry for the redundancy. Thanks for copying me with that, Vassilii. I'm not keeping up with the FlightGear code now, so if everyone else thinks the change is a good idea, I have no objection. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] waterways ..W in your airport database
On Mon, 24 Oct 2005, Robin Peel wrote: Paul: In general, X-Plane only supports water runways at designated seaplane bases, not as additions to terrestrial airports (I forget the reason, I am afraid). I will look into whether they can be added back. I do recall that PHNL has this combination - as do a few airports in Alaska. - Robin Thanks for looking into that. I haven't seen those airports myself, and I wonder what the beacon lighting for those with the beacons are as per the AIM 2-1-8? White/green + Yellow alone? http://www.faa.gov/atpubs/AIM/Chap2/aim0201.html#2-1-8 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] cleanup of FlighGear and SimGear
http://caliban.lbl.gov/fgfs_patches/flightgear.diff
Great work. I wonder if there is a way to profile fg/sg for this kind
of inefficiencies somewhere in a tight loop.
A couple of comments:
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 06:59:49 -
@@ -108,7 +108,7 @@
FGAIBase();
virtual ~FGAIBase();
virtual void update(double dt);
-inline Point3D GetPos() { return(pos); }
+inline const Point3D GetPos() { return(pos); }
enum object_type { otNull = 0, otAircraft, otShip, otCarrier, otBallistic,
otRocket, otStorm, otThermal, otStatic,
If you return the pos as a const Point3D, you should
probably mark the method to be const as well on the same occasion.
Also, by doing this change you vouch that *every* CALLER of the method
doesn't use the reference beyond the scope of the object's life
(should be fine if all that's done is a copy ctor right at the caller)
-- ignore me if you have checked this already.
Same with other similar changes (returning a const reference) further in
the patch.
diff -u -r1.8 ATCdisplay.hxx
--- src/ATC/ATCdisplay.hxx 30 Sep 2004 15:43:32 - 1.8
+++ src/ATC/ATCdisplay.hxx 25 Oct 2005 06:59:56 -
@@ -76,16 +76,16 @@
// Register a single message for display after a delay of delay
seconds
// Will automatically stop displaying after a suitable interval.
-void RegisterSingleMessage(string msg, double delay = 0.0);// OK -
I know passing a string in and out is probably not good but it will have to do
for now.
+void RegisterSingleMessage(const string msg, double delay = 0.0); // OK -
I know passing a string in and out is probably not good but it will have to do
for now.
Here it looks like you can safely remove the comment now :)
http://caliban.lbl.gov/fgfs_patches/simgear.diff
This one looks to me as containing some additional local changes you've
made, beyond the const optimization. See the chunks pertaining to
simgear/math/point3d.hxx
simgear/math/polar3d.hxx
and simgear/threads/SGThread.hxx
I suggest separating those away.
V.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Driving real instruments.
Just wondering if anyone (pos historically) has driven physical instruments using FlightGear on Linux. I'm thinking the analog variety (ASI AI ALT etc) from the likes of SimKits. Obviously the SimKits stuff couldn't work directly because their proprietary software to drive the CCU is for Windows and MSFS only. So are there, or have there been any examples of someone succesfully driving analog instruments using FlightGear on Linux? Cheers -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Just wondering if anyone (pos historically) has driven physical instruments using FlightGear on Linux. I'm thinking the analog variety (ASI AI ALT etc) from the likes of SimKits. Obviously the SimKits stuff couldn't work directly because their proprietary software to drive the CCU is for Windows and MSFS only. So are there, or have there been any examples of someone succesfully driving analog instruments using FlightGear on Linux? For the FAA Level 3 FTD certified sims I work with, we draw the instruments on an LCD screen, then place a panel cutout with bezels on top of that. Fools a *lot* of people into thinking they are real, even though they aren't. The simkits stuff are driven by standard servos, right? So you could get a little PIC board to run your servos and take position commands in from the serial port ... then you just need to send the data out the serial port from FG (with perhaps a small amount of interface coding.) It might be a little time consuming to get all the pieces in place and working, but once you figure out how to generate the PWM servo signal, there's nothing technically difficult there. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 14:07, Curtis L. Olson wrote: For the FAA Level 3 FTD certified sims I work with, we draw the instruments on an LCD screen, then place a panel cutout with bezels on top of that. Fools a *lot* of people into thinking they are real, even though they aren't. I did think of this trick too :) Although it also threw up a problem.. The simkits stuff are driven by standard servos, right? So you could get a little PIC board to run your servos and take position commands in from the serial port ... then you just need to send the data out the serial port from FG (with perhaps a small amount of interface coding.) It might be a little time consuming to get all the pieces in place and working, but once you figure out how to generate the PWM servo signal, there's nothing technically difficult there. Curt. The problem being the 'setting' of an instrument. If you wanted to directly set an instrument you'd need some sort of encoder (eg: to rotate a VOR direction wheel). This could be done easily enough, of course, in the case of the LCD behind the panel, the major hurdle being the depth of the control in the panel. When it comes to physical gauges, the system itself would need to know the precise position of a direction wheel so it would have to be read from a sensor in the instrument (SimKits do this). The only way forward I spotted was using 'Phidgets' interface cards to run the servos and also read from analog sensors in the instruments. Unfortunately my total lack of software development skills and apparent numerical dyslexia would preclude this. That is, unless now or in the future enough people might become interested in doing this (I may not code but I'm quite the engineer when it comes to physical stuff ;) ) I think I could drive an ASI, AI, TC, VSI and engine guages using Phidgets just by writing FG values to a phidgets device in the correct sense but anything more is rocket-science to me due to the code involved. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Curtis L. Olson wrote: [...] The simkits stuff are driven by standard servos, right? So you could get a little PIC board to run your servos and take position commands in from the serial port ... then you just need to send the data out the serial port from FG (with perhaps a small amount of interface coding.) I could be easier than that. You can buy ready-to-run serial interface boards with several PWM outputs - you just need the ability to define an output bit mask in FlightGear in which you compile the desired output values. For the other direction there are simple analogue to serial converters, some even directly attached to a potentiometer that you can use to set the altimeter QNH. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] cleanup of FlighGear and SimGear
Vassilii Khachaturov wrote:
http://caliban.lbl.gov/fgfs_patches/flightgear.diff
Great work. I wonder if there is a way to profile fg/sg for this kind
of inefficiencies somewhere in a tight loop.
Ok, these changes have been committed. It's quite extensive but I'm
rather pleased with them. Thanks Alex!
A couple of comments:
-inline Point3D GetPos() { return(pos); }
+inline const Point3D GetPos() { return(pos); }
If you return the pos as a const Point3D, you should
probably mark the method to be const as well on the same occasion.
This one has been omitted because it limits it's usability and doesn't
improve the code much IMHO.
This one looks to me as containing some additional local changes you've
made, beyond the const optimization. See the chunks pertaining to
simgear/math/point3d.hxx
simgear/math/polar3d.hxx
and simgear/threads/SGThread.hxx
These are all speedups and thread safety updates, so I've committed
these also.
Erik
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Depth buffer issues with instruments and reindeer
Just thought I'd mention a couple things. 1) Some of the aircraft panel instruments display z-fighting even at the higher depth buffer setting... # grep Depth XFree86.0.log (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 (--) Depth 24 pixmap format is 32 bpp ...and I'm wondering if there's been some change in the 2D panel code or something else that might be producing this. The Citation II seems to be especially bad. Are other folks seeing this? 2) Raindeer in the santa model should be spelled reindeer. It might be a common misspelling but it is still a misspelling ;-) Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Depth buffer issues with instruments and reindeer
Jim Wilson wrote: 2) Raindeer in the santa model should be spelled reindeer. It might be a common misspelling but it is still a misspelling ;-) Ehr Alright, but only because it's you who mentioned it. I could have called it rendier instead as it's called in Dutch, but I chose to call it after Rainman I guess ... ;-) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 14:07, Curtis L. Olson wrote: For the FAA Level 3 FTD certified sims I work with, we draw the instruments on an LCD screen, then place a panel cutout with bezels on top of that. Fools a *lot* of people into thinking they are real, even though they aren't. Just another quick thought on this idea. (I'd like to try it) If I've got my facts right, a standard gauge is about 3 1/8inch (approx 80mm) diameter mount. So does that suggest a 19inch or 20inch LCD screen for the c172-610x panel? I've also had a couple of bright ideas for providing gauge adjustment controls infront of the LCD, do you have a trick to do this or do you set them separately (via a normal key/mouse interface)? Thanks -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Just another quick thought on this idea. (I'd like to try it) If I've got my facts right, a standard gauge is about 3 1/8inch (approx 80mm) diameter mount. So does that suggest a 19inch or 20inch LCD screen for the c172-610x panel? I don't recall the exact dimensions but I'm sure it's somewhere in that neighborhood. I've also had a couple of bright ideas for providing gauge adjustment controls infront of the LCD, do you have a trick to do this or do you set them separately (via a normal key/mouse interface)? There are adjustments in the proper place on the panel. I'm just a software guy, so I don't know all the hardware tricks that are being done. But I do know the end result has a nice solid feel and is very convincing. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
For the FAA Level 3 FTD certified sims I work with, we draw the instruments on an LCD screen, then place a panel cutout with bezels on top of that. How are you driving the panel? From the same box as the cockpit view (multiple FG instances?)or by using multiple machines? I'm quite interested in the possibilities of multi-display setups, but it feels a bit excessive to have a box just dedicated to displaying a panel. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Buchanan, Stuart wrote: How are you driving the panel? From the same box as the cockpit view (multiple FG instances?)or by using multiple machines? I'm quite interested in the possibilities of multi-display setups, but it feels a bit excessive to have a box just dedicated to displaying a panel. A really good setup requires the following: * The server, displaying the panel and running the FDM. * A dual core machine for every display as a slave to the main server. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
A really good setup requires the following: * The server, displaying the panel and running the FDM. * A dual core machine for every display as a slave to the main server. Erik What is the reason for using a dual-core machine for each 'out the window' view? (Asking out of ignorance) -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/ATC AIEntity.cxx, 1.12,
Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/FlightGear/src/ATC In directory baron:/tmp/cvs-serv30924/src/ATC [...] * Use const string rather than string in function calls when appropriate. [...] I have the impression that the changes to the FlightGear subtree didn't make it into CVS - at least they didn't appear on checkout. Am I the only one who misses these changes ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 15:34, Curtis L. Olson wrote: There are adjustments in the proper place on the panel. I'm just a software guy, so I don't know all the hardware tricks that are being done. But I do know the end result has a nice solid feel and is very convincing. Curt. Well, I think I could get the adjusters in place (experimentation time) My next question would have to be (bear with me) Does FreeGLUT support multiple mice yet? Alternatively, does FreeGLUT rely on X11 for it's mouse definitions. I think I may have found a method in X.org which will allow multiple USB mice to behave as a single 'logical' mouse - albeit with loads of scroll-wheels etc. ;) The idea being that a mouse is possibly the cheapest off-the-shelf 'encoder' on the market (not strictly an encoder but good for the purpose). Not sure about x.org's limitations but the USB interface will support 127 devices per channel; more than enough for a light-aircraft cockpit interface. Cheers. -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Depth buffer issues with instruments and reindeer
Jim Wilson wrote: Just thought I'd mention a couple things. 1) Some of the aircraft panel instruments display z-fighting even at the higher depth buffer setting... # grep Depth XFree86.0.log (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 (--) Depth 24 pixmap format is 32 bpp ...and I'm wondering if there's been some change in the 2D panel code or something else that might be producing this. The Citation II seems to be especially bad. Are other folks seeing this? Depth tests are disabled when drawing 2D or 2.5D panels. I've checked the Citation-II, I can not see any z-fighting. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Buchanan, Stuart wrote: How are you driving the panel? From the same box as the cockpit view (multiple FG instances?)or by using multiple machines? I'm quite interested in the possibilities of multi-display setups, but it feels a bit excessive to have a box just dedicated to displaying a panel. We are using multiple machines, one for each display. My feeling is that if it is a bit excessive, it is only a small bit excessive and I can put up with it. :-) You are welcome to try running a multiheaded machine (with support for opengl on all your displays.) I'd be interested in hearing your results. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Well, I think I could get the adjusters in place (experimentation time) My next question would have to be (bear with me) Does FreeGLUT support multiple mice yet? Alternatively, does FreeGLUT rely on X11 for it's mouse definitions. I think I may have found a method in X.org which will allow multiple USB mice to behave as a single 'logical' mouse - albeit with loads of scroll-wheels etc. ;) The idea being that a mouse is possibly the cheapest off-the-shelf 'encoder' on the market (not strictly an encoder but good for the purpose). Not sure about x.org's limitations but the USB interface will support 127 devices per channel; more than enough for a light-aircraft cockpit interface. John Wojnarowski is developing some interesting switch, button, light interfacing hardware that plugs into your computer via usb. I don't know if it has any A2D or D2A capabilities. It sounds really promising though. Hopefully he will jump in here with details as his time permits. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: What is the reason for using a dual-core machine for each 'out the window' view? It allows you to load the scenery without seeing glitches or hick-ups in the rendering thread. Erik ___ 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/ATC AIEntity.cxx, 1.12,
Martin Spott wrote: I have the impression that the changes to the FlightGear subtree didn't make it into CVS - at least they didn't appear on checkout. Am I the only one who misses these changes ? I guess so, the CVS changelog was sent out to me by mail. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tuesday 25 October 2005 16:45, Curtis L. Olson wrote: We are using multiple machines, one for each display. My feeling is that if it is a bit excessive, it is only a small bit excessive and I can put up with it. :-) You are welcome to try running a multiheaded machine (with support for opengl on all your displays.) I'd be interested in hearing your results. I had a go at this a while back using the nvidia proprietary driver's TwinView option. TwinView can be configured to stretch the X display across 2 screens and provide acceleration on both. The nvidia driver hides the fact that the display spans two screens. So 2x 1024x768 displays are presented to the X server as a single 2048x768 wide screen. Using FlightGear across both of the displays is as simple as launching with --geometry=2048x768 and the performance is the same as you'd expect displaying the same size window on a single display. You can adjust the FOV to say 90deg to give a realistic panorama and I'd love to try it with two projectors :) Note that I tried --enable-game-mode but didn't get it working, however I'm sure this was down to my setup at the time and not the TwinView config. For displaying a panel (and avoiding the performance hit of two instances) perhaps you could configure the TwinView as 'top and bottom' monitors, the top one providing the out-the-window view and the bottom one showing the panel. The panel would probably have to be specifically designed to only fill 1/2 your display area - the 610x panel seems to scale to the longest edge in all circumstances. Personally, I'd favour the aforementioned 2 systems, one for panel, FDM, input and sound and one (or more) for the out-the-window view. (Hopefully thereby boosting the 3d display's performance a bit?) -- Dave Martin http://museum.bounce-gaming.net ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Dave Martin wrote: Unfortunately my total lack of software development skills and apparent numerical dyslexia would preclude this. That is, unless now or in the future enough people might become interested in doing this (I may not code but I'm quite the engineer when it comes to physical stuff ;) ) I think I could drive an ASI, AI, TC, VSI and engine guages using Phidgets just by writing FG values to a phidgets device in the correct sense but anything more is rocket-science to me due to the code involved. http://www.f15sim.com/index.html is a website you might try. He is using Phidgets to drive some of his gauges. Don't have the details. I think most of the Phidget software is MS Windows based although some of it is being ported to Linux ( how much and when I don't know ) I might be wrong and have not examined any of the software or interfaces closely but I think you'll need to do more a bit more than just write FG values to a device. If Phidgets aren't the answer, might consider breadboarding up a circuit via a USB I/O port along with the software. I've been working on some electronics for a slightly different application, but this might be an interesting derivative. If you want to handle the physical stuff, I could find some time to help with the electronics and software. You can contact me off-list at [EMAIL PROTECTED] Regards John W. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/Main metar_main.cxx, 1.9, 1.10
Erik Hofman [EMAIL PROTECTED] writes:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv17258
Modified Files:
metar_main.cxx
Log Message:
I guess there was something in Alex' patch that wasn't all that fortunate.
Index: metar_main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/metar_main.cxx,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -r1.9 -r1.10
*** metar_main.cxx25 Oct 2005 13:49:57 - 1.9
--- metar_main.cxx25 Oct 2005 16:28:46 - 1.10
***
*** 28,32
#include simgear/environment/metar.hxx
#include simgear/structure/exception.hxx
- #include simgear/scene/sky/sky.hxx
using namespace std;
--- 28,31
***
*** 486,491
}
- SGSky* thesky = new SGSky;
-
int main(int argc, char *argv[])
{
--- 485,488
sorry about this, but when i link against shared libraries i need this
otherwise i get:
g++ -DPKGLIBDIR=\/usr/local/share/FlightGear\ -g -O2 -D_REENTRANT
-L/usr/X11R6/lib -L/usr/local/lib -o metar metar_main.o -lsgenvironment -lsgio
-lsgbucket -lsgmisc -lsgstructure -lsgdebug -lsgprops -lsgxml -lsgserial
-lsgsound -lsgsky -lsgmaterial -lsgscreen -lsgmath -lplibssg -lplibsg -lglut
-lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lplibnet -lplibul
-lz -ldl -lm -lexpat -lalut -lopenal -ldl -lm -lpthread -lalut
/usr/local/lib/libsgsky.so: undefined reference to `thesky'
collect2: ld returned 1 exit status
i am not sure exactly _why_ it works for static libraries.
anyway, this doesn't affect anybody else (unless they use shared
libraries like me).
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Threading for SMP, boon or bane?
On Mon, 24 Oct 2005 11:08:06 -0700, Andy wrote in message [EMAIL PROTECTED]: Curtis L. Olson wrote: I would like to make a case for non-threading from the standpoint of simplicity. We have had (and probably still have) some extremely subtle and extremely difficult to track bugs in our threaded tile loader. I don't disagree at all. Everything you say is true, and a reason to avoid threading wherever possible. Naive thread architectures are invariably a disaster. But unfortunately the hardware world conspires against us -- SMP is rapidly becoming the rule rather than the exception for high performance desktops. Note that there are a few spots where we could split out separate threads in a relatively clean manner: + FDM: Put a lock around the input and output stages (or wrap them into an object that can be placed in a synchronized queue) and let the actual numerics work happen on a different CPU. The advantage here is that you can crank up the simulation rate quite a bit on SMP/multicore boxes, leading to (at least with YASim) more stable ground handling. ..and clusters. ;o) + Audio: drive the OpenAL thread with a simple command stream from the main loop. One many systems, this will (might, if OpenAL doesn't already do this) move the mixing off of the main CPU, which is good. Even better, it will decouple the audio stream from the main loop latency issues and make skips easier to handle. + Rendering: One idea here would be to clone a separate scene graph (just the non-leaf animation nodes, really) and let one thread (the renderer) draw it while another (the main loop) gets the next one ready for rendering. When done, you do a synchronized graph swap, or even triple-buffer it for higher throughput at the expense of latency. This would require significant surgery to the existing model/animation code (and, to a lesser extent, the GUI and tile code) to store the property values somewhere instead of reading them at render-time. ..can we get both multi screen wrap around cockpit style immersion movie theaters and formation flight? + Everything else: This thread would contain the existing main loop, and its basic structure wouldn't change. Note that this design allows threads live by relatively simple rules. The main loop doesn't change much except where direct calls are replaced by commands to be queued. And the worker threads all work only on their internal data; they don't need (and are forbidden) to touch external state like the property tree. The first two could be done with fairly minimal code, actually. The renderer changes would be more significant. -- ..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@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tue, 25 Oct 2005 13:59:31 +0100, Dave wrote in message [EMAIL PROTECTED]: Just wondering if anyone (pos historically) has driven physical instruments using FlightGear on Linux. I'm thinking the analog variety (ASI AI ALT etc) from the likes of SimKits. Obviously the SimKits stuff couldn't work directly because their proprietary software to drive the CCU is for Windows and MSFS only. So are there, or have there been any examples of someone succesfully driving analog instruments using FlightGear on Linux? ..the closest thing I'm aware of this far, would be the Discovery TV show on Red Baron's (Richthofen) final dog fight, they used FG and a commercial FS (MSFS?) hooked up together. I think Michael Selig at UIUC was involved, Michael, Curt? -- ..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@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] cleanup of FlighGear and SimGear
Vassilii Khachaturov [EMAIL PROTECTED] writes:
http://caliban.lbl.gov/fgfs_patches/flightgear.diff
Great work. I wonder if there is a way to profile fg/sg for this kind
of inefficiencies somewhere in a tight loop.
A couple of comments:
diff -u -r1.43 AIBase.hxx
--- src/AIModel/AIBase.hxx15 Oct 2005 14:55:51 - 1.43
+++ src/AIModel/AIBase.hxx25 Oct 2005 06:59:49 -
@@ -108,7 +108,7 @@
FGAIBase();
virtual ~FGAIBase();
virtual void update(double dt);
-inline Point3D GetPos() { return(pos); }
+inline const Point3D GetPos() { return(pos); }
enum object_type { otNull = 0, otAircraft, otShip, otCarrier,
otBallistic,
otRocket, otStorm, otThermal, otStatic,
If you return the pos as a const Point3D, you should
probably mark the method to be const as well on the same occasion.
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).
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
Curtis L. Olson wrote: Dave Martin wrote: Well, I think I could get the adjusters in place (experimentation time) My next question would have to be (bear with me) Does FreeGLUT support multiple mice yet? Alternatively, does FreeGLUT rely on X11 for it's mouse definitions. I think I may have found a method in X.org which will allow multiple USB mice to behave as a single 'logical' mouse - albeit with loads of scroll-wheels etc. ;) The idea being that a mouse is possibly the cheapest off-the-shelf 'encoder' on the market (not strictly an encoder but good for the purpose). Not sure about x.org's limitations but the USB interface will support 127 devices per channel; more than enough for a light-aircraft cockpit interface. It's cheap and you get what you pay for. Not enough bits and resolution and you still face the problem of now writing some sort of driver that handles the USB connections and converts the GLUT mouse inputs to something meaningful to drive your gauges. And you still have to handle the physical design problem. Thinking it's better to start with a clean piece of paper. Again, phidgets are worth a look. The software problem is also cleaner than a X-11/GLUT hack and can be worked. John Wojnaroski is developing some interesting switch, button, light interfacing hardware that plugs into your computer via usb. I don't know if it has any A2D or D2A capabilities. It sounds really promising though. Hopefully he will jump in here with details as his time permits. Curt. The boards Curt refers to were specifically designed for a 747 simulator. They will read analog, discrete inputs, rotary encoders but are not designed to drive anything other than digital signals. Would need a bit more design and rework to handle the current loads of DC motors or servos, control, etc. (See earlier post) Regards John W. ___ 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/ATC AIEntity.cxx, 1.12,
Erik Hofman Martin Spott wrote: I have the impression that the changes to the FlightGear subtree didn't make it into CVS - at least they didn't appear on checkout. Am I the only one who misses these changes ? I guess so, the CVS changelog was sent out to me by mail. Erik I'd be more impressed if this extensive change to CVS compiled under Cygwin, so far I've found and corrected half a dozen errors, but now I think I've stuck on AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' discards qualifiers SNAFU Vivian ___ 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/ATC AIEntity.cxx, 1.12,
Vivian Meazza discovered: AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' discards qualifiers Heh, don't you just *love* C++ error messages? :) Translated: AIFlightPlan.cxx:69: error: passing `const string' as `this' argument of `string::operator=()' discards qualifiers You can't assign to a const object, basically. No idea why this compiles correctly on other platforms... Andy ___ 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/ATCAIEntity.cxx, 1.12,
Andy Ross Vivian Meazza discovered: AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' discards qualifiers Heh, don't you just *love* C++ error messages? :) Translated: AIFlightPlan.cxx:69: error: passing `const string' as `this' argument of `string::operator=()' discards qualifiers You can't assign to a const object, basically. No idea why this compiles correctly on other platforms... Cracked that one - I introduced it in correcting others. So all done now. Just preparing a diff of the changes that I had to apply to get Cygwin to compile. Thanks Vivian ___ 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:[Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Vivian Meazza wrote Andy Ross Vivian Meazza discovered: AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' discards qualifiers Heh, don't you just *love* C++ error messages? :) Translated: AIFlightPlan.cxx:69: error: passing `const string' as `this' argument of `string::operator=()' discards qualifiers You can't assign to a const object, basically. No idea why this compiles correctly on other platforms... Cracked that one - I introduced it in correcting others. So all done now. Just preparing a diff of the changes that I had to apply to get Cygwin to compile. I attach a diff against CVS - HEAD which I applied to get CVS to compile under Cygwin. It may not be the best or preferred way to do it, but the patch works here, so far as I can see. Regards, Vivian CVS.diff Description: Binary data ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Vivian Meazza [EMAIL PROTECTED] writes:
I attach a diff against CVS - HEAD which I applied to get CVS to compile
under Cygwin. It may not be the best or preferred way to do it, but the
patch works here, so far as I can see.
diff -u -w -b -r1.11 AIFlightPlan.hxx
--- AIFlightPlan.hxx25 Oct 2005 13:49:56 - 1.11
+++ AIFlightPlan.hxx25 Oct 2005 19:17:09 -
@@ -77,14 +77,14 @@
time_t getStartTime() { return start_time; };
voidcreate(FGAirport *dep, FGAirport *arr, int leg, double alt, double
speed, double lat, double lon,
-bool firstLeg, double radius, const string fltType, const
string aircraftType, const string airline);
+bool firstLeg, double radius, string fltType, string
aircraftType, string airline);
void setLeg(int val) { leg = val;};
void setTime(time_t st) { start_time = st; };
int getGate() { return gateId; };
double getLeadInAngle() { return leadInAngle; };
- const string getRunway() { return rwy._rwy_no; };
- const string getRunwayId() { return rwy._id; };
+ string getRunway() { return rwy._rwy_no; };
+ string getRunwayId() { return rwy._id; };
void setRepeat(bool r) { repeat = r; };
bool getRepeat(void) { return repeat; };
void restart(void);
why do you need to do this? what was the error when trying to compile
the cvs version?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
On Tue, October 25, 2005 5:18 pm, John Wojnaroski said: The boards Curt refers to were specifically designed for a 747 simulator. They will read analog, discrete inputs, rotary encoders but are not designed to drive anything other than digital signals. Would need a bit more design and rework to handle the current loads of DC motors or servos, control, etc. (See earlier post) How about the analogue output boards on http://cockpit.varxec.net/ -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Depth buffer issues with instruments and reindeer
From: Harald JOHNSEN Jim Wilson wrote: Just thought I'd mention a couple things. 1) Some of the aircraft panel instruments display z-fighting even at the higher depth buffer setting... # grep Depth XFree86.0.log (**) NVIDIA(0): Depth 24, (--) framebuffer bpp 32 (--) Depth 24 pixmap format is 32 bpp ...and I'm wondering if there's been some change in the 2D panel code or something else that might be producing this. The Citation II seems to be especially bad. Are other folks seeing this? Depth tests are disabled when drawing 2D or 2.5D panels. I've checked the Citation-II, I can not see any z-fighting. http://www.spiderbark.com/fgfs/citation_instruments.png It turns out these are in fact contained in a single 3D model for the entire aircraft, so it has nothing to do with 2D. Apparently the problem is in the models. I'll have to go back and make a list of the others. Of course now this raises a question about how my nvidia card is operating a 16bpp buffer when the logs all show it is configured properly. FWIW I'd like to suggest that it is a good idea for 3D modelers to test their work at 16 bit depth buffer settings since a lot of folks are still running modern laptop, consumer grade and Intel embedded chips at 16 bit for performance reasons. Even though it involves moving layers further appart, adjusting 3D instrument models to support 16 bit generally does no harm to the appearance of the model at the normal viewing distance. Best, Jim ___ 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
On Dienstag 25 Oktober 2005 21:33, Frederic Bouvier wrote: 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. No, obviously not. You would use that like Point3D pt = obj.GetPos(); where the const ref is directly passed into the constructor of pt. No problem at all. If you don't need a temporary copy, you can with zero cost just use obj.GetPos() multiple times without creating multiple temporary copies of the return value. As long as the returned object is implemented const correct, returning a const ref by a const getter function is the prefered way to do. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ 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/ATCAIEntity.cxx, 1.12,
Alex Romosan asked
Vivian Meazza [EMAIL PROTECTED] writes:
I attach a diff against CVS - HEAD which I applied to get CVS to compile
under Cygwin. It may not be the best or preferred way to do it, but the
patch works here, so far as I can see.
diff -u -w -b -r1.11 AIFlightPlan.hxx
--- AIFlightPlan.hxx25 Oct 2005 13:49:56 - 1.11
+++ AIFlightPlan.hxx25 Oct 2005 19:17:09 -
@@ -77,14 +77,14 @@
time_t getStartTime() { return start_time; };
voidcreate(FGAirport *dep, FGAirport *arr, int leg, double alt,
double speed, double lat, double lon,
-bool firstLeg, double radius, const string fltType,
const string aircraftType, const string airline);
+bool firstLeg, double radius, string fltType, string
aircraftType, string airline);
void setLeg(int val) { leg = val;};
void setTime(time_t st) { start_time = st; };
int getGate() { return gateId; };
double getLeadInAngle() { return leadInAngle; };
- const string getRunway() { return rwy._rwy_no; };
- const string getRunwayId() { return rwy._id; };
+ string getRunway() { return rwy._rwy_no; };
+ string getRunwayId() { return rwy._id; };
void setRepeat(bool r) { repeat = r; };
bool getRepeat(void) { return repeat; };
void restart(void);
why do you need to do this?
Er ... because Cygwin wouldn't compile?
what was the error when trying to compile
the cvs version?
The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far
as the compiler was concerned.
It now compiles and runs OK
V.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Vivian Meazza [EMAIL PROTECTED] writes: The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far as the compiler was concerned. It now compiles and runs OK i don't understand. does the cvs version compile or do you still have to make those changes to get it to compile? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ 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/ATCAIEntity.cxx, 1.12,
Alex Romosan asked: Vivian Meazza [EMAIL PROTECTED] writes: The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far as the compiler was concerned. It now compiles and runs OK i don't understand. does the cvs version compile or do you still have to make those changes to get it to compile? Before I made the corrections cvs failed to compile. After I made the corrections (those in the diff) cvs compiled and ran. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Vivian Meazza [EMAIL PROTECTED] writes: Alex Romosan asked: Vivian Meazza [EMAIL PROTECTED] writes: The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far as the compiler was concerned. It now compiles and runs OK i don't understand. does the cvs version compile or do you still have to make those changes to get it to compile? Before I made the corrections cvs failed to compile. After I made the corrections (those in the diff) cvs compiled and ran. this is why i would've have liked to see the original error message. if the compiler didn't like those changes here it should've not liked them everywhere else. unfortunately i don't have cygwin installed to compile it myself. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Santa's r[ae]i?ndeer
Why are the bells commented out in raindeer-sound.xml? They do sound cute. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Driving real instruments.
John Wojnaroski wrote: Dave Martin wrote: Unfortunately my total lack of software development skills and apparent numerical dyslexia would preclude this. That is, unless now or in the future enough people might become interested in doing this (I may not code but I'm quite the engineer when it comes to physical stuff ;) ) I think I could drive an ASI, AI, TC, VSI and engine guages using Phidgets just by writing FG values to a phidgets device in the correct sense but anything more is rocket-science to me due to the code involved. http://www.f15sim.com/index.html is a website you might try. He is using Phidgets to drive some of his gauges. Don't have the details. Phidgets are insanely easy to drive. Right now the only gauges I'm driving are 1 custom built steam gauges for the oil hyd pressure. They use ultra-micro Futaba servos with a 2:1 gear ratio to drive the pointer. You might want to head over to http://www.mikesflightdeck.com if you want to see how to scratch build your own gear. g. -- I'm not crazy, I'm plausibly off-nominal! Proud owner of 80-0007 http://www.f15sim.com - The only one of its kind. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] cleanup of FlighGear (part ii)
i tried to make sure accessor functions which return by reference act
on const objects. also replaced some iterators with const_iterator
and a few return/pass by reference that were missed the first time
around:
Index: src/AIModel/AIAircraft.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIAircraft.hxx,v
retrieving revision 1.15
diff -u -r1.15 AIAircraft.hxx
--- src/AIModel/AIAircraft.hxx 4 Jun 2005 09:38:52 - 1.15
+++ src/AIModel/AIAircraft.hxx 26 Oct 2005 01:05:25 -
@@ -61,7 +61,7 @@
void SetPerformance(const PERF_STRUCT *ps);
void SetFlightPlan(FGAIFlightPlan *f);
-FGAIFlightPlan* GetFlightPlan() { return fp; };
+FGAIFlightPlan* GetFlightPlan() const { return fp; };
void AccelTo(double speed);
void PitchTo(double angle);
void RollTo(double angle);
Index: src/AIModel/AIBase.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/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 26 Oct 2005 01:05:25 -
@@ -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,
Index: src/AIModel/AIFlightPlan.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIFlightPlan.cxx,v
retrieving revision 1.13
diff -u -r1.13 AIFlightPlan.cxx
--- src/AIModel/AIFlightPlan.cxx 25 Oct 2005 13:49:56 - 1.13
+++ src/AIModel/AIFlightPlan.cxx 26 Oct 2005 01:05:25 -
@@ -295,8 +295,8 @@
}
-FGAIFlightPlan::waypoint*
-FGAIFlightPlan::getPreviousWaypoint( void )
+FGAIFlightPlan::waypoint* const
+FGAIFlightPlan::getPreviousWaypoint( void ) const
{
if (wpt_iterator == waypoints.begin()) {
return 0;
@@ -306,14 +306,14 @@
}
}
-FGAIFlightPlan::waypoint*
-FGAIFlightPlan::getCurrentWaypoint( void )
+FGAIFlightPlan::waypoint* const
+FGAIFlightPlan::getCurrentWaypoint( void ) const
{
return *wpt_iterator;
}
-FGAIFlightPlan::waypoint*
-FGAIFlightPlan::getNextWaypoint( void )
+FGAIFlightPlan::waypoint* const
+FGAIFlightPlan::getNextWaypoint( void ) const
{
wpt_vector_iterator i = waypoints.end();
i--; // end() points to one element after the last one.
@@ -344,7 +344,7 @@
}
// gives distance in feet from a position to a waypoint
-double FGAIFlightPlan::getDistanceToGo(double lat, double lon, waypoint* wp){
+double FGAIFlightPlan::getDistanceToGo(double lat, double lon, waypoint* wp) const{
// get size of a degree2 at the present latitude
// this won't work over large distances
double ft_per_deg_lat = 366468.96 - 3717.12 * cos(lat / SG_RADIANS_TO_DEGREES);
@@ -386,12 +386,12 @@
}
-double FGAIFlightPlan::getBearing(waypoint* first, waypoint* second){
+double FGAIFlightPlan::getBearing(waypoint* first, waypoint* second) const{
return getBearing(first-latitude, first-longitude, second);
}
-double FGAIFlightPlan::getBearing(double lat, double lon, waypoint* wp){
+double FGAIFlightPlan::getBearing(double lat, double lon, waypoint* wp) const{
double course, distance;
// double latd = lat;
// double lond = lon;
Index: src/AIModel/AIFlightPlan.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIFlightPlan.hxx,v
retrieving revision 1.11
diff -u -r1.11 AIFlightPlan.hxx
--- src/AIModel/AIFlightPlan.hxx 25 Oct 2005 13:49:56 - 1.11
+++ src/AIModel/AIFlightPlan.hxx 26 Oct 2005 01:05:25 -
@@ -62,37 +62,37 @@
const string airline);
~FGAIFlightPlan();
- waypoint* getPreviousWaypoint( void );
- waypoint* getCurrentWaypoint( void );
- waypoint* getNextWaypoint( void );
+ waypoint* const getPreviousWaypoint( void ) const;
+ waypoint* const getCurrentWaypoint( void ) const;
+ waypoint* const getNextWaypoint( void ) const;
void IncrementWaypoint( bool erase );
- double getDistanceToGo(double lat, double lon, waypoint* wp);
- int getLeg () { return leg;};
+ double getDistanceToGo(double lat, double lon, waypoint* wp) const;
+ int getLeg () const { return leg;};
void setLeadDistance(double speed, double bearing, waypoint* current, waypoint* next);
void setLeadDistance(double distance_ft);
double getLeadDistance( void ) const {return lead_distance;}
- double getBearing(waypoint* previous, waypoint* next);
- double getBearing(double lat, double lon, waypoint* next);
- time_t getStartTime() { return start_time; };
+ double getBearing(waypoint* previous, waypoint* next) const;
+ double
