Re: [Flightgear-devel] Model Performance and dc3 donuts
Arnt Karlsen writes: ...2 proportional joysticks, just like a model airplane radio control transmitter?? I'm not sure what you mean by proportional, but they look exactly like regular joysticks to Linux. 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] 3D Cockpit, cont'd
Andy Ross writes: Apropos of this stuff, David, you might want to look at panel.cxx and investigate parameterizing the panel location. Right now, the panel is drawn in front of the viewer, with the top edge six degrees down from the center of the view and subtending 60 degrees of arc from side to side. This is fine, as far as it goes, but the real design allows for plastering the panel into 3D space by defining three corner points. I'd be thrilled for someone to take over the 2D panel code. I think that the future lies with the 3D cockpit, and I'm thinking of ways to carry most of the current panel work over -- we should be able to keep the current instrument XML files (which represent 99% of the work invested) and project each instrument individually into 3D space. I'm not promising this next week or even next month (or next quarter, for that matter), but we will need to be able to have different instruments lying on different planes (i.e. the overhead panel, the door panels, the center pedestal, etc.). For bigger things, like throttles and yokes, we'll probably use animated 3D objects. 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] engine sounds with UIUC models
Tony Peden writes: You need to write the data to the appropriate properties. You might take a look at JSBSim.[ch]xx and what we're doing with the /surface-positions/elevator-pos-norm /surface-positions/rudder-pos-norm etc. For LaRCSim, I just added code to copy the control inputs directly to these properties. 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] Flightgear, FS2K2 and GMAX
Marcio Shimoda writes: Well, this is a problem The current version of ssgLoadMDL just loads the all the information in mdl file. It doesn't know what is loading, if is a wheel or other moving part. Fortunately, that doesn't matter. We specify animations externally using an XML config file; see http://www.flightgear.org/Docs/fgfs-model-howto.html for details. As long as ssgLoadMDL preserves object names inside the model, we should be able to animate it. 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] engine sounds with UIUC models
Erik Hofman writes: To get it working the UIUC code should populate the property tree with at least the following properties (for a piston engine driven aeroplane): starting/stoping the sounds: --- /engines/engine/cranking /engines/engine/running /gear/gear[]/wow /surface-positions/flap-pos-norm /sim/aero/alarms/stall-warning Since UIUC doesn't have any engine start-up code or stall-detection code, it's probably good enough just to set /engines/engine[0]/running to true (repeat for additional engines), and to copy the value of the flap control directly to /surface/positions/flap-pos-norm. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: Re: [Flightgear-devel] Flightgear, FS2K2 and GMAX
Per Liedman writes: MDL is not a format used for modellers, it's more like a compiled binary format used for MSFS. This means that it *does not* contain object names. Hence, ssgLoadMDL does not preserve object names, since there are no names to preserve. :-) Having said that, ssgLoadMDL *does* know of some special types of objects in the MDL format (such as gear, flaps, spoilers, rudder, elevator, ailerons) and names the branch nodes appropriately when it finds these nodes. Unfortunately, the detection mechanism might be highly dependant on which version of MSFS the model was designed for, so I don't know how well it will work with models exported from GMAX for MSFS 2002. Wolfram mentioned that GMAX-exported models don't work with PLIB anyway. 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. 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 !
Norman Vine writes: Note for the FDM writers This means that queries for multiple 3 or 4 gear locations should be quicker then just the single query was before That's good news -- I'd like to encourge the FDM writers to query separately for each gear now, at least for the wheels and skids (crash points aren't as serious). 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 S Berndt writes: So, when querying, would we supply the lat/lon/radius of each bogey of interest, then get the height above ground? I think so. We might want to rewrite the interface so that you can supply offsets in meters, but that would require a bit of thought. 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 !
Tony Peden writes: So then, we'd need to convert from our body coordinates to FG's global cartesian? You already have the absolute position, so you need only to add in the body coordinates rotated to the body axes, I think. 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] engine sounds with UIUC models
Jon S Berndt writes: The best solution would be for the UIUC guys to bite the bullet and port their work to use JSBSim. :-) :-) :-) Hmm -- today seems to be a big day for trolls. I wonder if any of Jon's NASA contacts are still waiting for him to bite the bullet and port JSBSim to FORTRAN. 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 S Berndt writes: I wonder if modeling this as a pure aural cue would be enough? Until Linux and PLIB support force-feedback controllers, it might be. For many surfaces, though, we will want the plane to bounce around visibly. 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] Flightgear, FS2K2 and GMAX
Marcio Shimoda writes: Does anybody have a tutorial describing how to create the ac models? You can create ac models with, AC3D (commercial), Blender (commercial but free [and now unsupported]), PPE (open source), or Innovation3D (open source); you'll need to pick your modeller than find tutorials specific to it. I have to separate the animated parts of the model? Yes, they need to be separate, named objects. That's the only requirement. 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
Curtis L. Olson writes: I had to copy sgdPointInTriangle() as well as one other routine from the old hitlist.cxx to get things to compile. We made a decision a while back that we wouldn't require a development version of plib, but require only the most recent 'stable' version. So, these routines need to be included. Can we #ifdef them in somehow? 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 !
C. Hotchkiss writes: Should we add good exception handling in the future, then throwing and catching exceptions would make for a more robust way of dealing with a lot of problems. And, it would probably be more informative. We have exception support and we use it, but there's a gotcha: exceptions don't survive passage through a C function, and we use C-based callbacks both through GLUT and through Expat. We'll have to make sure that we catch exceptions in every callback function and do something with them, so that they don't just crash the program. 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 !
Andy Ross writes: I really don't subscribe to the indirection above all school of software engineering, where the slightest hint that change might be coming is enough to justify all sorts of contortions in the code. Sometimes, simple things really should be left simple. 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). To rewind a bit, Andy rightly pointed out some of the problems with C++ exceptions, including the fact that they don't include stack traces and that people usually throw only strings. Granted, on both points, but exceptions still have the advantage that they can be caught at any arbitrary point up the stack and handled. For example, let's say that YASim fails to parse its XML config file. If it throws an exception, perhaps fg_init can catch that, display a warning dialog, and default to magic carpet mode. 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] 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] 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] 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] 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] 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] 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] 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] 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
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] Inlined code harmful?
Andy Ross writes:
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.
Yes, that was my guess, too. When the method was just a straight
getter, like
inline double get_foo () const { return _foo; }
inlining didn't seem to hurt much (and in a couple of cases it made a
very tiny speed improvement), but once the inlined code had a couple
of lines, either in itself or indirectly by invoking other inlined
code from the standard library headers, inline caused a significant
slowdown (sometimes 25% in a tight loop). That happened even in the
inlined code wasn't invoked, i.e.
inline void foo ()
{
SG_LOG(SG_GENERAL, SG_ERROR, An error);
}
then
bool flag = false;
if (flag)
foo();
// some other stuff
I was surprised by how much faster things like this ran when I
un-inlined foo().
The build-time problem that Andy mentions has two causes: one is the
code inlining, and the other is the simple fact that so many modules
still include headers from so many other modules. Curts FGGlobals and
my property stuff is an attempt to get rid of (a lot of) that, but the
cleanup has only started. It might be some consolation to Andy that
things used to be much worse.
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] Doc Check
Cameron Moore writes: I'm not familiar with our XML parser, but could we get away with using this instead?: has-gs-needle/ In other words, you'd like foo/foo to be the equivalent of footrue/foo or foo1/foo I'm not sure if that's a good idea -- I'd be more inclined to default to 0/false/empty-string. What do other people think? 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] Inlined code harmful?
Jon Berndt writes:
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?
I'm afraid that my tests were fast and not that scientific, but here's
the most dramatic case, for 100,000,000 accesses of a double property:
Everything inlined: 3.9sec
Nothing inlined: 3.2sec
Only variable-reference getters inlined: 3.15sec
In this test, we paid a 22% time penalty for inlining even 2-3 line
methods (anything that didn't resolve simply to a variable reference).
Perhaps the results would be different under other circumstances. By
variable-reference getters I mean things like
double get_foo () const { return _foo; }
where the compiler will treat
double foo = thing.get_foo();
as
double foo = _foo;
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] Inlined code harmful?
Tony Peden writes:
To get the equivalent of tieing to object methods, a once-per-frame data
copy is necessary. Did your testing take this into account?
No, I was just testing access time. I checked in some optimizations
that skip a lot of unnecessary code when the value is held internally,
so the differences are even greater now.
Here are some tests I just ran, for 100,000,000 accesses of a double
property (I ran each on a few times then picked the most typical user
time; there was little variation anyway):
Tied to object methods: 5.880 sec
Internal (access only): 2.870 sec
Internal (1:1 get:set ratio): 3.74 sec
Internal (10:1 get:set ratio): 3.07 sec
Even when I copy the property value once for every access, it's much
faster than tying to methods. When I set once for every 10 accesses
(probably typical for the more popular properties), there's almost no
additional overhead.
I am trying to find ways to optimize tied methods, but I haven't found
any way yet to handle them without excessive indirection, because of
the necessity of instantiating a template for each different
class/type combination. I should be able to get tied pointers working
as fast as internal methods, though, if we decide to keep those.
I found only a slight improvement by un-inlining several of the most
called object methods in JSBSim. The profiling did show less time spent
in SGPropertyNode::getDoubleValue, but more time in the un-inlined
getters.
Yes, that was mainly just a matter of making the profiling report more
accurate. Remember that my tests were just for the speed of property
accesses (hence the focussed, tight loop). If we made property
accesses 25% faster, and they accounted for, say, 1% of program
execution time, we'd see only a 0.25% speed improvement.
In terms of total execution time, I'd say it came out about the same.
A real gain might be had if I un-inlined more tied methods, I don't
know at this point.
Even if uninlining the methods kept the speed the same, it would be a
good idea -- the JSBSim executable will be smaller and GDB will be
able to report the current position more accurately. The only reason
not to do it would be if uninlining caused a serious performance hit.
As I mentioned before, the only methods that seem to work well inlined
are ones that simply resolve to variables, like
double get_foo () const { return _foo; }
void set_foo (double foo) { _foo = foo; }
Even here, the advantages are very slight; anything more complicated
seems to slow things down.
This is all separate from the issue of the property manager, of course.
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] Compile Error
David Findlay writes: Anyone getting this error with latest cvs of everything? Yes, you're getting it because you're using the CVS plib (like many of us). I #ifdef'd sgdPointInTriangle out locally in my hitlist.cxx, but we need someone who knows plib better to add a general solution. This is going to bite a lot of FlightGear developers; we cannot leave it as it is. 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] Doc Check
Jon Berndt writes: I've had some thoughts along those lines, too. Note that I am not so familiar with proper XML, but I wondered if this might be legal or advisable, Instead of: POSITION X24.5/X Z-49.0/Z /POSITION we could use: POSITION X=24.5 Z=-49.5/ Right now, I use attributes for meta-information (data type, read/write flags, aliasing, and tracing). As long as I use attributes for meta-information and elements for data, we'll have a clean upgrade path; otherwise, we'll end up with lots of reserved names (you cannot have a property named alias, for example, because it might conflict with the attribute), and versioning problems (there's a new attribute named foo, so any existing foo properties have to be renamed). The current practice is a little verbose compared with a custom-designed, single-purpose XML format, but it generalizes nicely. Another alternative would be to use XML Namespaces, but (while I support them) those have their detractors even in the hard-core XML community, and I'm worried that they'll confuse people a bit in FlightGear. 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] Inlined code harmful?
Andy Ross writes: Tony reported back to the list on a more organic test -- he un-inlined the most common inline methods in JSBSim, and discovered a slight (but not exciting) speed *increase*. Actually, my interest would be in a different benchmark: how much does removing all the inlined code help the *compile* times? :) Well, it will kill you the first time, of course. After than, I'm sure it will help a bit, but the biggest benefit will come because the header files won't be modified as often when the implementation is in the C++ files, and as a result, dependencies won't be triggered all the time. 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] Doc Check
Andy Ross writes: sim fooA/foo fooB/foo /sim This already works as you would expect. Multiple children with the same name are automatically numbered sequentially when there is no n attribute, so the above is synonymous with sim foo n=0A/foo foo n=1B/foo /sim I tend often to include n anyway, just to help people keep track of where they are. That's most important when there are a lot of subproperties, not in a simple list like the above. 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] Doc Check
Andy Ross writes: POSITION X=24.5 Z=-49.5/ This is more readable to my eyes too, which is why the YASim parser uses attributes. If it's any comfort, this is a general problem in XML: the more general we make a format, the less we can use optimizations like these, but the more specialized we make a format, the less we can do with it. A custom-designed XML format for panels, sound, animations, FDMs, etc. could be *much* less verbose, but then we'd be managing n different XML-based formats and parsing libraries. There are ways around this problem. For example, the Resource Description Framework (RDF) has Byzantine syntax rules precisely so that people can use attribute instead of elements when they want to (and all kinds of other abbreviations as well). RDF has a lot of good ideas, but it's a major pain to implement (I've done it twice) and even harder to learn; take a glance at the spec and see: http://www.w3.org/TR/REC-rdf-syntax/ RDF is also almost impossible to use with XSLT or XPath in the general case because of all the syntactic variants allowed. By contrast, our property-tree format, though verbose, is relatively easy to learn (no harder than HTML) and trivially easy to format or process with XSLT and other standard XML tools. A Perl or Python script to do something useful with a XML property file can be only a few lines long. This is a classic worse-is-better approach, for better or worse, I guess. We impose a bit on the user, but keep things much simpler as a result. Nonetheless, I think I'd honestly have to admit that this is a bug in YASim. The reason I did it this way is that I didn't know the property tree parser existed at the time. :) The one advantage of Andy's approach is efficiency -- he copies from the XML straight into the YASim data structures, without building up and tearing down an in-memory property tree first. For large-scale XML implementations, we *have* to do things that way -- the DOM and XSLT tend to break down catastrophically for large XML documents or high volume. That's why we designed the Simple API for XML (SAX). Efficiency doesn't matter much for YASim, since we're a short file, and we're reading it only once. If we're ever processing a lot of XML in the main loop, say, over a network connection or from large GIS databases, we'll need to go with a streaming approach like Andy used. 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] Re: Property Manager Changes
Melchior FRANZ writes: ... and now Simgear doesn't compile for me any more. gcc (2.95.2) complains about sort and sprintf not being found in props.cxx (implicit declaration of function ...). Adding #include algo.h #include stdio.h helps, but this is probably not what you had in mind. What is the correct fix? That's almost it. I ended up adding #include algorithm #include stdio.h This problem didn't show up with g++ 3.0, so I missed it. 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] Re: Obvious Speedups
Melchior FRANZ writes: * David Megginson -- Tuesday 19 March 2002 19:16: Would it be possible either put out a version without the spurious whitespace changes, or to post a message showing only what you actually changed? You could also patch a copy, make your own patch with diff -bB between the patched and the unpatched file and then apply this patch to the original. Thanks, that did the trick (it still left a lot of whitespace differences, but it got rid of about 75% of them for me). I managed to get it compiled, but I see almost no change in framerate -- instead of 44 fps it flickered between 44 and 45 fps, which is inside any reasonable margin of error. If Norm can tell us what the patch was supposed to do, perhaps we can help find a way to make it work. I'm going to leave it out for now, though. 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] Re: Obvious Speedups
Curtis L. Olson writes: diff -w ignores white space, but that doesn't necessarily help if you are using emacs ediff to compare the files and merge the changes. It could, perhaps, if you do something like this: diff -w main.cxx /tmp/new-main.cxx main.patch patch main.cxx /tmp/main.patch xemacs main.cxx then, in xemacs, M-x ediff-revision 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] Obvious Speedups
Andy Ross writes: Have I missed something? I'd be really shocked if the fps numbers were different at all with this patch. Where does the 10% come from? Note that Norm wrote that it *should* improve the framerate by 10%, not that it actually did. I'm waiting to hear more details. 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] Re: Obvious Speedups
Curtis L. Olson writes: You definitely can't be ranked as an emacs power user until you are intimate with all the .elc's. :-) No, you're not an Emacs power user until RMS has forced you to have your boss sign one of those disclaimers before he puts your code in the main elisp distribution. 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] Re: Obvious Speedups
Jim Wilson writes: Can we hold off on this? I'm totally reorganizing the viewer code and really don't need to deal with these kind of changes. It'll functionally be the same so there shouldn't be any problem making this change later. I agree that we need to hold off on any viewer changes, at least for a day or two, to see if Jim has any success finishing his rewrite. 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] Obvious Speedups
Norman Vine writes: Note that prior to patch profiling showed approx 10% of time in fgIdle() and fgReshape() this patch removed them from the loop and in subsequent profiling they did not show up at all and my fps was ~10% higher :-) I saw no significant FPS difference at all. There could be a difference between the effect on Windows and Linux, or I might not have applied the patch correctly; I'll look forward to trying the revised patch. 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] Re: Obvious Speedups
Norman Vine writes: I am not so sure that we don't want both an pulsed 'euler' angle setter 'keypoard and hat' AND a separate mouse controller. I mean after all you don't have to go into Mouse View mode and this way I can use the keyboard to set the default viewin offsets and I the mouse can be used for 'quick look arounds'. I don't think this is a good architectural choice -- having two (or more) different ways of doing the same thing makes life hard for all the rest of the programmers, as we've seen over the past few weeks with the viewer code. Obviously, the final say will be Curt's, but I'm going to insist as hard as I can that we have the mouse code provide Euler angles like all the other input sources. If we did decide to support Norm's scenario, I think the right approach would be to push the current viewer state then pop it out again. That would be a good, general solution that would work for anything (mouse, keyboard, joystick, graphic tablet, head-mounted thingy, or what-have-you). 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] Re: Obvious Speedups
Norman Vine writes: http://www.vso.cape.com/~nhv/files/fgfs/nhv_obvious.tgz Are the main.cxx changes atomic? I'd like to apply just them, for now. Thanks, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Curtis L. Olson writes: Oh well, I've only been flamed by RMS (but that should at least count for something, right?) You get one point for every 12 flames. 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] Re: Obvious Speedups
Norman Vine writes: True -- but then again I have sped the program up ~15% even more if you consider the model view, within the last month. Heck I replaced five matrix multiplies with one for every moving part in the model display code alone :-)) Norm -- I am very grateful for your contributions. Most noticably, they reduced the stutter at the start of the model animation for some audio hardware and made the model code cleaner. How did you arrive at the 15% figure, though? My framerate hasn't changed at all for a long time. Perhaps it has something to do with the combination of graphics hardware and CPU people are using -- I have a relatively fast CPU (c.a. 900MHZ) but only a slow-to-middle-range GPU (GeForce2), so I may be more GPU- than CPU-limited. Perhaps someone running with, say, a GeForce3 and a 400MHZ CPU will see the framerate changes I'm missing. So I think we can afford to use one here, where there actually is a reason for it ! We're not worried about the processing cost of a matrix multiply. I would be shocked if adding an extra 100 matrix multiplies changed the frame rate by more than a fraction of a frame per second. We're worried about the simplicity and consistency of the interface and the maintainability of the code. The Viewer ( please lets come up with a better name code should only be concerned with the orientations ect that are 'inherent' in the world 'situation' and the GUI module should handle user interactions or am I missing something 'obvious' :-) The user input (GUI or otherwise) tells the viewer *what* it wants, and the viewer figures out *how* to do it. I shouldn't have to add quats or matrices into the network, keyboard or joystick handling code, and by analogy, they don't belong in the mouse code either. 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] Re: Obvious Speedups
Norman Vine writes: David Megginson writes: Norman Vine writes: Old binary (about 2 days old, pre-property changes) --- From 4,000 ft: 45-46 fps From 8,000 ft: 29-30 fps Current CVS --- From 4,000 ft: 49-50 fps From 8,000 ft: 35-36 fps This speedup is most likely my new hitlist code 8-10% I checked the dates, and I installed my old binary on Monday evening, after your hitlist code was already incorporated, so unfortunately it doesn't come into the equation. I don't have any similar test from before that, but it could be that the framerate was even slower before. I have no idea what caused this speedup -- I doubt it was the property rewrite. Current CVS with Norm's main.cxx patch added From 4,000 ft: 49 fps From 8,000 ft: 35 fps Hmm... My guess is that this has something todo with your running in a wIndow and glut is doing stuff behind the scenes that is not necessary on a windows box in game mode That is possible. We're on different OS's with different windowing systems and drivers -- you may have identified a performance bug that affects only Windows systems. I posted your main.cxx to a temporary URL (http://www.megginson.com/flightsim/main.cxx), and I'd love to hear from other Windows users. 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] Bruce Perens Street Map of USA
David Findlay writes: This might be of use to us. Could we include this sort of data in the FGFS scenery? No, we cannot, with our current approach -- it would create far too many polygons. Even moving to VMap1 pretty-much kills the scenery engine, and that just adds major regional roads and more detailed polygons. The only way to get something like that with current technology in is to generate giant textures for each tile. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Kudos for Tony
Tony Peden has been working quietly for the last couple of weeks incorporating the property manager into JSBSim itself. He checked the results into CVS this morning, and they are very impressive: in FlightGear (using JSBSim, of course) open the property browser and look under /fdm/jsbsim for an enormous amount of information about what's going on inside JSBSim. I haven't tried yet, but I imagine that it might even be possible to change some internal JSBSim values on the fly for testing or experimenting. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Kudos for Jim (new view code)
This is a banner week for major FlightGear code overhauls. Jim Wilson's excellent view-code rewrite is now in the CVS. We should be very close now to adding a tower view and a more usable 3-D cockpit, among many other things. I should also give additional thanks to Norman Vine, who wrote the original viewer code that we still steal all the hard parts from. *** NOTE *** I had to do a make distclean to get this to work, because of screwed-up dependency information somewhere in my source tree. You may have to do the same. Here's Jim's description of the changes (also in the CVS log): Description: This update includes the new viewer interface as proposed by David M. and a first pass at cleaning up the viewer/view manager code by Jim W. Note that I have dropped Main/viewer_lookat.?xx and Main/viewer_rph.?xx and modified the Makefile.am accordingly. Detail of work: Overall: The code reads a little easier. There are still some unnecessary bits in there and I'd like to supplement the comments in the viewer.hxx with a tiny bit on each interface group and what the groupings mean (similar but briefer than what you emailed me the other day). I tried not to mess up the style, but there is an occasional inconsistency. In general I wouldn't call it done (especially since there's no tower yet! :)), but I'd like to get this out there so others can comment, and test. In Viewer: The interface as you suggested has been implemented. Basically everything seems to work as it did visually. There is no difference that I can see in performance, although some things might be a tiny bit faster. I've merged the lookat and rph (pilot view) code into the recalc for the viewer. There is still some redundancy between the two, but a lot has been removed. In some cases I've taken some code that we'd likely want to inline anyway and left it in there in duplicate. You'll see that the code for both looks a little cleaner. I need to take a closer look at the rotations in particular. I've cleaned up a little there, but I suspect more can be done to streamline this. The external declaration to the Quat_mat in mouse.cxx has been removed. IMHO the quat doesn't serve any intrinsic purpose in mouse.cxx, but I'm not about to rip it out. It would seem that there more conventional ways to get spherical data that are just as fast. In any case all the viewer was pulling from the quat matrix was the pitch value so I modified mouse.cxx to output to our pitchOffset input and that works fine. I've changed the native values to degrees from radians where appropriate. This required a conversion from degrees to radians in a couple modules that access the interface. Perhaps we should add interface calls that do the conversion, e.g. a getHeadingOffset_rad() to go along with the getHeadingOffset_deg(). On the view_offset (now headingOffset) thing there are two entry points because of the ability to instantly switch views or to scroll to a new view angle (by hitting the numeric keys for example). This leaves an anomaly in the interface which should be resolved by adding goal settings to the interface, e.g. a setGoalHeadingOffset_deg(), setGoalPitchOffset_deg(), etc. Other than these two issues, the next step here will be to look at some further optimizations, and to write support code for a tower view. That should be fairly simple at this point. I was considering creating a simulated tower view or pedestrian view that defaulted to a position off to the right of whereever the plane is at the moment you switch to the tower view. This could be a fall back when we don't have an actual tower location at hand (as would be the case with rural airports). ViewManager: Basically all I did here was neaten things up by ripping out excess crap and made it compatible as is with the new interface. The result is that viewmanager is now ready to be developed. The two preexisting views are still hardcoded into the view manager. The next step would be to design configuration xml (eg /sim/view[x]/config/blahblah) that could be used to set up as many views as we want. If we want to take the easy way out, we might want to insist that view[0] be a pilot-view and have viewmanager check for that. Anyway, that's the scoop. There's an odd mix of inlined and not inlined, const and not const declarations, but I was going to wait until things were closer to done before messing with that kind of thing. Let me know if you have any questions. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] minor nits
Curtis L. Olson writes: Here's a couple things that have surfaced after the recent rewrites: - The AGL instrument on the default HUD appears to now be in meters. Altitude is still in feet. If you pop on the hud and assume the agl is in feet, you will be way off ... this should get switched back. I'm noticing some feet/meter problems as well. I also noticed that --altitude= on the command line was giving me meters rather than feet. - The heading hold seems to hold 5-10 degrees 'left' of the heading bug location. This also is recent addition. No, this has been a problem for at least six months. 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] Re: Obvious Speedups
Andy Ross writes: Oooh, which reminds me: has the default logging level changed? I was noticing last night that lots of stuff that used to be printed isn't anymore, including the YASim solution report which I'd like to preserve. I looked briefly for something that might have changed, but couldn't find anything obvious. I think Curt made some changes a few weeks back -- a high default logging level is murder on the Windows users. If you want to see everything, try this: --prop:/sim/logging/classes=all --prop:/sim/logging/priority=bulk All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] minor nits
Curtis L. Olson writes: I'm noticing some feet/meter problems as well. I also noticed that --altitude= on the command line was giving me meters rather than feet. Could this be a side effect of the property manager overhaul? I'm not sure what else has changed recently that could be related. I think so -- I'm going to take a look at options.cxx right now. - The heading hold seems to hold 5-10 degrees 'left' of the heading bug location. This also is recent addition. No, this has been a problem for at least six months. No, the problem has become 5-10 degrees worse in the past couple of days. Interesting. I've seen the problem consistently for quite a few months (the AP holds the DG about 10 deg off the heading bug). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Flaps not working in JSBSim
JSBSim is no longer setting the /surface-positions/flaps-norm property, so the flaps don't move in the animation and don't make a sound. The position is still set correctly in /controls/flaps, and flap animation works as usual with --aircraft=c172-yasim. 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] 3D Cockpit, cont'd
Andy Ross writes: That's exactly the idea. You take a plane of instruments (what we're currently calling a panel XML file) and project it into 3D space via specifying corners. It draws on top of the existing stuff, with no problems whatsoever. If you want to have only one instrument per panel, that works fine. Most (well, all) cockpits, though, have a bunch of flat boards with instruments mounted on them. Call each one of those a panel and we're done. All the work carries over automatically. The only code changes required are to allow the corner vertices to be specified in the configuration (/sim/panels[n]/bottom-left/x-m, etc...), and allow more than one panel to be created at once. Maybe there's a need for a cockpit xml file to unify some of this. I don't look at raw OpenGL all that often -- I guess I'll have to do a bit of trig to figure out the transformation, given the corners. If you have even the slightest inclination to try this yourself, please be my guest. I do need to get the panel into a proper SSG scene graph some day soon. 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] Re: Obvious Speedups
Norman Vine writes: This is rapidly getting on towards voodoo coding, and I think perhaps we should step back a bit. What, exactly, are the changes in this patch that make it worthwhile? What does it eliminate? What is the evidence for speedup? gprof is your friend gprof will show where CPU time is being spent, but not how much of a framerate increase you can expect. Even for CPU time, it's iffy -- for example, SGPropertyNode::getDoubleValue was showing up high in the profiling stats for JSBSim, but that's because it was invoking a lot of inline accessor methods that weren't profiled (because they were inlined). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgReshape redux
I did some experimenting with fgReshape, adding a simple test at the start to return if the width, height, and panel visibility were unchanged, but saw no framerate improvement. Upon closer examination, the only OpenGL-related things in the function are glViewport( 0, (GLint)(height - view_h), (GLint)(width), (GLint)(view_h) ); and ssgSetFOV( globals-get_current_view()-get_h_fov(), globals-get_current_view()-get_v_fov() ); Does glViewport have any significant overhead? Don't we have to call it every frame anyway (I know the panel code does so). All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
Norman Vine writes:
In my (limited) tests, even inlining something like
void setFoo (double foo) { _foo = (foo 0 ? 0 : foo); }
slows things down.
Really ??
then try this both with and without optimization :-))
Ah, yes, but this is a tight loop. In my tests on props.hxx, the
inlined code came in the middle of a long code block. I didn't have
time to do a lot of rewriting, but even when I did something as simple
as
double x = 100 + jnk;
jnk = 1000 + test_junk(i);
double y = 50 / x;
jnk *= y;
the speed advantage of the inlined code was cut in half.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
Norman Vine writes: However some code fragments run 100's or even 1000's of times per iteration and these fragments should be studied on an individual basis and not just automatically un-inlined because it is in 'vogue' :-) It's not a question of vogue. Currently, we start with an enormous amount of inlined code by default. I'm suggesting that we start with nothing (or almost nothing) inlined, then inline only what can be proven to help through profiling and timing tests -- uninlined until proven necessary, rather than inlined until proven unnecessary. This should make the executable smaller, compile times faster, headers more readable, and debuggers more useful, all as side-effects. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug with c310
Arnt Karlsen writes: ..belly landings should be a noisy prop bending affair, but you should not total the aircraft... unless its a B-17 and you forget to dump the ball turret. In any case, you should walk away from the wreck, possibly receiving a repair bill from the insurance guy. ;-) And angry letters from the grieving family of the tail gunner. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault on mini-panels
Jim Wilson writes: Here's a backtrace on this. I've just checked in some minor fixes to props.cxx in SimGear, and swapping panels (with 's') in FlightGear is working again. Thanks. By the way, we need to get rid of the panel_2 property; instead, we should have panel[0], panel[1], panel[2], etc. and allow 's' to cycle through the whole list. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Jonathan Polley writes: The only thing I see it complain about is using std::sort. If I try 'using std::sort,' as is done if PROPS_STANDALONE is defined, I get the same errors. Considering the problems I am having getting JSBSim to compile, with similar complaints, I am getting concerned that something has gone terribly wrong. If I had a better understanding of C++ and/or STL, I could be more help hunting this down. I may have to attempt a re-install of MSVC tomorrow. I'm pretty sure that this is another MSVC conformance bug. There is a C function sort in stdlib, and there is a C++ function sort with a different signature in std. I always try to avoid 'using namespace std' in C++, just as I avoid things like import java.io.* in Java -- they're both bad design. In this case, however, it seems to be a necessary evil, so I'll make the change in SimGear. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Bernie Bright writes: Moving using std::sort after #include algorithm fixes the problem in props.cxx. I thought I'd done that already, but the change must have been blown away by something else. Oh well. I've checked it in now. 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] policy question: new [], delete
Melchior FRANZ writes: As I reported recently, I'm running fgfs through the valgrind debugger. Due to hundreds of error messages and to still having to learn valgrind I'm not very productive yet. I did resolve a few hundred error messages, though, all of which were caused by only a few (sort of) cosmetic bugs. In most cases it was code like this: char *s = new char[10]; ... delete s; // should be: delete [] s; I'll fix the ones in props.cxx right now. Patches for any others would be welcome (if you send them to me, I prefer patches to whole files; if you send them to Curt, he prefers whole files to patches). 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] framerate 1/s
Melchior FRANZ writes: The changes from yesterday turned my framerate at KSFO from about 10 to 1 per second. Ten is already painful enough, and that with clouds and panel turned off. But one is a bit weak and makes fgfs virtually unflyable. (I've only got a 266MHz processor and a V3 graphics card.) Which changes? I don't think we did anything major yesterday. 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] Re: framerate 1/s
Melchior FRANZ writes: * David Megginson -- Friday 22 March 2002 13:41: Which changes? I don't think we did anything major yesterday. Some things in the mouse control file and something in the viewer. But I'm right now running 'cvs up -D 16 hours ago' so that I can see if the last changes are really the problem. It'll take a while until I have recompiled. Jim's changes simply renamed the old goal_offset and goal_tilt methods for consistency -- there is no new rendering or computation going on in them. If your framerate has dropped so precipitously, there must be something else going on. 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] Re: framerate 1/s
Melchior FRANZ writes: Yes, Linux (2.4.18). Nothing in the background. I have still the version from yesterday installed, which works fast as always. Just the build from today is dead slow. I can start these different builds alternating and the one from today is always unusable, while the other always works. Can anyone else reproduce this? I cannot, unfortunately, and I'm struggling to think of anything that changed yesterday that could cause this problem. In the new source tree, try a 'make distclean' and then rebuild -- perhaps everything didn't build correctly originally. 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] Re: framerate 1/s
Alex Perry writes: It's working fine for me, in terms of framerate. Still getting a bunch of segfaults with teleport and attempts to change the loaded panel. When did you last update? I check in a fix for changing the panel yesterday, and if it's not working for some people, I need to know. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Airport lighting around KSFO
I've put together a quick scenery overlay for the entire w130n30 chunk around the Bay area, with runway lighting for all the airports. You can download it here (temporarily): http://www.megginson.com/flightsim/w130n30-overlay.tar.gz You should unpack this from inside your scenery directory after backing up existing files, etc. etc. These were generated using today's CVS of TerraGear. 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] JSBSim Inlining
Tony Peden writes: Also, I was able to better quantify the performance change due to incorporating the properties code. Prior to this, I had done speed comparisons with the profiling code compiled in, but now I'm not so sure that's fair. So: pre-props: 1.3 seconds average post-props: 1.4 seconds average or about an 8% loss in speed. I'm not surprised that you'd see a small slowdown with heavy property use, but I'm surprised that you're seeing this in standalone JSBSim. I looked at the current JSBSim code, and there are scarcely any property accesses at all: as far as I can tell, only FGCoefficient::Value and FGCoefficient::TotalValue methods touch the property tree at all in the main loop, though I can imagine that these are relatively heavily used. What property-related methods show up near the top in the profiling? The other possibility is that the new multi-FDM stubs are slowing things down, but that seems unlikely. 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] JSBSim Inlining
Tony Peden writes: What property-related methods show up near the top in the profiling? SGPropertyNode::getDoubleValue() This makes perfect sense, because it's called in place of FGState::GetParameter which used to be the big hitter. I had been thinking about eliminating tying to pointers, but in my own tests, I have had very little luck speeding up tying to object methods, so maybe tying to member variable pointers is a reasonable alternative (it also avoids all the template madness). I can optimize that a bit as well. When you use this approach, instead of node-tie(SGRawValuemethods(this, Foo::getBar, Foo::setBar)); you would do node-tie(SGRawValuePointer(bar)); This works, of course, only if your getters and setters don't massage or clamp the values at all. There are some easy optimizations I can perform to make tied pointers as fast as internal values, if they turn out to be helpful. 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] JSBSim Inlining
Tony Peden writes: This seems very attractive, but it also seems to break the OO. My personal feeling is that it would be better to chase JSBSim design improvements and live with the cost of tieing to object methods. Sounds fair -- that's the kind of approach I've learned to appreciate more and more over the years. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Problems Building JSBSim using MSVC 6.0
Jon Berndt writes: Are we doing something unusual, or is MSVC requiring something it shouldn't? The latter, I think, since the pointer type can be determined unambiguously from the method signature. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] new_hitlist
Wolfram Kuss writes: The bigger problem, I suspect, will be main memory (or maybe disk bandwidth). An impostor scheme is going to be really tile hungry -- constantly dragging tiles off of disk, rendering them into textures, and forgetting about them. I know a sim that does what Norman suggest and it does not seem to have problems with loading tiles, although it rerenders tiles all the time (about one tile per frame). I misunderstood Norm's original suggestion, but I still see no major problem with using a simpler scheme like I suggested in an earlier posting: 1. At distance (a), replace the tile with a single quad (or two triangles) using the texture for the most common material on the tile -- these would be similar to our current ocean tiles. 2. At distance (b), replace the tile with a single quad (or two triangles) untextured and using the ambient colour for the most common material on the tile. This probably wouldn't be hard to implement using SSG, and wouldn't have any dependencies on hardware capabilities -- we could generate the two alternative tiles at tile load time as well as the main one, since they would be very small. I think that SSG already has LOD support of some kind, so we wouldn't have to do much at all. This approach would let us experiment with different distances and see if we need Norm's imposters as an intermediate layer. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Viewer Improvements and 3D cockpit (and note to Alex Perry)
I've just checked in Jim's latest viewer improvements and I encourage everyone to update the main source tree and the base package, then try fgfs --aircraft=c172-3d It's still not pretty, but with Jim's improvements, it's usable -- you can look around easily with the mouse or keyboard. I just tried my first end-to-end flight using the 3D C172 cockpit, flying from CYOW to CYRP. Alex: the cockpit interior hasn't been made accurate yet (I haven't used any proper plans or detailed photographs), but how does the general feel compare with flying in a real C172? Are the body reference points where you expect them to be? Does it feel right? Is the propeller filling too much of the front view? Should I add a cup holder? On that note, what a difference the ability to use body reference points makes! I'd never been able to nail the turn to final from base consistently on a visual approach, and I had assumed that I was just totally incompetent (which I probably am -- keep me away from real planes). With the 3D cockpit visible from all viewing angles, however, I had no problem starting the turn at the right time, turning the right amount, and ending up perfectly lined up with the runway for an easy landing. It's also easier to keep the plane straight and level during climb with rudder input. I just put the view direction about 5 or 10 deg to the left so that I can see more of the horizon, and I find myself making the adjustments instinctively rather than chasing the gauges. It was a little harder to find the airport in the first place, though. I actually managed to get lost briefly, even though I was only a few km outside Ottawa, just because the view looked so unfamiliar from the 3D cockpit and because parts of it were obscured in lateral view. 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] Viewer Improvements and 3D cockpit (and note to Alex Perry)
Curtis L. Olson writes: With the latest changes from cvs, I come up by default and see the instruments but no instrument panel / background. The propeller is spinning off center to the left. From the left seat, the prop should be off center to the right I think. (Or do they fly on the other side of the victor airways in Canada?) :-) There is no background because you see the 3D model's panel behind the instruments. If you're not seeing the 3D model panel behind the instruments, make sure you're using the latest base package and source code from the CVS. One problem I saw is that if you pitch up/down the view from the 'inside the cockpit' view and then switch to an external view, the aircraft model itself is left at the 'view' pitch offset which is incorrect. Yes, I'm seeing this in the newest code as well. 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] Viewer Improvements and 3D cockpit (and note to Alex Perry)
Jon Berndt writes: Any chance someone could post a screen shot??? I took six quick shots while twirling the view around 3000ft above the default airport (KSFO): http://www.megginson.com/flightsim/cockpit01.png http://www.megginson.com/flightsim/cockpit02.png http://www.megginson.com/flightsim/cockpit03.png http://www.megginson.com/flightsim/cockpit04.png http://www.megginson.com/flightsim/cockpit05.png http://www.megginson.com/flightsim/cockpit06.png 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] Viewer Improvements and 3D cockpit (and note to Alex Perry)
Curtis L. Olson writes: There is no background because you see the 3D model's panel behind the instruments. If you're not seeing the 3D model panel behind the instruments, make sure you're using the latest base package and source code from the CVS. Hmmm, I'm not seeing the panel behind the instrument, and I do have the latest cvs base and source as of 5 seconds ago ... I suppose I could try a full rebuild ... (?) You might have to -- dependency handling seems very badly screwed up these days. It could also have something to do with your 3D hardware -- in main.cxx, I set the near clip very close for interior view, and perhaps that's screwing something up for you. 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] Viewer Improvements and 3D cockpit
Richard Bytheway writes: I like this lots, I must have a play myself later. The second thing I noticed (after just how cool the panel looks) is how obvious the flat knobs are, particularly the magneto switch. I guess that a full 3D panel will fix this, but I am not volunteering to do the work :-) Thanks. A full purely 3D panel is not practical with current hardware -- we won't be making every gauge and needle fully 3D; I think that some parts are good candidates for 3D animation, though. You mention the throttle and mixture knobs -- the levers on larger aircraft will definitely need to be 3D, as will the control yokes, fuel selector level, rudder pedals, parking brake, and possibly the various trim wheels. I think we might get away with sticking to textures for the radio knobs and other smaller things. On a related note, does anyone know how I could convince CVS that the base package tar.gz file contents are a suitable starting point for a cvs update of the base package? You could try upgrading directory by directory rather than from the root. 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] Viewer Improvements and 3D cockpit (and note to Alex Perry)
David Megginson writes: You might have to -- dependency handling seems very badly screwed up these days. It could also have something to do with your 3D hardware -- in main.cxx, I set the near clip very close for interior view, and perhaps that's screwing something up for you. As I just mentioned to Curt by private e-mail, I hadn't checked Jim's latest c172-3d-set.xml into the base package. Perhaps Curt will have better luck with it. 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] Viewer Improvements and 3D cockpit (and noteto Alex Perry)
Alex Perry writes: Works fine. Thank you Jim! My main complaint is that the view elevation is such that I have some cockpit ceiling in the view, yet some of the instrument panel is missing. I can fix it with the mouse scrolling, but it is cancelled as soon as I revert to mouse joystick input mode. Thus, please point the view direction vector down a little bit. That will be changing real soon now. As a temporary measure, try starting with something like this: fgfs --aircraft=c172-3d-set.xml --prop:/sim/view/goal-tilt-offset=-5 When my new mouse code is finished, you'll be able to keep your mouse view if you wish (it will be fully configurable, so you can set it to do all kinds of things). Right now, I have rebound my arrow keys to control the view offset and tilt, since I never fly with the keyboard anyway. Looks fine; you can check the geometry since it's a 75 diameter. However, we _really_ need to blur the thing, it looks downright stupid. Yes, I'm trying to decide how to do that. I suggest two additional textures, a fully blurred one and a 45 degree blurred arc, and alpha progressively through them. We can store all three inside one texture, if needed, since the fully blurred one is actually a 1D texture (but needs to be 2D for the arc). I'm thinking along the same lines: in addition to the prop object, make two disks, one with the blade outlines still partly visible, and one with everything very blurred, then switch among them based on RPM. That will require some changes to model.cxx, though, and I want to work on the mouse changes first. Should I add a cup holder? No; we _do_ need to implement leaning the head to look round the yoke, so we can add the yoke, and the instrument plate clip and other stuff. When the new mouse code is ready, you'll be able to use the mouse to move the view position as well as the view angle. At first, it won't be tied to the hinges of the human body, but we can implement that next if we want to. 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] compile error in latest cvs
Jim Wilson writes: I'm getting a compile error in model.cxx with the latest cvs. There Same thing here. I sent the same message to David about an hour ago. If you roll back the very last change in just model.cxx you can build and it works. Fixed -- sorry about that. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Configurable mouse progress
The configurable mouse support is now about 75% complete, and it already provides most of the functionality of the old GUI/mouse.cxx module. I'd be grateful if people could start taking a look by building FlightGear --with-new-mouse and looking over $FG_ROOT/mice.xml. I've designed everything to support multiple mice, in case we ever switch away from glut (which allows only one). We also get mouse-wheel support for free under Linux, with X-windows configured for mouse-wheel support, since the wheel movement is reported as buttons 3 and 4 -- you can play with this now, if you're adventurous (for example, you could bind the mouse wheel to elevator trim if you yoke or joystick doesn't have a trim wheel). 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] RFC: View Properties structure Proposal
Andy Ross writes: Wolfram Kuss wrote: I indeed think it is very important while landing to be able to look ahead or look at the landing spot with the press of a key. In RL, my head swivels between those two views, especially while in base. Don't know whether some AI or much user defined stuff is needed for *this* feature though. I already have this feature. Just add a joystick mapping that sets the view offsets to zero, and scroll around with a hat switch. A little extra work would allow it to toggle settings from storage properties somewhere, so you wouldn't lose the direction you were looking at before you flipped to forward. You can do it with your keypad as well (unless you have a notebook, like I do). 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] Modal mouse thoughts
Alex Perry writes: I like the concept of the mice.xml file, but am not really comfortable about having the implied modal state hidden in there. Can we break it out, so that mouse, joystick and keyboard events can be conditional on state variables ? Thanks for looking at the code. There are a few things I'm trying to decide right now. First, I'd like to get all state variables out of the /input tree -- the current mouse mode, x- and y-position, and (soon) button status should all go in some other subtree, such as /devices/mice (we desperately need to do that high-level reorg of the property tree). As for the mouse mode, it is accessible from any bindings using conditions, such as key n=?? binding condition equals property/input/mice/mouse[0]/mode/property value1/value /equals /condition commandproperty-assign/command ... /binding /key In fact, I had originally implemented mice.xml that way (as you suggested in your example), but it seemed very verbose -- I have no objection to putting it back if it doesn't scare away everyone else. Yet another option is to allow a fixed maximum number of modes (say, 10) and make them into pseudo-modifiers; we could do the same for mouse buttons. That's not really necessary any more with conditions, though. The other benefit is that the keyboard can easily become modal. We don't currently support key sequences and stateful decoding of keyboard input, which severely limits our ability to tie useful controls to keys. Modal key input is fully possible currently with clever use of conditions, but it is very verbose. Let's say that we wanted 'X' to start an input sequence: key n=88 binding commandproperty-assign/command property/status/modes/x-mode/property valuetrue/value /binding /key and then 'a' to be the second key of such a sequence: key n=97 binding condition property/status/modes/x-mode/property /condition ... /binding binding condition property/status/modes/x-mode/property /condition commandproperty-assign/command property/status/modes/x-mode/property valuefalse/value /binding /key I agree that that's hideously ugly. It's a little cleaner if you just want X to be a modifier key, since it can clear its own flag on release: key n=88 binding commandproperty-assign/command property/status/modes/x-mode/property valuetrue/value /binding mod-up binding commandproperty-assign/command property/status/modes/x-mode/property valuefalse/value /binding /mod-up /key Exactly the same trick works for any joystick or mouse button. The final benefit is that it explicitly allows chorded buttons on the joystick to be decoded. This is useful for people with low button count joysticks. I also see a benefit in having a clean way (compared to how we do it now) of switching a joystick axis between multiple analog input options. This can be handled the same way, though again, it will be verbose. I'm trying to figure out some structural simplifications. One problem with using conditions is that you have to use them anywhere -- if I set up modal input using conditions, bindings that don't know about the mode will charge on blindly ahead; modifiers, on the other hand, cause bindings that don't know about them to be skipped. 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] Modal mouse thoughts
Erik Hofman writes: What i *realy* like about the new code is the way the mouse pointer moves from one side of the screen to the other side when clipping to the borders. Thanks. What I don't like is the fact that, when changing pointers, the view stays fixed to the last position. I'm realy lost at where I'm looking at and where I should expect the front of the plane. I would suggest that the view direction would be reset to straight ahead when switching modes. It isn't hard to change the file to make the view snap back when you leave mouse-view mode -- we'll just have to choose a default. Personally, I prefer to have the view direction stay put when I leave mouse view mode, especially when using the 3D cockpit. What does everyone else think? In the meantime, I did bind mouse button 1 in view mode to snap the view forward, and you can use that before clicking out if you want. 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] Configurable mouse progress
Norman Vine writes: necessary fix so that PUI can do it's thing Thanks for the patch, Norm. It compiled fine and didn't cause any obvious problems, but I noticed that the menu didn't disappear with mouse motion as intended. I have no objection to adding the glutPostRedisplay calls (they cannot hurt, since FlightGear redraws the whole window every frame anyway). I am curious, though, about why you moved the puMouse calls from FGInput::doMouseClick and FGInput::doMouseMovement to GLUTmouse and GLUTmotion. I deliberately made the puMouse calls conditional on pass_through so that PUI would *not* see clicks and movement in alternative modes like the view mode -- with your change, PUI will always see clicks and movement, no matter what the mouse mode. Am I totally misunderstanding how PUI works? 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] Modal mouse thoughts
Curtis L. Olson writes: I finally got a chance to try the new 3d cockpit interior and it is a very good start. It's pretty awkward trying to fly with the keyboard and pan the view with the mouse since I'm used to flying with the mouse. In that case, consider rebinding the arrow keys to pan the view. That worked well for me (I keep it as a local mod loaded from my .fgfsrc). I'm appending the bindings to the end of this message. I did a lot of autopilot assist and it's very interesting. It does give you a much better feeling of being inside an aircraft. Portions of the scene that should be blocked out are blocked out. The only thing missing to make it completely realistic is a large individual in the right seat to totally block your view out there. I'll accept contributions of 3D models. Here are my bindings for making the arrow keys control the view: PropertyList input keyboard key n=356 nameLeft/name descScroll view left/desc binding commandproperty-adjust/command property/sim/view/goal-offset-deg/property step1/step /binding /key key n=357 nameUp/name descScroll view up/desc binding commandproperty-adjust/command property/sim/view/goal-tilt-deg/property step1/step /binding /key key n=358 nameRight/name descScroll view right/desc binding commandproperty-adjust/command property/sim/view/goal-offset-deg/property step-1/step /binding /key key n=359 nameDown/name descScroll view down/desc binding commandproperty-adjust/command property/sim/view/goal-tilt-deg/property step-1/step /binding /key /keyboard /input /PropertyList 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] Modal mouse thoughts
Norman Vine writes: This was IMHO necessary for the MOUSE_YOKE mode and very useful for the other modes. Some of this was compile time configurable, FWIW this was fairly tricky to get right at first but is fairly straight forward once you figure out what you need. ie when cycling into YOKE Mode you want the cursor to reflect current state of the stick !! I don't know how the mouse code ended up, but when I originally wrote it, this wasn't necessary -- I just used scaled mouse movement to move the controls, rather than reading an absolute screen position (as I would with a joystick), so there was no need for the mouse code to remember the mouse's screen position. I'm doing the same thing now in the new input.cxx code, and yoke mode seems to work OK. I think that most of this can be programmed into the newer system if wanted by adding saved_x, saved_y mouse position in each of the modes. ie give each mode state as to cursor location. Again, I use the amount of mouse movement rather than the absolute screen position to control the view (and did in the original GUI mouse code as well), so there is no need to keep the original position except for aesthetics. It wouldn't be hard to code up multiple saved viewpoints, but I think that we should wait to see how Jim's viewer overhaul turns out first. 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] HUD xml files
Norman Vine writes: previously sent patch for hud.cxx required ! These add a NEW elevator trim marker along side the elevator position gauge also adds missing cemterpoint tick marks FYI With this you can see what the AutoPilot is doing when in one of the 'altitude modes' I've updated the source code and base package CVS with Norm's patches, and they work well. Thanks. 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] Configurable mouse progress
Norman Vine writes: HINT - try testing the autopilot adjuster and the Pilot Offset adjuster if you want to see if you are cooperating with PUI when handling mouse events Yes, it works but there seems to be some confusion between passive motion and motion -- I'll look into fixing that. 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] Normans changes
Erik Hofman writes: I think I just got the conformation from both you and David. It's a bit hard to tell if they get applied, when the patches are sent to the list and nobody responds. You need to subscribe to the CVS lists -- then you get an e-mail for every checkin to the repository. 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] Modal mouse thoughts
Andy Ross writes: The issue of visual feedback is a good point. I wonder if the best solution would be to turn off the mouse cursor entirely and use the control indicators on the panel or hud? I've been thinking along the same lines. We need some kind of visual feedback, though, so that the user knows what mouse mode she's in. Any suggestions? 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] Modal mouse thoughts
Alex Perry writes: On the 2D panel and the HUD, we already have visual control feedback. On the 3D panel, we can replace the scale indicators with a moving yoke. Yes, that's coming very soon. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
