[Flightgear-devel] directional sound...
Hi guys, Just a note to say fantastic job on the directional/doppler sounds ! I'm never going to get any flying done now , I just keep buzzing the tower :) Cheers. -- syd & sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
On Fri, 22 Jun 2007 23:27:51 +0100 "Vivian Meazza" <[EMAIL PROTECTED]> wrote: > Syd > > > Sent: 22 June 2007 20:18 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar > > > > > > On Fri, 22 Jun 2007 16:56:34 +0100 > > "Vivian Meazza" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > -Original Message- > > > Syd > > > > > > > Sent: 22 June 2007 15:43 > > > > To: FlightGear developers discussions > > > > Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar > > > > > > > > > > > > On Fri, 22 Jun 2007 13:42:16 +0200 > > > > Melchior FRANZ <[EMAIL PROTECTED]> wrote: > > > > > > > > > * Vivian Meazza -- Wednesday 13 June 2007: > > > > > > Tim Moore has been hard at work recently (with the smallest of > > > > > > inputs by me), and has ported the improved weather > > radar already > > > > > > available for plib to OSG. > > > > > > > > > > No objections and other comments since the patches were > > > > published on > > > > > 2007/06/20. Because of the nearing release (not that we have the > > > > > slightest idea when this could be :-) and the nature of > > the patch I > > > > > want to give developers one last chance to object: if > > > > nobody does that > > > > > until tomorrow 2007/06/23 20:00 GMT, then I will: > > > > > > > > > > (a) apply those radar patches to sg and fg for osg and plib > > > > > (b) comment out the "delete rt" in > > > > src/Instrumentation/od_gauge.cx:89 > > > > > > > > > > > > > > > > > > > > PRO > > > > > > > > > > + we have a nice c++ radar implementation in both > > branches, which > > > > > handles arbitrary numbers of AI/MP aircraft, ships, TACAN > > > > > emitting and other objects > > > > > > > > > > + we can drop the quite clumsy and limited & limiting XML radar > > > > > implementation > > > > > > > > > > + fixes a bug in AIManager (ask Vivian :-) > > > > > > > > > > + instantiates impact sub-submodels in correct order > > > > > > > > > > > > > > > > > > > > CONTRA - > > > > > > > > > > - bigger commit despite the near(?) release, with potential risk > > > > > to break something > > > > > > > > > > BUT: + the patch touches only files that can hardly have side > > > > > effects on other subsystems, and isn't executed at all > > > > > when aircraft without od_gauge/radar are used (which > > > > > is the vast majority). So even if there'd be problems, > > > > > they would only affect the E3B, the T38(?), and ... the > > > > > harrier? And even then one could comment out the radar > > > > > instrument in the XML file and avoid all problems. > > > > > > > > > >+ the patches were tested by, at least, Vivian, AJ, > > > > > Csaba "Jester"(?) and me, and found functional and not > > > > > causing problems, except the following (AJ and I): > > > > > > > > > > - requires to comment out the destruction of the RTT class to > > > > > avoid crashes on exit on (some?) nVidia cards. That's hackish, > > > > > > > > > > BUT: + that's exactly what the 3D clouds are doing > > since years! > > > > > They don't destruct the RTT class either! Nobody has > > > > > reported problems that could be linked to that, none > > > > > of the developers has observed such problems (AFAIK). > > > > > > > > > >+ that's exactly what the TestRenderTexture.cxx test > > > > > application by the very author of the RenderTexture > > > > > class does. He doesn't destruct the class > > either (except > > > > > before creating a new one during mode changes on user > > > > > request). > > > > > > > > > >+ it can be assumed that the card frees this resource > > > > > like all others, when the context is destroyed, so the > > > > > buggy freeing operation via glXDestroyPbuffer() should > > > > > be optional in this case. > > > > > > > > > > m. > > > > > > > > Hi , I vote for adding it , and I've had that shutdown error > > > > since I first used the wxradar ,it's not a new one here... > > > > Just my 2 cents worth :). Cheers > > > > > > > > > > That's very interesting information. We suspected that this was a > > > longstanding problem, but had no evidence. And does Melchior's fix, > > > fix it for you? > > > > > > V. > > > > > Hi Vivian, > > No I haven't tried the updated version yet ... anxiously > > awaiting CVS version ;).But I can try it first if you like , > > and see what I get ... Cheers > > -- > > > > It would be helpful if you could comment out "delete rt" in > src/Instrumentation/od_gauge.cx around line #89, and tell us if that fixes > the problem in the old code. > > Thanks > > Vivian > Hi again, I checked the source code , recent update , and "delete rt" is already
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
Syd > Sent: 22 June 2007 20:18 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar > > > On Fri, 22 Jun 2007 16:56:34 +0100 > "Vivian Meazza" <[EMAIL PROTECTED]> wrote: > > > > > > > > -Original Message- > > Syd > > > > > Sent: 22 June 2007 15:43 > > > To: FlightGear developers discussions > > > Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar > > > > > > > > > On Fri, 22 Jun 2007 13:42:16 +0200 > > > Melchior FRANZ <[EMAIL PROTECTED]> wrote: > > > > > > > * Vivian Meazza -- Wednesday 13 June 2007: > > > > > Tim Moore has been hard at work recently (with the smallest of > > > > > inputs by me), and has ported the improved weather > radar already > > > > > available for plib to OSG. > > > > > > > > No objections and other comments since the patches were > > > published on > > > > 2007/06/20. Because of the nearing release (not that we have the > > > > slightest idea when this could be :-) and the nature of > the patch I > > > > want to give developers one last chance to object: if > > > nobody does that > > > > until tomorrow 2007/06/23 20:00 GMT, then I will: > > > > > > > > (a) apply those radar patches to sg and fg for osg and plib > > > > (b) comment out the "delete rt" in > > > src/Instrumentation/od_gauge.cx:89 > > > > > > > > > > > > > > > > PRO > > > > > > > > + we have a nice c++ radar implementation in both > branches, which > > > > handles arbitrary numbers of AI/MP aircraft, ships, TACAN > > > > emitting and other objects > > > > > > > > + we can drop the quite clumsy and limited & limiting XML radar > > > > implementation > > > > > > > > + fixes a bug in AIManager (ask Vivian :-) > > > > > > > > + instantiates impact sub-submodels in correct order > > > > > > > > > > > > > > > > CONTRA - > > > > > > > > - bigger commit despite the near(?) release, with potential risk > > > > to break something > > > > > > > > BUT: + the patch touches only files that can hardly have side > > > > effects on other subsystems, and isn't executed at all > > > > when aircraft without od_gauge/radar are used (which > > > > is the vast majority). So even if there'd be problems, > > > > they would only affect the E3B, the T38(?), and ... the > > > > harrier? And even then one could comment out the radar > > > > instrument in the XML file and avoid all problems. > > > > > > > >+ the patches were tested by, at least, Vivian, AJ, > > > > Csaba "Jester"(?) and me, and found functional and not > > > > causing problems, except the following (AJ and I): > > > > > > > > - requires to comment out the destruction of the RTT class to > > > > avoid crashes on exit on (some?) nVidia cards. That's hackish, > > > > > > > > BUT: + that's exactly what the 3D clouds are doing > since years! > > > > They don't destruct the RTT class either! Nobody has > > > > reported problems that could be linked to that, none > > > > of the developers has observed such problems (AFAIK). > > > > > > > >+ that's exactly what the TestRenderTexture.cxx test > > > > application by the very author of the RenderTexture > > > > class does. He doesn't destruct the class > either (except > > > > before creating a new one during mode changes on user > > > > request). > > > > > > > >+ it can be assumed that the card frees this resource > > > > like all others, when the context is destroyed, so the > > > > buggy freeing operation via glXDestroyPbuffer() should > > > > be optional in this case. > > > > > > > > m. > > > > > > Hi , I vote for adding it , and I've had that shutdown error > > > since I first used the wxradar ,it's not a new one here... > > > Just my 2 cents worth :). Cheers > > > > > > > That's very interesting information. We suspected that this was a > > longstanding problem, but had no evidence. And does Melchior's fix, > > fix it for you? > > > > V. > > > Hi Vivian, > No I haven't tried the updated version yet ... anxiously > awaiting CVS version ;).But I can try it first if you like , > and see what I get ... Cheers > -- > It would be helpful if you could comment out "delete rt" in src/Instrumentation/od_gauge.cx around line #89, and tell us if that fixes the problem in the old code. Thanks Vivian - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://l
Re: [Flightgear-devel] Help with interfacing other flight models
A great upper hierachy pseudocode document would be very usefull as well. Year ago I outlined one when we were firsr conceiving of the idea for flight gear. (Under my old compuserv address curtis) I haven't been invovled in the programming much since then and would love a guidepost document describing the basic data loops, rendering loops, and calculation loops in a nested structure. On Fri, 22 Jun 2007 11:37 am, Chris Scruggs wrote: > I work with a company that is interested in developing > methods for interfacing one of our products with FlightGear. We > produce and sell a high-fidelity Aerospace Toolkit for the LabVIEW > development environmnet. The Toolkit helps engineers develop > simulations of spacecraft flight for model-based design work. If it > helps in answering the questions product information may be found here > (http://www.atacolorado.com/aerospace_toolkit.htm). We wish to offer > users the ability to interface the simulations they develop > with FlightGear to enhance their visualization options. > > I have searched through the documentaion and read through some of the > source code. However, I am curious if there is a document describing > the overall architecture of FlightGear that is readily available. > > Regards, > > Chris Scruggs > > www.atacolorado.com > > > > Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see > what's on, when. www.GlobalBoiling.com for daily images about hurricanes, globalwarming and the melting poles. www.ElectricQuakes.com daily solar and earthquake images. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] AWOS
This is a drop-in replacement for $FG_ROOT/ATC/default.atis What it is: ATIS, ASOS, AWOS, etc. information from apt.dat, combined with the more festival-friendly names for airports that existed in the old default.atis. Not only the added frequencies, but if my memory serves correct there are relatively recent ATIS frequency changes that are in apt.dat but did not work in FG, I assume they would work now as well. It's basically a stopgap, as doing the right thing would be to parse apt.dat directly and differentiate in dialogs between ATIS/AWOS/ASOS (right now they all appear as ATIS in e.g. the ATC Frequencies box). On IRC it was suggested that hacking apt.dat would be ill-timed as we are waiting for the 850 apt.dat format database to be released. The file is at http://hans.fugal.net/tmp/default.atis -- Hans Fugal Fugal Computing - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
On Fri, 22 Jun 2007 16:56:34 +0100 "Vivian Meazza" <[EMAIL PROTECTED]> wrote: > > > > -Original Message- > Syd > > > Sent: 22 June 2007 15:43 > > To: FlightGear developers discussions > > Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar > > > > > > On Fri, 22 Jun 2007 13:42:16 +0200 > > Melchior FRANZ <[EMAIL PROTECTED]> wrote: > > > > > * Vivian Meazza -- Wednesday 13 June 2007: > > > > Tim Moore has been hard at work recently (with the smallest of > > > > inputs by me), and has ported the improved weather radar already > > > > available for plib to OSG. > > > > > > No objections and other comments since the patches were > > published on > > > 2007/06/20. Because of the nearing release (not that we have the > > > slightest idea when this could be :-) and the nature of the patch I > > > want to give developers one last chance to object: if > > nobody does that > > > until tomorrow 2007/06/23 20:00 GMT, then I will: > > > > > > (a) apply those radar patches to sg and fg for osg and plib > > > (b) comment out the "delete rt" in > > src/Instrumentation/od_gauge.cx:89 > > > > > > > > > > > > PRO > > > > > > + we have a nice c++ radar implementation in both branches, which > > > handles arbitrary numbers of AI/MP aircraft, ships, TACAN > > > emitting and other objects > > > > > > + we can drop the quite clumsy and limited & limiting XML radar > > > implementation > > > > > > + fixes a bug in AIManager (ask Vivian :-) > > > > > > + instantiates impact sub-submodels in correct order > > > > > > > > > > > > CONTRA - > > > > > > - bigger commit despite the near(?) release, with potential risk > > > to break something > > > > > > BUT: + the patch touches only files that can hardly have side > > > effects on other subsystems, and isn't executed at all > > > when aircraft without od_gauge/radar are used (which > > > is the vast majority). So even if there'd be problems, > > > they would only affect the E3B, the T38(?), and ... the > > > harrier? And even then one could comment out the radar > > > instrument in the XML file and avoid all problems. > > > > > >+ the patches were tested by, at least, Vivian, AJ, > > > Csaba "Jester"(?) and me, and found functional and not > > > causing problems, except the following (AJ and I): > > > > > > - requires to comment out the destruction of the RTT class to > > > avoid crashes on exit on (some?) nVidia cards. That's hackish, > > > > > > BUT: + that's exactly what the 3D clouds are doing since years! > > > They don't destruct the RTT class either! Nobody has > > > reported problems that could be linked to that, none > > > of the developers has observed such problems (AFAIK). > > > > > >+ that's exactly what the TestRenderTexture.cxx test > > > application by the very author of the RenderTexture > > > class does. He doesn't destruct the class either (except > > > before creating a new one during mode changes on user > > > request). > > > > > >+ it can be assumed that the card frees this resource > > > like all others, when the context is destroyed, so the > > > buggy freeing operation via glXDestroyPbuffer() should > > > be optional in this case. > > > > > > m. > > > > Hi , I vote for adding it , and I've had that shutdown error > > since I first used the wxradar ,it's not a new one here... > > Just my 2 cents worth :). Cheers > > > > That's very interesting information. We suspected that this was a > longstanding problem, but had no evidence. And does Melchior's fix, fix it > for you? > > V. > Hi Vivian, No I haven't tried the updated version yet ... anxiously awaiting CVS version ;).But I can try it first if you like , and see what I get ... Cheers -- syd & sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Help with interfacing other flight models
I work with a company that is interested in developing methods for interfacing one of our products with FlightGear. We produce and sell a high-fidelity Aerospace Toolkit for the LabVIEW development environmnet. The Toolkit helps engineers develop simulations of spacecraft flight for model-based design work. If it helps in answering the questions product information may be found here (http://www.atacolorado.com/aerospace_toolkit.htm). We wish to offer users the ability to interface the simulations they develop with FlightGear to enhance their visualization options. I have searched through the documentaion and read through some of the source code. However, I am curious if there is a document describing the overall architecture of FlightGear that is readily available. Regards, Chris Scruggs www.atacolorado.com - Sick sense of humor? Visit Yahoo! TV's Comedy with an Edge to see what's on, when. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
> -Original Message- Syd > Sent: 22 June 2007 15:43 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar > > > On Fri, 22 Jun 2007 13:42:16 +0200 > Melchior FRANZ <[EMAIL PROTECTED]> wrote: > > > * Vivian Meazza -- Wednesday 13 June 2007: > > > Tim Moore has been hard at work recently (with the smallest of > > > inputs by me), and has ported the improved weather radar already > > > available for plib to OSG. > > > > No objections and other comments since the patches were > published on > > 2007/06/20. Because of the nearing release (not that we have the > > slightest idea when this could be :-) and the nature of the patch I > > want to give developers one last chance to object: if > nobody does that > > until tomorrow 2007/06/23 20:00 GMT, then I will: > > > > (a) apply those radar patches to sg and fg for osg and plib > > (b) comment out the "delete rt" in > src/Instrumentation/od_gauge.cx:89 > > > > > > > > PRO > > > > + we have a nice c++ radar implementation in both branches, which > > handles arbitrary numbers of AI/MP aircraft, ships, TACAN > > emitting and other objects > > > > + we can drop the quite clumsy and limited & limiting XML radar > > implementation > > > > + fixes a bug in AIManager (ask Vivian :-) > > > > + instantiates impact sub-submodels in correct order > > > > > > > > CONTRA - > > > > - bigger commit despite the near(?) release, with potential risk > > to break something > > > > BUT: + the patch touches only files that can hardly have side > > effects on other subsystems, and isn't executed at all > > when aircraft without od_gauge/radar are used (which > > is the vast majority). So even if there'd be problems, > > they would only affect the E3B, the T38(?), and ... the > > harrier? And even then one could comment out the radar > > instrument in the XML file and avoid all problems. > > > >+ the patches were tested by, at least, Vivian, AJ, > > Csaba "Jester"(?) and me, and found functional and not > > causing problems, except the following (AJ and I): > > > > - requires to comment out the destruction of the RTT class to > > avoid crashes on exit on (some?) nVidia cards. That's hackish, > > > > BUT: + that's exactly what the 3D clouds are doing since years! > > They don't destruct the RTT class either! Nobody has > > reported problems that could be linked to that, none > > of the developers has observed such problems (AFAIK). > > > >+ that's exactly what the TestRenderTexture.cxx test > > application by the very author of the RenderTexture > > class does. He doesn't destruct the class either (except > > before creating a new one during mode changes on user > > request). > > > >+ it can be assumed that the card frees this resource > > like all others, when the context is destroyed, so the > > buggy freeing operation via glXDestroyPbuffer() should > > be optional in this case. > > > > m. > > Hi , I vote for adding it , and I've had that shutdown error > since I first used the wxradar ,it's not a new one here... > Just my 2 cents worth :). Cheers > That's very interesting information. We suspected that this was a longstanding problem, but had no evidence. And does Melchior's fix, fix it for you? V. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
On Fri, 22 Jun 2007 13:42:16 +0200 Melchior FRANZ <[EMAIL PROTECTED]> wrote: > * Vivian Meazza -- Wednesday 13 June 2007: > > Tim Moore has been hard at work recently (with the smallest of inputs by > > me), and has ported the improved weather radar already available for plib to > > OSG. > > No objections and other comments since the patches were published > on 2007/06/20. Because of the nearing release (not that we have > the slightest idea when this could be :-) and the nature of the > patch I want to give developers one last chance to object: if > nobody does that until tomorrow 2007/06/23 20:00 GMT, then I will: > > (a) apply those radar patches to sg and fg for osg and plib > (b) comment out the "delete rt" in src/Instrumentation/od_gauge.cx:89 > > > > PRO > > + we have a nice c++ radar implementation in both branches, which > handles arbitrary numbers of AI/MP aircraft, ships, TACAN > emitting and other objects > > + we can drop the quite clumsy and limited & limiting XML radar > implementation > > + fixes a bug in AIManager (ask Vivian :-) > > + instantiates impact sub-submodels in correct order > > > > CONTRA - > > - bigger commit despite the near(?) release, with potential risk > to break something > > BUT: + the patch touches only files that can hardly have side > effects on other subsystems, and isn't executed at all > when aircraft without od_gauge/radar are used (which > is the vast majority). So even if there'd be problems, > they would only affect the E3B, the T38(?), and ... the > harrier? And even then one could comment out the radar > instrument in the XML file and avoid all problems. > >+ the patches were tested by, at least, Vivian, AJ, > Csaba "Jester"(?) and me, and found functional and not > causing problems, except the following (AJ and I): > > - requires to comment out the destruction of the RTT class to > avoid crashes on exit on (some?) nVidia cards. That's hackish, > > BUT: + that's exactly what the 3D clouds are doing since years! > They don't destruct the RTT class either! Nobody has > reported problems that could be linked to that, none > of the developers has observed such problems (AFAIK). > >+ that's exactly what the TestRenderTexture.cxx test > application by the very author of the RenderTexture > class does. He doesn't destruct the class either (except > before creating a new one during mode changes on user > request). > >+ it can be assumed that the card frees this resource > like all others, when the context is destroyed, so the > buggy freeing operation via glXDestroyPbuffer() should > be optional in this case. > > m. Hi , I vote for adding it , and I've had that shutdown error since I first used the wxradar ,it's not a new one here... Just my 2 cents worth :). Cheers -- syd & sandy <[EMAIL PROTECTED]> - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] AWOS
I fly a lot of general aviation at small airports without ATIS, and where there is no controlled airport for miles around. There are two frustrations I experience with flightgear in these situations: 1. The ATC/Frequencies box always says there's nothing within 40 nm. But in many cases there *is* an airport with ATIS close enough to receive ATIS (but not within 40 nm). Maybe this radius could be expanded, at least when nothing else was found? My local area happens to be a pathological case: KLRU is 40.7nm from KELP. 2. A lot of these airports, and almost always one within range no matter how remote you get (in the US anyway), have ASOS or AWOS (basically, almost everywhere you have a METAR you have either ATIS or ASOS/AWOS). They're essentially the same as ATIS, at least in all the ways that matter. FlightGear's database has these frequencies, but you hear nothing when tuning to them. The first point is a minor inconvenience, since a good pilot should be gathering things like radio frequencies *before* flying. :-) The second point makes it hard to get in-sim weather information (without "cheating" by looking at the weather scenario METAR) out west. I imagine the ASOS/AWOS thing might be a simple matter of expanding the search for frequencies somewhere. If someone can point me to the right area in the code I can probably work out a patch. -- Hans Fugal Fugal Computing - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [ANN] OSG - Improved Weather Radar
* Vivian Meazza -- Wednesday 13 June 2007: > Tim Moore has been hard at work recently (with the smallest of inputs by > me), and has ported the improved weather radar already available for plib to > OSG. No objections and other comments since the patches were published on 2007/06/20. Because of the nearing release (not that we have the slightest idea when this could be :-) and the nature of the patch I want to give developers one last chance to object: if nobody does that until tomorrow 2007/06/23 20:00 GMT, then I will: (a) apply those radar patches to sg and fg for osg and plib (b) comment out the "delete rt" in src/Instrumentation/od_gauge.cx:89 PRO + we have a nice c++ radar implementation in both branches, which handles arbitrary numbers of AI/MP aircraft, ships, TACAN emitting and other objects + we can drop the quite clumsy and limited & limiting XML radar implementation + fixes a bug in AIManager (ask Vivian :-) + instantiates impact sub-submodels in correct order CONTRA - - bigger commit despite the near(?) release, with potential risk to break something BUT: + the patch touches only files that can hardly have side effects on other subsystems, and isn't executed at all when aircraft without od_gauge/radar are used (which is the vast majority). So even if there'd be problems, they would only affect the E3B, the T38(?), and ... the harrier? And even then one could comment out the radar instrument in the XML file and avoid all problems. + the patches were tested by, at least, Vivian, AJ, Csaba "Jester"(?) and me, and found functional and not causing problems, except the following (AJ and I): - requires to comment out the destruction of the RTT class to avoid crashes on exit on (some?) nVidia cards. That's hackish, BUT: + that's exactly what the 3D clouds are doing since years! They don't destruct the RTT class either! Nobody has reported problems that could be linked to that, none of the developers has observed such problems (AFAIK). + that's exactly what the TestRenderTexture.cxx test application by the very author of the RenderTexture class does. He doesn't destruct the class either (except before creating a new one during mode changes on user request). + it can be assumed that the card frees this resource like all others, when the context is destroyed, so the buggy freeing operation via glXDestroyPbuffer() should be optional in this case. m. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
