Re: [Flightgear-devel] Redhat (vs debian) / BSD OK?
The problems people have with the xBSD have nothing to do with FGFS. Once you've got all the dependencies (i.e. GL, PLIB, MK, etc) working, You might get in trouble with some graphics boards that are not supported by XFree86/DRI. I know that there is a project to build something that is comparable to the NVidia Linux kernel module but I don't know by now how far development has gone now, 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] Redhat (vs debian) / BSD OK?
FWIW on a SuSE 7.3 system I had to downgrade (install parallel actually) autoconf. Just pointing out SuSE needed a little tweak too. I would'nt call it that way. Autoconf on SuSE-7.3 works pretty nice. The only tweak is that you have to run 'aclocal' with '-I .'. I know this because I do build FlightGear from CVS on a daily basis, using SuSE-7.3. I once asked to include this into the 'autogen.sh' script but nobody noticed, so I'm running my own stuff: # ls CVS /dev/null (libtoolize --copy --force; aclocal -I .; autoheader; automake -a; autoconf) 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] How to define a new airport
I'd like to define a new airport. How can I do that ? Is there any paper talking about it ? There is FlightGear/docs-mini/AptNavFAQ.FlightGear.html with lots of useful information but I have the impression that you need to regenerate scenery at this location to include the new airport. [...] Is there any place where we can get coordinates of all airports around the world ? http://www.aircraft-charter-world.com/airports/ http://www.worldaerodata.com/ These might serve as a starting point. But they list only those who are officially 'open'. BTW, if anyone has data on FX01 (Chambley Airbase in France where the annual RSA meeting takes place) - o.k., I admit, I'm repeating myself 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] Why not use assert()?
Hello, what's wrong with using #include assert.h ... assert(some_condition); instead of that Null Pointer assignment? Regards, Nicolai ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Flightgear, FS2K2 and GMAX
David wrote: Wolfram mentioned that GMAX-exported models don't work with PLIB anyway. Yes, you can not load the gmax generated MDLs. You can try to use Quake models as intermdediary file or maybe with Middleman http://takeoff.to/landing you could get an *.x file. I have not had time to try either option myself yet, sorry. In other cases, the best bet would probably be to load the model into PPE, name the appropriate objects, then export it to some other format for FlightGear to use. Unfortunately, PLIB can generate many thousands of nodes. But we only need the names for the gear, props etc, which should IMHO work automatically for MDLs that you can import. All the best, David Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: SuSE new release ad page
Alex Perry wrote: http://www.suse.com/us/products/suse_linux/i386/games.html nearly the same text as for 7.3: http://www.suse.com/us/products/suse_linux/73/games.html CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: SuSE new release ad page
http://www.suse.com/us/products/suse_linux/i386/games.html Yep, I've been pushing them a bit to make a build of the new release of FlightGear :-) Unfortunately this will not include all the nice stuff that went in in the meantime (c310 crashes on gear retraction ;-). I'll figure out how to build a suitable replacement' package from the CVS tree, 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] Anyone recognize this problem?
William Earnest writes: In file included from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../. ./include/g++-3/iostream.h:31, This doesn't look good -- somehow, include files from G++ 2.95.2 and G++ 3.0 seem to be getting mixed up. 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] Blinking model lights
Jim Wilson writes: If I was going to add blinking lights to the model animation code, how would I do the timing? This is still on my TODO list, together with LOD and other conditional hiding and showing. Were you thinking of blinking by swapping objects, or by changing colour/texture? 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] Redhat (vs debian) / BSD OK?
Greg Long writes: My question is primarily this: Other that personal preference, is there any major need to install Debian over RedHat Linux 7.2 for FlighGear development? I notice the gcc issue in the FAQ, but I should be cool on that with 7.2, though I'll check. I think that we have many RedHat users working with FlightGear, so there should be no problem. We'll convert you to Debian some other time. I have a friend who might join in as well, and he has an OpenBSD setup. If there are any known issues with FlightGear work on that platform please advise. That's great -- I think we have very few OpenBSD users, and the more the merrier for hunting down bugs, etc. 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] How to define a new airport
Sergio Roth writes: I'd like to define a new airport. How can I do that ? Is there any paper talking about it ? Is there any place where we can get coordinates of all airports around the world ? The airports are defined in $FG_ROOT/Airports/default.apt.gz, but they don't appear on the fly -- you have to rebuild your scenery using TerraGear, and that's non-trivial. I'd like to add dynamic airport generation at some point in the future, but it's a big job. 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] ARGGHHH !
Alex Perry writes: Fair enough. I certainly overengineered props.[ch]xx, in anticipation of all kinds of sophisticated stuff that people never bothered doing. I've been learning, slowly, from the XP people to build only for today (all my training previously was to anticipate future needs, and it's hard to let that go). It's nice to have a concept that can support all that stuff if/when we have an excuse to make use of it. Put the methods and stuff into the header file, with a comment that they are not implemented yet, and have the implementations break if used. That makes it easier to have backward compatible code when the snazzy features get added. Yes, except that I think we're paying a price with a couple of levels of unnecessary indirection and with code that no one but me can understand. I'd like to keep most of the user-level stuff intact, but to remove the developer-level stuff we're not actually using and reduce the number of layers. One thing that has impressed me about Andy Ross's code over most of the rest of FlightGear (including any of my own contributions that I haven't looked at for a few months) is that I was able to understand most of his code immediately. Part of that is because he uses good, clear design patterns, but a lot of it is because he is a good practitioner of worse-is-better: when in doubt seems to err on the side of leaving stuff out rather than putting it in. From my experience both on open source and on large commercial projects, I've come to agree entirely with the XP people on certain points: 1. Never write code that you don't need right now, and never make a design more complicated than it needs to be for today. On average, it's cheaper to add one new feature later, when it's needed, than to waste time and obfuscate code by adding twenty new features now purely on spec. 2. Deleting code is as important as writing code. Never leave old code lying around. Instead of commenting or #ifdef'ing stuff out, delete it. If no one's using a particular class or method any more, delete it. If only a class or method is used in only a couple of places, try refactoring the code to use a different approach then delete the class or method. Curt and I disagree on the second point but try (most of the time) to respect each-other's opinions. Personally, I believe that (especially with CVS and ediff-revision in XEmacs for restoring old stuff) the cost of leaving in a lot of commented-out old code is painfully high -- it makes the code hard to understand and maintain, so people tend not to touch it until either something breaks or the whole development stalls. We have to try to write code that a new developer can understand the first time through, and that means keeping it short and simple and avoiding indirection and subclassing wherever possible (the last point shouldn't be controversial, since modern OO design frowns on excessive subclassing anyway). For the record, I don't agree with the XP people on team programming or the unimportance of documentation. 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] Norman's change and the PointInTriangle
Alex Perry writes: Can we patch the sgdPointInTriangle back to PointInTriangle _and_ keep the improvements from Norman in the tree ? I think we just need to #ifdef for the PLIB version. 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] simple tower view
Michael Selig writes: I am wondering does the view manager work-in-progress support a simple tower view at this stage? Having gone from our non-CVS tower view in 0.7.8 to a recent CVS checkout leaves me wishing for more. Jim Wilson is working on the rewrite. We do plan to support tower view (and other interesting views) very soon, but I don't know if it will be in the first take or not. 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] simple tower view
Michael Selig writes: That would be nice, but even something simple that puts the viewpoint 200 ft above the runway behind the aircraft would be great to start with. That view is a help when building and testing the new aircraft models. It also makes the sim well-primed for R/C use. We have a center lon/lat/alt for every airport. For small airports, unfortunately, that's often the runway center, but it should still be useful as a starting tower location until we have better data. 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_hitlist
Norman Vine wrote: Erik Hofman writes: Norman Vine wrote: I'd better just go back into lurk mode I guess Preferably not. The code improves the framerate by a factor which you meantioned earlier, but also makes the framerate quite steady. So you must have done something right! The routine is useless if it isn't perfect though :-( Well that's been solved. Thanks! But as you say the improvement is rather dramatic esp. when in the vicinity of an airport and it's MANY 'teeny' triangles :-) I'm realy impressed by the effect of the code. The higher I get, the higher the framerate! This makes me believe we could actually enlarge the view range when getting at a higher altitude. I start from 10 fps on the runway all the way up to 22 fps at 5000 feet (when starting with --disable-skyblend). Deactivating the textures at that altitude gives even 27 fps! This *must* be the right way. ;-) Thanks again Norman. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley writes: I have made an attempt to describe the contents of 'preferences.xml.' Could someone knowledgeable in the properties list and preferences.xml file let me know if I am understanding things correctly? Also, is there any information about what each component of FlightGear needs from the property list (i.e., the various FDMs, etc.)? http://homepage.mac.com/eq_fidget/FG_Dox/preferences_xml.html Just to start, the property tree has nothing to do with Metakit -- we use Metakit only to hold airport and navaid data. path Aircraft/c172/Panels/c172-vfr-panel.xml/ path This tells FlightGear where it can find the configuration information for the aircraft. It is the same as using the '--aircraft-dir=' option. Actually, this is the path to the default instrument panel. --aircraft-dir is a special option used only by UIUC. Thanks for starting on this -- it's much needed. 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] simple tower view
David Megginson wrote: Michael Selig writes: I am wondering does the view manager work-in-progress support a simple tower view at this stage? Having gone from our non-CVS tower view in 0.7.8 to a recent CVS checkout leaves me wishing for more. Jim Wilson is working on the rewrite. We do plan to support tower view (and other interesting views) very soon, but I don't know if it will be in the first take or not. Talking about views. Currently when looking around in the cockpit you turn around a single point (if I recall it correctly). Wouldn't it be nessercary to actually incoorporate the eye distance from the middle of the head into that action (and limit the rotation to about 270 degrees). It would seem more natural that way (for me at least ;-)) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
Erik Hofman writes: I'm realy impressed by the effect of the code. The higher I get, the higher the framerate! This makes me believe we could actually enlarge the view range when getting at a higher altitude. Cool glad it works for you but IMHO what is needed are imposter tiles imposters are where you use a 'texture only substitute for the geometry that are computed on the fly 'often enough' This is 'radical' LOD but in our case the tiles out on the boundary are really just 'little slivers' and there is no need for anyting else. I would think that we could easily lump many tiles together into these impostors to form a 2 level ring of 'near' and 'far' impostors around our current scenery. This will of course work best for slow flying aircraft but I don't see any need for these impostors to need to be updated ie regenerated any more often then say once per tile change for the near impostors and once every 'several' tile changes for the 'far impostors''. This of course could be spread out over tile change period so the effect on the frame rate should be quite small certainly less then the improvement the new hitlist gives . Doing something like this would allow flying with an effective tile radius of at least an order of magnitude greater then what you can do now at almost the same fps :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
Erik Hofman writes: I'm realy impressed by the effect of the code. The higher I get, the higher the framerate! This makes me believe we could actually enlarge the view range when getting at a higher altitude. This would be really nice for very high flying (X) aircraft. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
David Megginson writes: One thing that has impressed me about Andy Ross's code over most of the rest of FlightGear (including any of my own contributions that I haven't looked at for a few months) is that I was able to understand most of his code immediately. Part of that is because he uses good, clear design patterns, but a lot of it is because he is a good practitioner of worse-is-better: when in doubt seems to err on the side of leaving stuff out rather than putting it in. From my experience both on open source and on large commercial projects, I've come to agree entirely with the XP people on certain points: 1. Never write code that you don't need right now, and never make a design more complicated than it needs to be for today. On average, it's cheaper to add one new feature later, when it's needed, than to waste time and obfuscate code by adding twenty new features now purely on spec. I know you are making a point by using extereme wording, but if you are running through the woods, it doesn't hurt to look up once in a while. 2. Deleting code is as important as writing code. Never leave old code lying around. Instead of commenting or #ifdef'ing stuff out, delete it. If no one's using a particular class or method any more, delete it. If only a class or method is used in only a couple of places, try refactoring the code to use a different approach then delete the class or method. Curt and I disagree on the second point but try (most of the time) to respect each-other's opinions. Perhaps you misunderstand my position. It's one thing to delete crufty old useless code. However, there may be reasons to keep old code #ifdef'd in. And it certainly doesn't hurt to ask before you delete someone else's old code. Personally, I believe that (especially with CVS and ediff-revision in XEmacs for restoring old stuff) the cost of leaving in a lot of commented-out old code is painfully high -- it makes the code hard to understand and maintain, so people tend not to touch it until either something breaks or the whole development stalls. I think there needs to be a balance here. Yes, cruft can get in the way, but code represents knowledge. Code represents experience. Code is the solution to a problem. For myself personally, if I am the author of a section of code, and if I am the one who has to maintain it and answer questions, I *certainly* should have the right to leave comments and hints and 'knowledge' and 'experience' included in that body of code. There may be very good reasons why the author includes it that aren't immediately obvious. If something doesn't make sense, or seems out of place, there's no harm in asking ... perhaps the author will look at the 'cruft' and say oh yea, nothing valuable there, we can axe it. But perhaps the code is there is for valid reasons and it's worth keeping. We have to try to write code that a new developer can understand the first time through, and that means keeping it short and simple and avoiding indirection and subclassing wherever possible (the last point shouldn't be controversial, since modern OO design frowns on excessive subclassing anyway). Yup, on this point I agree with you completely. 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] ARGGHHH !
David Megginson writes: For the record, I don't agree with the XP people on team programming Hopefully you will eventually come to embrace that concept too. :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] Redhat (vs debian) / BSD OK?
On Sun, 17 Mar 2002, David Megginson wrote: I think that we have many RedHat users working with FlightGear, so there should be no problem. We'll convert you to Debian some other time. distro holy war At this point I'll just add that Slackware users don't have any problems - it flightgear is happy on a default install. /distro holy war :-) -- Jon StockillPublic Key: C6BD585D [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Curtis L. Olson writes: I know you are making a point by using extereme wording, but if you are running through the woods, it doesn't hurt to look up once in a while. I preached full interface design in advance through much of the 1990s -- it seemed like a good idea. I now freely renounce that view. Dead code is just too expensive to keep around; I'm willing to bet that FlightGear contributors spend more time trying to understand existing code (including mine) than writing new code. Perhaps you misunderstand my position. It's one thing to delete crufty old useless code. However, there may be reasons to keep old code #ifdef'd in. This is where we disagree -- keeping it in makes the code much harder for new (and existing) contributors to read and understand, gives false hits when searching for variables and method calls, etc. etc. With CVS, it's trivially easy to look at or restore old code later if we need to; I'm strongly in favour of keeping the onscreen code short, clean, and uncluttered. Unlike the XP people, however, I am a big supporter of explanatory comments. There are parts of FlightGear that have a single, well-known maintainer (such as YASim or WeatherCM), but a lot of the dead code is in the well-trodden public corridors of FlightGear, like fg_init.cxx, main.cxx, etc. 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] ARGGHHH !
This is where we disagree -- keeping it in makes the code much harder for new (and existing) contributors to read and understand, gives false hits when searching for variables and method calls, etc. etc. With CVS, it's trivially easy to look at or restore old code later if we need to; I'm strongly in favour of keeping the onscreen code short, clean, and uncluttered. Unlike the XP people, however, I am a big supporter of explanatory comments. There are parts of FlightGear that have a single, well-known maintainer (such as YASim or WeatherCM), but a lot of the dead code is in the well-trodden public corridors of FlightGear, like fg_init.cxx, main.cxx, etc. I ran into this problem when looking through FlightGear code in the past. It's hard to keep track of things like: #ifdef xxx ... ... 200 lines of code ... ... #else ... ... 100 lines of code ... ... #endif If the page being shown does not show the #ifdef, it can be really confusing. I can't recall any specific examples of this in the code, but I remember being bitten by this kind of thing a couple of times when perusing some of the base FlightGear code. Elimination of dead code (as we all know, CVS is really good for tracking past changes) and better documentation would be really helpful. We'd like to be better in JSBSim too - we all face this. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Just to start, the property tree has nothing to do with Metakit -- we use Metakit only to hold airport and navaid data. I will make that change. path Aircraft/c172/Panels/c172-vfr-panel.xml/ path This tells FlightGear where it can find the configuration information for the aircraft. It is the same as using the '--aircraft-dir=' option. Actually, this is the path to the default instrument panel. --aircraft-dir is a special option used only by UIUC. Thanks for starting on this -- it's much needed. Some of the other XML files are rather easy to figure out (i.e,. keyboard. xml), but others are not (i.e., the FDM specific files). Does anyone have anything written that describes these? The materials.xml file has quite a nice description at the top. Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Help with XML and preferences.xml
Some of the other XML files are rather easy to figure out (i.e,. keyboard. xml), but others are not (i.e., the FDM specific files). Does anyone have anything written that describes these? The materials.xml file has quite a nice description at the top. Can you let us know what is unclear in the FDM files so we can write up a better explanation? Thanks, Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Redhat (vs debian) - DEBIAN ISO's obtained
I might go ahead and give Debian a shot on the install, seems like the distro of choice, and I have a separate Redhat box (233mhz, don't think its S3 Virge supports OpenGL, I'd have to look) but I could use that for testing Debian seems to be the choice by large, and if it supports rpm's I might as well muck around with it for a bit. Despite RedHat's many publicized issues, I will give them credit - the GUI install is smooth and painless, and works like a champ on the 4 systems I have tried 7.2 on. The text installer is just as easy really. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jon Stockill Sent: Sunday, March 17, 2002 6:08 AM To: [EMAIL PROTECTED] Subject: re: [Flightgear-devel] Redhat (vs debian) / BSD OK? On Sun, 17 Mar 2002, David Megginson wrote: I think that we have many RedHat users working with FlightGear, so there should be no problem. We'll convert you to Debian some other time. distro holy war At this point I'll just add that Slackware users don't have any problems - it flightgear is happy on a default install. /distro holy war :-) -- Jon StockillPublic Key: C6BD585D [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] Redhat (vs debian) - DEBIAN ISO's obtained
I forgot to say that Debian must REALLY hide their ISO's - I had to get these from www.linuxiso.org Hopefully they boot OKburning ISO #1 right now. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Greg Long Sent: Sunday, March 17, 2002 8:24 AM To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] Redhat (vs debian) - DEBIAN ISO's obtained I might go ahead and give Debian a shot on the install, seems like the distro of choice, and I have a separate Redhat box (233mhz, don't think its S3 Virge supports OpenGL, I'd have to look) but I could use that for testing Debian seems to be the choice by large, and if it supports rpm's I might as well muck around with it for a bit. Despite RedHat's many publicized issues, I will give them credit - the GUI install is smooth and painless, and works like a champ on the 4 systems I have tried 7.2 on. The text installer is just as easy really. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jon Stockill Sent: Sunday, March 17, 2002 6:08 AM To: [EMAIL PROTECTED] Subject: re: [Flightgear-devel] Redhat (vs debian) / BSD OK? On Sun, 17 Mar 2002, David Megginson wrote: I think that we have many RedHat users working with FlightGear, so there should be no problem. We'll convert you to Debian some other time. distro holy war At this point I'll just add that Slackware users don't have any problems - it flightgear is happy on a default install. /distro holy war :-) -- Jon StockillPublic Key: C6BD585D [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 ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Help with XML and preferences.xml
Jonathan Polley writes: Some of the other XML files are rather easy to figure out (i.e,. keyboard. xml), but others are not (i.e., the FDM specific files). YASim and JSBSim each uses its own XML format, which is different from the XML format used by the rest of FlightGear. For YASim, see $FG_ROOT/Aircraft-yasim/README.yasim in the base package; for JSBSim, see the documentation at http://jsbsim.sourceforge.net/. UIUC uses a non-XML config-file format. 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] ARGGHHH !
Jon Berndt writes: Elimination of dead code (as we all know, CVS is really good for tracking past changes) and better documentation would be really helpful. We'd like to be better in JSBSim too - we all face this. Absolutely. While I don't tend to keep #ifdef's around, some of my code is pretty badly obfuscated right now, so I need to take care of the beam in my own eye before I do too much more preaching about everyone else's slivers. 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] simple tower view
Michael Selig [EMAIL PROTECTED] said: That would be nice, but even something simple that puts the viewpoint 200 ft above the runway behind the aircraft would be great to start with. That view is a help when building and testing the new aircraft models. It also makes the sim well-primed for R/C use. Regards, Michael Try the pilot offset dialog on the menu. With the dials you can position the eye anywhere on a sphere from 1 to 100 meters radius from the model. It is great for testing model animations. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Redhat (vs debian) - DEBIAN ISO's obtained
Greg Long writes: I might go ahead and give Debian a shot on the install, seems like the distro of choice, and I have a separate Redhat box (233mhz, don't think its S3 Virge supports OpenGL, I'd have to look) but I could use that for testing Debian seems to be the choice by large, and if it supports rpm's I might as well muck around with it for a bit. Debian is a bear to install but a dream to maintain. While Magic Carpet makes it easier than it used to be to pull in security fixes and bug patches for a specific version of RedHat, it doesn't help upgrading from one version to another. In Debian, when you're ready to move from, say, potato, to woody or sid, you just update the paths in /etc/apt/sources.list, then type apt-get update apt-get dist-upgrade To move from one RedHat version to another, I usually had to reformat my hard drive. 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] Help with XML and preferences.xml
On Sunday, March 17, 2002, at 09:53 AM, Jon Berndt wrote: Some of the other XML files are rather easy to figure out (i.e,. keyboard. xml), but others are not (i.e., the FDM specific files). Does anyone have anything written that describes these? The materials.xml file has quite a nice description at the top. Can you let us know what is unclear in the FDM files so we can write up a better explanation? I think this is more along the lines of my not what is important to each FDM when it comes to configuration. If I wanted to configure a Boeing 707 model by modifying a 747 model, what is needed for each FDM type? When I look in YASim, I see quite a bit of information, but I don't know what it pertinent. What does it mean to add or remove an engine to the various FDMs? How do I define the characteristics of an engine? All of these questions come about because I am unfamiliar with how the FDMs are put together and how they work. My documentation effort is driven by my lack of understanding on how things work, and my assumption that I am not the only one ;) On that topic, I have some updates to the preferences.xml documentation http://homepage.mac.com/eq_fidget/FG_Dox/preferences_xml.html Thanks for the info, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Redhat (vs debian) - DEBIAN ISO's obtained
On Sun, 2002-03-17 at 09:22, David Megginson wrote: Greg Long writes: I might go ahead and give Debian a shot on the install, seems like the distro of choice, and I have a separate Redhat box (233mhz, don't think its S3 Virge supports OpenGL, I'd have to look) but I could use that for testing Debian seems to be the choice by large, and if it supports rpm's I might as well muck around with it for a bit. Debian is a bear to install but a dream to maintain. While Magic Carpet makes it easier than it used to be to pull in security fixes and bug patches for a specific version of RedHat, it doesn't help upgrading from one version to another. In Debian, when you're ready to move from, say, potato, to woody or sid, you just update the paths in /etc/apt/sources.list, then type apt-get update apt-get dist-upgrade To move from one RedHat version to another, I usually had to reformat my hard drive. Which isn't to say that apt-get, dpkg, dselect, et.al. don't have their own warts. For example, Red Carpet seems to be good about telling you what's going on whereas with apt-get, AFAICT, its really hard to find out why apt-get upgrade won't install something. That said, however, it does seem to be true that you'll only ever need to install Debian once on a given system. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Redhat (vs debian) - DEBIAN ISO's obtained
I forgot to say that Debian must REALLY hide their ISO's - I had to get these from www.linuxiso.org Hopefully they boot OKburning ISO #1 right now. That's because nobody pays them for the bandwidth. They'd rather you use someone else's bandwidth, or borrow a CD from someone else, or buy one. After all, you only need that CD exactly once per computer system. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
If the page being shown does not show the #ifdef, it can be really confusing. I can't recall any specific examples of this in the code, but I remember being bitten by this kind of thing a couple of times when perusing some of the base FlightGear code. Some of it is simply people being polite and leaving another developer's code in the file rather than deleting it for them. However, unless the person who #ifdef'ed the code tells the other developer to look at it, this is unlikely to be noticed and thereafter deleted. Elimination of dead code (as we all know, CVS is really good for tracking past changes) and better documentation would be really helpful. We'd like to be better in JSBSim too - we all face this. How about doing this kind of diff ? /* The clever function was removed from the CVS after rev 2.13.4 */ int clever() [] Anybody who is interested can cvs update back to that version and read it through ... without cluttering things up. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] simple tower view
Erik Hofman [EMAIL PROTECTED] said: Talking about views. Currently when looking around in the cockpit you turn around a single point (if I recall it correctly). Wouldn't it be nessercary to actually incoorporate the eye distance from the middle of the head into that action (and limit the rotation to about 270 degrees). It would seem more natural that way (for me at least ;-)) Did you see The Exorcist? :-D Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] simple tower view
At 3/17/02, you wrote: Michael Selig writes: I am wondering does the view manager work-in-progress support a simple tower view at this stage? Having gone from our non-CVS tower view in 0.7.8 to a recent CVS checkout leaves me wishing for more. Jim Wilson is working on the rewrite. We do plan to support tower view (and other interesting views) very soon, but I don't know if it will be in the first take or not. All the best, David -- David Megginson [EMAIL PROTECTED] Sounds very good! ** Prof. Michael S. Selig Dept. of Aero/Astro Engineering University of Illinois at Urbana-Champaign 306 Talbot Laboratory 104 South Wright Street Urbana, IL 61801-2935 (217) 244-5757 (o), (509) 691-1373 (fax) mailto:[EMAIL PROTECTED] http://www.uiuc.edu/ph/www/m-selig http://www.uiuc.edu/ph/www/m-selig/faq.html (FAQ) ** ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Anyone recognize this problem?
On Sat, 16 Mar 2002 18:15:41 -0500, William Earnest [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Hello, Wound up rearranging some hardware, and am trying to move FlightGear to a faster machine. Sytem is based on RH-7.1 as was the previous, but with a /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../. ./include/g++-3/iostream.h:31, ..this is a new install? I'd get RH72 and all erratas, gcc is now at version 3.0.4-1. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
Norman Vine writes: IMHO the biggest obstacle to reading and developing FGFS code is the formatting We really need a mechanical formating means that is acceptable to every one as the CVS standard even if it is not perfect or even close to what one would personally use. When I've looked, I've not found any acceptably tools to do automatic formatting of C++ code. The *very* few tools that did exist either were far too simplistic and weren't to the point of actually being useful or made horrible awful choices without providing a way to override those choices. The closest thing I've found to a usable tool is emacs, but that is interactive and not something you can batch, and it is very limitted in what it does and occasionally does some ugly stuff too. FWIW, I try to fix really poorly / inconsistantly formated code as it's submitted, but I'm not perfect either. This way everyone could format the code in a way that helped them understand it and the CVS maintainers could easily compare submissions against existing code FWIW I find a large percentage of the code very difficult to read because of indentation does not match structure and lack of whitespace I know that Curt often has had a difficult time with my submissioons because of massive whitespace change but in all due respect the majority of these changes were necessary inorder fo me to understand the code. With all corresponding due respect, these white space changes may help you understand the code, but they are anything but consistant, and they rarely follow the conventions of the code you are tweaking. That IMHO just makes things a lot messier and harder for anyone else to read. I realize that this is a 'religous' issue and a 'tough' problem but IMHO it is a major obstacle to FGFS code evolution I'd be happy if somewone could find a decent code [re]formatter that gave us enough flexibility to make our own style choices and didn't have glaring ommission or do really stupid things. BTW, Norman, are you having fun hitting all the religeous hot buttons here since your return? :-) 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] ARGGHHH !
David Megginson writes: I disagree that this is the biggest obstacle (or even one of the top 10), but then, I use an editor (XEmacs) with syntax highlighting, brace matching, language-based navigation (jump forward one function), etc., so those features might be hiding the problem from me. That said, I do agree that this is a problem. We probably need a standard coding style for FlightGear code, preferably one that is preinstalled in most programmers' editors. The question is whether we have anyone with cycles available to lead discussion on this and clean up the existing code base. Personally, I've looked, and I've not found any tools that actually do a reasonable job. If we do come up with a style guide it will probably piss off 100% of us. If this is a problem in the top 10, it's definitely not in the top 5. 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] ARGGHHH !
Curtis L. Olson [EMAIL PROTECTED] said: If something doesn't make sense, or seems out of place, there's no harm in asking ... perhaps the author will look at the 'cruft' and say oh yea, nothing valuable there, we can axe it. But perhaps the code is there is for valid reasons and it's worth keeping. From where I sit, I'd have to agree more with David. There should be no cruft left in the code that gets committed. This doesn't mean individual developers can't keep it around on there local drive, but once something is good enough to commit it should contain working code and nothing else. Critical information can always be kept in comments, but ifdef'ed or commented out code is very distracting. For here on out I hereby give anyone permission to hack out any dead, commented out, or useless code that I submit to the project. You don't need to ask. :-) On planning ahead: Back when I studied systems analysis 20 years ago, planning ahead was everything. Hardware price/performance, OO design, and networks have changed all that. These things are what make requirements so unpredictable these days (and systems so flexible). How many distribution software designs of the early nineties anticipated web based e-commerce? But now as the business world becomes increasing internetworked, requirement cycles measure in weeks and months, not years and decades. It is hard to break old habits though. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
Curtis L. Olson writes: I'd be happy if somewone could find a decent code [re]formatter that gave us enough flexibility to make our own style choices and didn't have glaring ommission or do really stupid things. astyle is the only 'free' beautifier I know of that does a reasonable job on c++templates exceptions try blocks ect It only has a limited set of styles available though so you have to accept one of the more standard ones unless you want to write some code My self I find the default settings 'just work' for me BTW, Norman, are you having fun hitting all the religeous hot buttons here since your return? :-) In all honesty I hadn't thought of it that way but if these are truely 'religeous' hot buttons then they probably need to be brought up once in a while :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ARGGHHH !
Norman Vine [EMAIL PROTECTED] said: I realize that this is a 'religous' issue and a 'tough' problem but IMHO it is a major obstacle to FGFS code evolution It is a tough problem to solve, but I haven't found it to be much of a problem reading fgfs code (have seen much worse). Maybe I'm not looking at the right code :-) It would be nice if people making patches to a module adhered as best as possible to the style of the original author, so that the module as a unit remains readible. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Jim Wilson writes: From where I sit, I'd have to agree more with David. There should be no cruft left in the code that gets committed. This doesn't mean individual developers can't keep it around on there local drive, but once something is good enough to commit it should contain working code and nothing else. Critical information can always be kept in comments, but ifdef'ed or commented out code is very distracting. For here on out I hereby give anyone permission to hack out any dead, commented out, or useless code that I submit to the project. You don't need to ask. :-) That works fine as long as the other person doesn't misidentify undead, unuseless code as being dead and useless. Not asking first can lead to hard feelings, and there's been too much of that going on around here lately. Where we can find ways to be nicer to each other, that is good. :-) On planning ahead: Back when I studied systems analysis 20 years ago, planning ahead was everything. Hardware price/performance, OO design, and networks have changed all that. These things are what make requirements so unpredictable these days (and systems so flexible). How many distribution software designs of the early nineties anticipated web based e-commerce? But now as the business world becomes increasing internetworked, requirement cycles measure in weeks and months, not years and decades. It is hard to break old habits though. This can be viewed at different levels. No we can't predict the future, and yes we need to be nimble and flexible and quick to adjust to the world changing around us, but some planning, some vision, some anticipation of the future is necessary to be succesful. Anyone who writes successful code is doing this at some level even if they say they aren't. :-) 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] ARGGHHH !
Norman Vine writes: Curtis L. Olson writes: I'd be happy if somewone could find a decent code [re]formatter that gave us enough flexibility to make our own style choices and didn't have glaring ommission or do really stupid things. astyle is the only 'free' beautifier I know of that does a reasonable job on c++templates exceptions try blocks ect It only has a limited set of styles available though so you have to accept one of the more standard ones unless you want to write some code My self I find the default settings 'just work' for me I admit I haven't tried this tool in a year or so, but when I did try it, they seemed much more focused on java formatting. And I wasn't even close to happy with it's treatment of C++. I'd love to see something with the flexibility of 'indent' available for C++, but that doesn't seem to be happening. BTW, Norman, are you having fun hitting all the religeous hot buttons here since your return? :-) In all honesty I hadn't thought of it that way but if these are truely 'religeous' hot buttons then they probably need to be brought up once in a while :-) Well, as long as it's done 'respectfully' and 'considerately' that's fine. But there's been way to much disrespect, snipping, and ill will going around this list lately. I know nothing is ever perfect. least of all human beings, but I think we could all make a concious effort to be nicer to each other and keep the tone of our messages positive... we really go no where when we are busy flaming each other and there has been really too much of that going on lately. 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] Re: OT: SuSE new release ad page
Melchior FRANZ [EMAIL PROTECTED] said: * Jim Wilson -- Sunday 17 March 2002 19:09: Interesting note, the top item on the list, Racer is not GPL or anything close to opensource ( see http://www.racer.nl/legal.htm ). It also uses the fmod lib for sound...which is imho overkill for a race sim...and it is not open either (in fact you can't even get the source). Guess I'm not all that familiar with Suse. Is that typical for their distribution? http://www.linuxracer.racesim.net/whatis.html m. Yes, but Ruud (the author) clearly states otherwise and has consistently fought attempts by some to redefine his stated intent. Personally, I don't think Ruud realizes what he's doing. He's got some pipe dream that someone is going to come along and offer him big bucks for his engine. I've seen the code and wouldn't consider it that marketable. But who knows. As it stands I think he would certainly gain by licensing under GPL. Right now anyone could read it and steal his ideas, if not the code, for commercial purpose and he would have no real recourse. In the end though I strongly believe it is the author's right to license her or his code any way they like, and I find it annoying when GPL champions try to pressure programmers to do otherwise. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] new_hitlist
Curtis L. Olson writes: One thing we'd need to think about before we got too far down this path is the texture RAM requirements of such a scheme. They should be minimal. For the first tier of imposter tiles, we're using textures that we already have, and just replacing the tile with a single quad (or two triangles) that use the most common texture. For the second tier, we're not using textures at all. It should work. We would need to do something like put 'long enough' skirts around all the tiles (including the ones with terrain mesh) to hide the gaps. By skirts do you mean something like these? http://java.sun.com/products/jfc/tsc/articles/jcanyon/#SECTION3.1.2 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 subject? was: ARGGHHH !
Curtis L. Olson [EMAIL PROTECTED] said: positive... we really go no where when we are busy flaming each other and there has been really too much of that going on lately. On that note I propose we dump this thread (known as: ARGG!) now and continue the discussion under different heading :-) Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Jim Wilson writes: From where I sit, I'd have to agree more with David. There should be no cruft left in the code that gets committed. This doesn't mean individual developers can't keep it around on there local drive, but once something is good enough to commit it should contain working code and nothing else. Critical information can always be kept in comments, but ifdef'ed or commented out code is very distracting. For here on out I hereby give anyone permission to hack out any dead, commented out, or useless code that I submit to the project. You don't need to ask. :-) We'll keep this on file. Same goes for me, by the way. Here's something that might help -- perhaps coders who want to keep old code around and visible could paste it into a separate file, like foobar.attic for foobar.cxx. That way, it would still be visible and easy to find. Personally, I think that's overkill, but it's an alternative for people who don't quite trust CVS to preserve their thoughts for posterity. On planning ahead: Back when I studied systems analysis 20 years ago, planning ahead was everything. Hardware price/performance, OO design, and networks have changed all that. These things are what make requirements so unpredictable these days (and systems so flexible). How many distribution software designs of the early nineties anticipated web based e-commerce? But now as the business world becomes increasing internetworked, requirement cycles measure in weeks and months, not years and decades. It is hard to break old habits though. On tech projects where I've been involved (ranging from $25K to over $50M), I figure we lost $10-$100 for every $1 we saved anticipating future needs. Jim's right -- people are just too stupid to guess the future (if you want a laugh, read the analysts' predictions on Yahoo! finance every morning before the markets open, and compare them with the market close after 4:15 EST -- it boggles my mind that they analysts be wrong *more* than 50% of the time). Planning ahead is OK, but C++ code and interfaces are not the place to do it. What you want is a short, 1-3 page roadmap document saying here's what we might do in the future and here's how we might do it. There's no point writing more than a few pages unless you want to give up any pretence of writing non-fiction. Perhaps we should stick three files in every code directory: a README file, explaining what the code in the directory does, a PLANS file, where we can put ideas for future interfaces, and an ATTIC file, where we can paste old code we might need again some day. When people send patches, they can send updates to these files as well. I'll volunteer to start the README files myself, if no one objects. Don't expect more than ten words each. 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_hitlist
David Megginson writes: Curtis L. Olson writes: One thing we'd need to think about before we got too far down this path is the texture RAM requirements of such a scheme. They should be minimal. For the first tier of imposter tiles, we're using textures that we already have, and just replacing the tile with a single quad (or two triangles) that use the most common texture. For the second tier, we're not using textures at all. It should work. I think Norman original mentioned 'imposters' which specifically means 'texture image' replacements of geometry. Here you would do something along the lines of rendering the entire tile from a satellite view into a single texture, and then just render that texture on a simple quad rather than the entire geometry. There are any number of ways to skin the cat though. We would need to do something like put 'long enough' skirts around all the tiles (including the ones with terrain mesh) to hide the gaps. By skirts do you mean something like these? http://java.sun.com/products/jfc/tsc/articles/jcanyon/#SECTION3.1.2 If that's the article I'm thinking of, then yes. 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] ARGGHHH !
David Megginson writes: Perhaps we should stick three files in every code directory: a README file, explaining what the code in the directory does, a PLANS file, where we can put ideas for future interfaces, and an ATTIC file, where we can paste old code we might need again some day. When people send patches, they can send updates to these files as well. I'll volunteer to start the README files myself, if no one objects. Don't expect more than ten words each. If you are willing to setup these files and keep them from getting too far out of date, then this sounds like a reasonable proposal to me. 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] San Jose (photo scenary)
I'd like to experiment flying under San Jose photo scenary. I've already downloaded the package but I don't know how to start it. Anyone coul'd help me ? If you look at the contents, there is one directory. Simply put it all in the same directory that currently has a KSJC* file in it. What is the URL/ftp site where one might obtain the package? could not find any info on the website. Regards JW ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Norman's change and the PointInTriangle
* [EMAIL PROTECTED] (Alex Perry) [2002.03.18 12:14]: Alex Perry writes: Yeah, but I'm running PLIB from CVS and I've now got a nameclash. Norman replied: #if 0 //code that clashes sgdIsectInfLinePlane() sgdPointInTriangle() #endif //0 Err, yeah, sarcasm I can do that /sarcasm I figured that it would be a good idea to generalize for everybody else, and that someone would know exactly what test to use for the decision. I don't have time to do this myself, but the real solution here is to add a configure test for these functions and set the proper define. It would be a good chance for someone to learn autoconf. It's not that difficult. -- Cameron Moore [ I'm writing an unauthorized autobiography. ] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Debian can wait
Well that install sucked. No Geforce2 support even - much easier to just go with RedHat7.2 for now. :) 7.2 should have the gcc update that 7.0 didn't have but I'll check it if I have any trouble. On 2002.03.17 00:57 Martin Spott wrote: FWIW on a SuSE 7.3 system I had to downgrade (install parallel actually) autoconf. Just pointing out SuSE needed a little tweak too. I would'nt call it that way. Autoconf on SuSE-7.3 works pretty nice. The only tweak is that you have to run 'aclocal' with '-I .'. I know this because I do build FlightGear from CVS on a daily basis, using SuSE-7.3. I once asked to include this into the 'autogen.sh' script but nobody noticed, so I'm running my own stuff: # ls CVS /dev/null (libtoolize --copy --force; aclocal -I .; autoheader; automake -a; autoconf) 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
Re: [Flightgear-devel] Debian can wait
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 18 Mar 2002 07:42, you wrote: Well that install sucked. No Geforce2 support even - much easier to just go with RedHat7.2 for now. :) It does support it, you've just got to load the driver after install. But Debian probably isn't the best for a new Linux user. David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8lRI4F2H7v0XOYBIRArFlAJwNSbHhm4Nu9eG34g8L1BFavB9l+wCgpcxs z+ap/yGpDjB9lBLmNOIG+T0= =Ig7z -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Debian can wait
Greg Long writes: Well that install sucked. No Geforce2 support even - much easier to just go with RedHat7.2 for now. :) 7.2 should have the gcc update that 7.0 didn't have but I'll check it if I have any trouble. Strange, I had no problem at all with any of my Debian installations and I'm running GeForce cards on all the boxes I'm responsible for. Yes, the debian installer isn't intended to be an entertainment experience, and it *allows* you to make decisions (which I consider a feature) :-) Debian isn't for everyone though and you certainly can produce a fine system based on other distributions. Disclaimer IUTBASA (I used to be a sys admin) so my views are warped twisted and unaligned with those of the general population. :-) 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] Redhat (vs debian) - DEBIAN ISO's obtained
You're really better off doing a network install if at all possible. Just download a couple of floppies and you're ready to go. On Sunday 17 March 2002 11:32 am, you wrote: I forgot to say that Debian must REALLY hide their ISO's - I had to get these from www.linuxiso.org Hopefully they boot OKburning ISO #1 right now. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Greg Long Sent: Sunday, March 17, 2002 8:24 AM To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] Redhat (vs debian) - DEBIAN ISO's obtained I might go ahead and give Debian a shot on the install, seems like the distro of choice, and I have a separate Redhat box (233mhz, don't think its S3 Virge supports OpenGL, I'd have to look) but I could use that for testing Debian seems to be the choice by large, and if it supports rpm's I might as well muck around with it for a bit. Despite RedHat's many publicized issues, I will give them credit - the GUI install is smooth and painless, and works like a champ on the 4 systems I have tried 7.2 on. The text installer is just as easy really. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jon Stockill Sent: Sunday, March 17, 2002 6:08 AM To: [EMAIL PROTECTED] Subject: re: [Flightgear-devel] Redhat (vs debian) / BSD OK? On Sun, 17 Mar 2002, David Megginson wrote: I think that we have many RedHat users working with FlightGear, so there should be no problem. We'll convert you to Debian some other time. distro holy war At this point I'll just add that Slackware users don't have any problems - it flightgear is happy on a default install. /distro holy war :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: SuSE new release ad page
On Sunday 17 March 2002 02:12 am, you wrote: http://www.suse.com/us/products/suse_linux/i386/games.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Gaaah! What an ugly old screenshot. I hope they're shipping a newer version! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Getting settled in my new home / Mars Scenery
(Regarding the Debian install) Options are nice during install, no argument here. And I realized I could install the driver after the fact, I just decided that with limited time, it wasn't worth investing the time in the direction of figuring out another distro - absolutely nothing against Debian as an OS other than the installer, but I imagine Debian isn't targeted to the general pop. I am not completely new to Linux, but have done limited tweaking behind the scenes. Being a CSET student and at the Sophomore level (though I used to do 8bit Assembly as a teenager in the 80's), I'm probably getting in over my head on this project, but hey, we're all a team, and there are those to consult with more experience than myself here and there - and all the work is not all raw coding of course. Though I've never forked over the money to get my private, I aced the FAA private written awhile back, and know a fair ammount. Wanna build an RV someday. Been flying Flight Sims since Flight SImulator II on the c64. I'll get my new Linux workstation setup to where I feel more at home, which includes VNC to access a Winbox without having to walk over to it. I might try to find a better mail client than Balsa, too, this isn't the best. Natilus runs a LOT better than on the 233 :) I could use suggestsion for an IDE - about all I know is the MS Visual Studio Suite. Sounds like I need to learn XML as well :) One of the main goals we would like to work on is Martian terrain. I'm not sure how much of the Earth's parameters are hard coded, but I'm imagining it shouldn't be TOO difficult to produce Mars scenery for the sim. I have done it a little bit with MS's Flight Sim, and the initial results were impressive - and FUN. I'm imagining a current Martian atmosphere, as well as a hypothetical post-teraformed Mars. Please feel free to read what I have done so far at: http://internet.oit.edu/~longg/gotmars.html -- interest / feedback? The Mars angle is not my only interest of course, I'm sure I can be of use in other areas. Greg ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Redhat (vs debian) / BSD OK?
On Sunday 17 March 2002 03:57 am, you wrote: FWIW on a SuSE 7.3 system I had to downgrade (install parallel actually) autoconf. Just pointing out SuSE needed a little tweak too. I would'nt call it that way. Autoconf on SuSE-7.3 works pretty nice. The only tweak is that you have to run 'aclocal' with '-I .'. I know this because I do build FlightGear from CVS on a daily basis, using SuSE-7.3. I once asked to include this into the 'autogen.sh' script but nobody noticed, so I'm running my own stuff: # ls CVS /dev/null (libtoolize --copy --force; aclocal -I .; autoheader; automake -a; autoconf) Martin. Hmm... maybe it was automake then. I'm not paying that much attention. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
Curtis L. Olson writes: If you are willing to setup these files and keep them from getting too far out of date, then this sounds like a reasonable proposal to me. I don't mind setting up the READMEs. The others will be set up as needed. 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] Getting settled in my new home / Mars Scenery
One of the main goals we would like to work on is Martian terrain. I'm not sure how much of the Earth's parameters are hard coded, but I'm imagining it shouldn't be TOO difficult to produce Mars scenery for the sim. I have done it a little bit with MS's Flight Sim, and the initial results were impressive - and FUN. I'm imagining a current Martian atmosphere, as well as a hypothetical post-teraformed Mars. Please feel free to read what I have done so far at: http://internet.oit.edu/~longg/gotmars.html -- interest / feedback? The Mars angle is not my only interest of course, I'm sure I can be of use in other areas. This is cool. We made some changes in JSBSim a few months ago to support different planetary flight simulations. Somewhere around here I have the code for the Mars Global Reference Atmosphere Model (Mars-GRAM) in Fortran. Gravity terms in JSBSim are retrieved via a function call, now, which could be modified for any planetary body. There are other affected parameters, as well, but the hooks are there for someday when that feature filters to the top of the programming queue. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Getting settled in my new home / Mars Scenery
Curtis L. Olson writes: That's one valid knock against Linux in general ... knowing how to admin one distribution doesn't necessarily help you a bit with other distributions. That's a bit of an exaggeration. There are quirks -- Debian uses /etc/rc?.d while RedHat adds another level, or example -- but the distros are 99% the same; it's just that we notice the parts that are not. 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] ARGGHHH !
On Sun, 17 Mar 2002 07:27:07 -0500, David Megginson [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Alex Perry writes: Fair enough. I certainly overengineered props.[ch]xx, in anticipation of all kinds of sophisticated stuff that people never bothered doing. I've been learning, slowly, from the XP people to build only for today(all my training previously was to anticipate future needs, and it's hard to let that go). It's nice to have a concept that can support all that stuff if/when we have an excuse to make use of it. Put the methods and stuff into the header file, with a comment that they are not implemented yet, and have the implementations break if used. That makes it easier to have backward compatible code when the snazzy features get added. Yes, except that I think we're paying a price with a couple of levels of unnecessary indirection and with code that no one but me can understand. I'd like to keep most of the user-level stuff intact, but ..educate us! Comments, and pointers where to learn more. This is also an educational project. ..and eventually, I will want to explain my changes to this-and-that code to airworthiness inspectors from FAA. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: SuSE new release ad page
Interesting note, the top item on the list, Racer is not GPL or anything close to opensource ( see http://www.racer.nl/legal.htm ). It also uses [...] Yep, the also ship near to commercial software with their distribution - at least on CD-ROM. Anyway you will find such sort of software on _any_ known distribution - think of the 'forms' library 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] Getting settled in my new home / Mars Scenery
David Megginson writes: Curtis L. Olson writes: That's one valid knock against Linux in general ... knowing how to admin one distribution doesn't necessarily help you a bit with other distributions. That's a bit of an exaggeration. There are quirks -- Debian uses /etc/rc?.d while RedHat adds another level, or example -- but the distros are 99% the same; it's just that we notice the parts that are not. Depends what you are doing. You weren't there to see my trying to upgrade ssh on a mandrake box a month ago ... I ended up deciding it wasn't worth the pain involved. :-) 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] OT: SuSE new release ad page
Interesting note, the top item on the list, Racer is not GPL or anything close to opensource ( see http://www.racer.nl/legal.htm ). I totally forgot Are you (Alex) using an Nvidia graphics board ? O.k., as I remember you do not. But many pople on this list do. So there seems to be very little objection to using closed source software, 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] ARGGHHH !
Jon Berndt [EMAIL PROTECTED] writes:
I ran into this problem when looking through FlightGear code in the past.
It's hard to keep track of things like:
#ifdef xxx
200 lines of code
#else
100 lines of code
#endif
If you happen to be using Emacs (available on Windows, the various derivatives
of Unix/Linux, and for other environments as well), you can eliminate the
viewing of the not-in-use code by typing M-x hide-ifdef-mode followed (if
necessary, depending on your configuration) by M-x hide-ifdefs. To show the
whole thing again, you can do M-x show-ifdefs
This will change code with ifdefs like this:
#include stdio.h
int main(int argc, char * argv[])
{
#ifdef xxx
/*
* Lots of code here
* which is only used
* in the rare case
* that 'xxx' is actually
* defined.
*/
#else
/*
* The real code is here
* and this is all we
* normally really want
* to see.
*/
#endif
}
into this:
#include stdio.h
int main(int argc, char * argv[])
{
#ifdef xxx ...
#else
/*
* The real code is here
* and this is all we
* normally really want
* to see.
*/
#endif
}
Yup, it actually runs a C preprocessor to determine what should be displayed,
so you get the proper stuff displayed. There are options available for
setting C preprocessor defines that would be specified at compile time, in
case not all of the defines are in header files.
Enjoy.
Derrell
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ARGGHHH !
On Sun, 17 Mar 2002 14:03:31 -0500, Norman Vine [EMAIL PROTECTED] wrote in message 001801c1cde6$6f3e2380$a300a8c0@nhv: hence my suggestion to find a set of settings for one of the 'beautifiers' that the code is run through, this way everyone can work on the code formatted in their prefered style. The question is whether we have anyone with cycles available to lead discussion on this and clean up the existing code base. FWIW astyle does the entire src tree in less then a minute on my 'slow' machine so this should not be an issue http://astyle.sourceforge.net ..could everyone document their preferred code style, in a coding style sheet of some sort? ..if astyle can _safely_ and _reliably_ restyle code back and forth between an accepted standard and everyones weird tastes, we only need a standard conversion tool, and a coding style standard. ..my own preference is using the Linux kernel coding style, simply for future airworthiness certification etc purposes. This should allow easier inspection etc of code flying in in aircraft EAA*-style.(EAA* www.eaa.org) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Debian can wait
On Sun, 17 Mar 2002 13:42:32 -0800, Greg Long [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: 7.2 should have the gcc update that 7.0 didn't have but I'll check it if I have any trouble. ..beware, there are 2 gcc's in RH72: [arnt@lana arnt]$ rpm -q gcc gcc3 gcc-2.96-98 gcc3-3.0.4-1 [arnt@lana arnt]$ rpm -qi gcc gcc3 Name: gcc Relocations: (not relocateable) Version : 2.96 Vendor: Red Hat, Inc. Release : 98Build Date: Tue 04 Sep 2001 08:10:42 PM CEST Install date: Thu 31 Jan 2002 10:32:27 PM CET Build Host: stripples.devel.redhat.com Group : Development/Languages Source RPM: gcc-2.96-98.src.rpm Size : 8376529 License: GPL Packager: Red Hat, Inc. http://bugzilla.redhat.com/bugzilla URL : http://gcc.gnu.org Summary : The GNU cc and gcc C compilers. Description : The gcc package includes the cc and gcc GNU compilers for compiling C code. Name: gcc3 Relocations: (not relocateable) Version : 3.0.4 Vendor: Red Hat, Inc. Release : 1 Build Date: Mon 25 Feb 2002 11:16:24 PM CET Install date: Thu 14 Mar 2002 01:23:31 AM CET Build Host: daffy.perf.redhat.com Group : Development/Languages Source RPM: gcc3-3.0.4-1.src.rpm Size : 9380610 License: GPL Packager: Red Hat, Inc. http://bugzilla.redhat.com/bugzilla URL : http://gcc.gnu.org Summary : Various compilers (C, C++, Objective-C, Java, ...). Description : The gcc3 package contains the GNU Compiler Collection version 3.0. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: SuSE new release ad page
On Sunday 17 March 2002 02:12 am, you wrote: http://www.suse.com/us/products/suse_linux/i386/games.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Gaaah! What an ugly old screenshot. I hope they're shipping a newer version! Maybe that is an old screenshot because is a picture of Racer 0.4.7 witch was opensource. []'s Marcio Shimoda ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Doc Check
I have completed my instrumentation of preferences.xml and I need someone who knows that file to give it a sanity check. I do have some of questions: What description should I have for: unitsfeet/units trimtrue/trim For entries such as: has-gs-needle1/has-gs-needle is a value of 'true' or 'false' better than 0 or 1? What is a DG? To me it is a Directional Gyro, but I don't think this is the case here. Can I have more than four engines (i.e., B-52)? If not, will some of the engines need to be 'merged' to fit the four locations? How is the 'clue meter' reading on the descriptions for the pilot and chase views? Is the aircraft orientation overridden by the runway geometry at an airport? I assume that the controls section is FDM specific? Finally, PLEASE pick nits with this document. I want it to be as accurate (and useful) as possible. Thanks, Jonathan Polley p.s. File is located at: http://homepage.mac.com/eq_fidget/FG_Dox/preferences_xml.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Inlined code harmful?
I had been concerned that SGPropertyNode::getDoubleValue was showing up at the top of the profiling output for JSBSim, but I think that that was masking the object methods it was invoking in other JSBSim code. Could very well be. properties, but not much for anything else. The biggest surprise was that inlining methods made things slower, not faster, in most cases This is certainly interesting. Do you have any statistics on how the property code was changed by un-inlining things? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] engine sounds with UIUC models
Jim Wilson [EMAIL PROTECTED] wrote: Heh don't laugh. At LWCE Borland was giving away Kylix which is basically delphi ported to linux...and if i'm not mistaken that uses something like turbo pascal as its language. It's what they call a RAD tool. Or is it a RAG (rapid atrocity generation) tool? Well Jim, Delphi programmers not only consume more coffee, they have bigger dicks too. ;-) Seriously - there is _no_ other tool on Windows that provide a better or faster RAD tool for client server and 3-tier development. No, maybe it is not suited for something like a flight simulator, but it kicks C++ and VB butt when it comes to the corporate application world. You add stuff like Corba and Oracle to the mix and Delphi is really pretty awesome. -- Billy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Inlined code harmful?
David Megginson wrote: The biggest surprise was that inlining methods made things slower, not faster, in most cases (there were a couple of exceptions). That may be a quirk of G++'s code generation, but it's probably worth considering -- I had inlined much of the infrastructure to try to speed things up, but then put it back out of line again piece by piece. It's probably not a quirk. Inlining actually helps very little except for VERY small functions. It used to be that a function call was slow -- you had to spill a bunch of registers and a return value onto the stack, and then clean them up later. But modern processors can, for the most part, stick all that mess into into a few extra pipeline stages. And all the extra code takes up extra cache lines, that are critical to performance on modern memories. So naively inlined code can actually be slower. It's also worth pointing out that needless inlining can bloat not only code, but compile times. FlightGear, frankly, takes forever to compile -- 17-18 minutes on my Athlon 950. Some of the bigger files pull in ungodly numbers of include files. I was playing recently with (I think) panel.cxx, and waiting for it to compile. A simple gcc -E on the file turned the ~50k of source code into a (no kidding) 750k wad for the compiler to choke on, due to all the code in all the include files. Check out gcc -M and gawk at the sheer number of included files. :) Some of this is the fault of the standard library, and can't be helped (except by dumping it, that is). But a lot of it is our own code, and could be productively removed from the header files. 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] Why not use assert()?
Nicolai Czempin wrote: what's wrong with using #include assert.h ... assert(some_condition); instead of that Null Pointer assignment? What null pointer assignment? Old news. This got covered, but I'll turn the question around: what does assert.h do that a crash doesn't? My way requires less code, introduces no dependence on the C standard library, and works portably on all architectures (not all asserts work the same in all debuggers). Are those huge advantages? Nope. But is assert.h a much better choice? Nope again. No one got hurt by this thing; I got yelled at only because people thought it was ugly. Aesthetics alone do not a good design make. Basically, if you can't stand to look at someone else's debug code, you need to find another career path. :) 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
[Flightgear-devel] ADI Mechanization
Hi, FWIW: while I've been working mostly with the glass displays, now and then I'll bring up the "steam gauges" panel. I finally see why the artifical horizon looked funny to me. All the ADI's that I'm aware of have the bank index marks fixed relative to the panel or instrument frame which is bolted to the airframe.And the bank pointer (the small triangle) remains perpendicular to the horizon and always points to the sky. The panel implemented in FG has the index marks rotating and the bank pointer perpendicular to the aircraft symbol. I'll admit it's been a while since I've stuck my head inside a 172, but, baring a trip to the local airport, most of the pics I've seen seem to show the configuration outlined in the first paragraph as well as the old Lear-Siegler MM-3 sitting on my desk. One of the clues taught in instrument flying for recovering from unusual attitudes is to use the bank pointer (sky pointer) to determine the shortest distance to roll the wings level if you find yourself inverted either nose down or nose up. Regards John W.
Re: [Flightgear-devel] new_hitlist
Curtis L. Olson wrote: One thing we'd need to think about before we got too far down this path is the texture RAM requirements of such a scheme. That's a manageable problem. If you think about it, the amount of impostor texture memory required is exactly that required to draw the tiles on the screen -- it's bounded by screen area. Clearly there will be a significant amount of overdraw. But there's no need for a 256x256 texture for an impostor that only subtends 20-30 pixels on the screen. The bigger problem, I suspect, will be main memory (or maybe disk bandwidth). An impostor scheme is going to be really tile hungry -- constantly dragging tiles off of disk, rendering them into textures, and forgetting about them. You're no longer limited by texture memory here, but you're still trying to cram huge datasets into a finite resource. This is the reason I'm still a CLOD bigot at heart -- with really huge datasets like terrain, any LOD scheme really needs to be done top-down (mip-mapped heightfields, for example), rather than bottom up (assembling huge terrains from huge numbers of maximum-LOD tiles). 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
