Re: [Flightgear-devel] Bug with c310
One other nit: retracting the gear while sitting on the runway doesn't work like it should. :-) I'm happy that is works as it does now, because I don't get an airplane crash when I forget the gear before landing :-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Doc Check
snip altimeter-datum-mb1013.25/altimeter-datum-mb I assume that this is the setting for the WGS-84 datum. It is the pressure setting on the altimeter, that can be adjusted by turning the knob on the altimeter. I assume that it is in mm of Hg? No, it is in millibar (mb) as specified in the property name. Richard. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Doc Check
altimeter-datum-mb1013.25/altimeter-datum-mb I assume that this is the setting for the WGS-84 datum. It is the pressure setting on the altimeter, that can be adjusted by turning the knob on the altimeter. I assume that it is in mm of Hg? It is in milibars ie 1mb=100 Pascal Madr ___ 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
RE: [Flightgear-devel] SimGear and --with-jpeg-factory
Richard Bytheway writes: I have noticed that when compiling --with-jpeg-factory on cygwin (Win98) I get an error regarding redefinition of (long) int types between the jpeg headers and win32 headers. I can't remember the exact details, will post them tomorrow. ~ line 250 jmorecfg.h #ifndef XMD_H /* X11/xmd.h correctly defines INT32 */ / typedef long INT32; #endif There is a conflict between some versions of Cygwin Win32 Headers and some Versions of jmorecfg.h See above for my local fix BTW This is not FGFS specific Norman attachment: winmail.dat
Re: [Flightgear-devel] Kudos for Tony
--- David Megginson [EMAIL PROTECTED] wrote: 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. Thanks, David, and thanks again for catching my error with FGPropertyManager.h. 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. It probably is, but I haven't given a lot of thought to what should be settable and what shouldn't, so doing so may have interesting results. Be aware also that some of the things which are settable are just flat out ignored (under most circumstances) by the C++. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Yahoo! Sports - live college hoops coverage http://sports.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
David Megginson wrote: Norman Vine writes: 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. While I don't see a direct improvement in framerate I notice a real effect on the screen update. The old behaviour had a small bump in the update every second or so, while the new code elliminates that. This makes me vote for including the patch. Erik BTW. This is probably only noticable on slower machines with a slow OpenGL implementation like the O2 I work on. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Kudos for Tony
Tony Peden wrote:
--- David Megginson [EMAIL PROTECTED] wrote:
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.
Thanks, David, and thanks again for catching my error
with FGPropertyManager.h.
Could you both remove FGPropertyManager:: from the class declaration
in FGPropertyManager.h please. MipsPro won't allow it:
e.g.
class FGPropertyManager:public SGPropertyNode {
public:
FGPropertyManager::FGPropertyManager(void) {
}
becomes:
class FGPropertyManager:public SGPropertyNode {
public:
FGPropertyManager(void) {
}
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Kudos for Tony
If David doesn't beat me to it, I'll do it when I get
home this evening.
--- Erik Hofman [EMAIL PROTECTED] wrote:
Tony Peden wrote:
--- David Megginson [EMAIL PROTECTED] wrote:
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.
Thanks, David, and thanks again for catching my
error
with FGPropertyManager.h.
Could you both remove FGPropertyManager:: from the
class declaration
in FGPropertyManager.h please. MipsPro won't allow
it:
e.g.
class FGPropertyManager:public SGPropertyNode {
public:
FGPropertyManager::FGPropertyManager(void) {
}
becomes:
class FGPropertyManager:public SGPropertyNode {
public:
FGPropertyManager(void) {
}
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
__
Do You Yahoo!?
Yahoo! Sports - live college hoops coverage
http://sports.yahoo.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs-base or Flightgear problem on Linux - Alpha
Aaaah, that sounds interesting. Are you building FlightGear on Tru64 or on Linux ? I have a 300 MHz AlphaServer1000 at home - yet without graphics board - with Tru64 on it. Although my machine don't have an AGP slot (does your's ? I believe r128 is AGP only !?) I might put some other PCI board in and have a try Martin. Tru64 and Opengl is kind of a mistery to me. From what i remember, first you need a supported graphics adaptor, i.e Digital 4d20, 4d50, 4d51 (Cpq has new ones too...) Then you need a sepatate OPEN3D license (Not included in the OS). IMHO. OTOH, if you really want to try, see http://moon.hanya-n.org/comp/alpha/hct/graphics.html Besides, PCI video cards are cheap by now. Me? I have a Digital Server 3305 (Like an AS800 , but built for NT), with a 16 mb Ati 128 PCI card, with Linux. It's a nice machine. Getting DRI to work was a headache. I was thinking about gzip failures (compiler related), do you know if there is any way to retrive the scenary files uncompressed?. The gcc port is not very good on the alpha, sadly. Regards Roberto de Iriarte [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-devel] Nvidia specific drawing and plib/Flightgear
Marten Stromberg wrote: Roman Grigoriev wrote: Guys could you please explain me some state of things 1) plib and vertex arrays Does this feature implement yet in plib or not if not mybe there are some suggestions how to make it As I understand now plib works with display lists this can speed up rendering process but if we use vertex arrays it will be more faster so we can run for example ./configure --with-nvidia-ext as I understand when I load models from 3ds I should get vertexes normals and texture coordinates for separate arrays and locate them to card memory or there are another way? PLIB supports vertex arrays already - but whether the model loaders generate vertex arrays or one of the several other data structures is an open issue. It's hard to make them do what *everyone* wants simultaneously. 2) multitexturing and plib To implement lightmaps for FGFS (light lobes) I need multitexturing The process: 1) read all poligons vertexes,normals,texcoords 2) use multitexturing 3) compute lightmaps 4) apply main texture and lightmaps texture Any suggestions how to make it using plib I don't think PLIB should be taking on the task of generating the lightmaps. But multitexture support is clearly a critical thing we need to implement fairly soon. We have discussed how to implement multitexturing support, and it turns out to be pretty hard to do without causing minor performance penalties for single-textured geometry. To be realistic, I do not think you will se it happen until the next major release of PLIB (but I promise to try and push it the best I can). Well, I'd like to get a minor/stable release done fairly soon so we can move on with some of these major issues. The last time I suggested we do that, a few people said they needed to fix a few items - so I held off from doing that - but we need to re-visit that. What does everyone need to do before we make a new stable release? - Steve Baker --- Mail : [EMAIL PROTECTED] WorkMail: [EMAIL PROTECTED] URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel_io.cxx,1.36,1.37
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.21 08:58]:
Index: panel_io.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel_io.cxx,v
retrieving revision 1.36
retrieving revision 1.37
diff -C2 -r1.36 -r1.37
*** panel_io.cxx 19 Mar 2002 16:12:15 - 1.36
--- panel_io.cxx 20 Mar 2002 14:57:31 - 1.37
***
*** 296,300
}
! if (propName != ) {
target = fgGetNode(propName.c_str(), true);
}
--- 296,300
}
! if (propName != (string)) {
target = fgGetNode(propName.c_str(), true);
}
As Bernie has mentioned before[1], this should be:
if (!propName.empty()) {
And for someone who has time, there's plenty more of these to be fixed:
$ cd FlightGear/src/
$ find . -type f -name '*.[ch]??' | xargs grep -n '[=!]= '
./ATC/ATCmgr.cxx:112: if(last_comm1_ident != ) {
./FDM/JSBSim/FGConfigFile.cpp:129: if (val == ) {// this call is to return the
tag value
./FDM/JSBSim/FGScript.cpp:190: if (aircraft == ) {
./Cockpit/panel.cxx:1079: if (_fmt == )
./Cockpit/panel.cxx:1087: if (_fmt == ) {
./Cockpit/panel_io.cxx:291: if (type == ) {
./Cockpit/panel_io.cxx:393: if (type == ) {
./Cockpit/panel_io.cxx:468: if (type == ) {
./Cockpit/panel_io.cxx:551:else if (layerclass == ) {
./Cockpit/panel_io.cxx:718: if (bgTexture == )
./Cockpit/panel_io.cxx:732:if (mbgTexture == )
./Cockpit/panel_io.cxx:738:if (mbgTexture == )
./Cockpit/panel_io.cxx:744:if (mbgTexture == )
./Cockpit/panel_io.cxx:750:if (mbgTexture == )
./Cockpit/panel_io.cxx:756:if (mbgTexture == )
./Cockpit/panel_io.cxx:762:if (mbgTexture == )
./Cockpit/panel_io.cxx:768:if (mbgTexture == )
./Input/input.cxx:113: if (_command_name == ) {
./Main/fg_init.cxx:143:if ( root == ) {
./Main/fg_init.cxx:158:if ( root == ) {
./Main/fg_init.cxx:168:if ( root == ) {
./Main/fg_init.cxx:177:if ( root == ) {
./Main/fg_props.cxx:145: if (classes == || classes == all) { // default
./Main/fg_props.cxx:203: } else if (priority == || priority == info) { // default
./Navaids/fixlist.cxx:106:if ( fix-get_ident() == ) {
./Network/props.cxx:206: if ( ttt == ) {
./Network/props.cxx:272: if ( prompt == ) {
./Sound/fg_fx.cxx:56: if (path_str == ) {
$ find . -type f -name '*.[ch]??' | xargs grep -n '[=!]= (string)'
./src/Cockpit/panel_io.cxx:298: if (propName != (string)) {
./src/Cockpit/panel_io.cxx:727: if (mbgTexture != (string)) {
./src/GUI/gui.cxx:170:if (throwable.getOrigin() != (string)) {
./src/Main/fg_props.cxx:108: if (result != (string))
./src/Scenery/FGTileLoader.cxx:95: if ( globals-get_fg_scenery() != (string) ) {
./src/Sound/soundmgr.cxx:248:if (file == (string))
$ cd SimGear/simgear/
$ find . -type f -name '*.[ch]??' | xargs grep -n '[=!]= '
./io/sg_socket.cxx:192:if ( port_str == || port_str == any ) {
./io/sg_socket_udp.cxx:59:if ( port_str == || port_str == any ) {
./misc/props.cxx:274: else if (components[position].name == ) {
$ find . -type f -name '*.[ch]??' | xargs grep -n '[=!]= (string)'
./misc/exception.cxx:89: if (_path != (string)) {
./timing/sg_time.cxx:91:if ( root != (string) ) {
[1] http://mail.flightgear.org/pipermail/flightgear-cvslogs/2002-March/001102.html
--
Cameron Moore
[ If a mute kid swears, should his mother wash his hands with soap? ]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Manager Changes
I've now modified the property-manager interface to use const char * instead of std::string throughout the public interface [...] I have the impression that the flaps are gone. I try to set the flaps via ], I can see the lever moving over the panel but I can't 'feel' the flaps and they don't move on the animated c310u3a. Some connection has been lost, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 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. That sounds very impressive (don't have time to try it right now). ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault on mini-panels
When I try to switch to a mini-panel, I always get a segfault (I've tested in c172 and c310). Is anyone else seeing this? I'm using a clean CVS build from yesterday (ie. prior to David's property code changes) with no command-line options. Thanks It was working for me a couple of days ago; but the viewport window was the wrong size so that shrinking the panel didn't make much extra scenery visible. ___ 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] Re: yasim flaps
Sounds to me like you've got that wing section (i.e. the flap) beyond the peak of the L/D curve, while the bulk of the wing is in front of the L/D curve. If that is the case, it is certainly something that will often happen in real life and your solver needs to cope with it. Without looking at the code, I can't make specific suggestions. Curtis L. Olson wrote: So, if I am at my max speed with 0 flaps in a straight and level configuration, then there is *no way* that lowering the flaps should net you additional speed while maintaining the same straight and level flight path. I don't care how well you explain it. :-) Not buyin' it, huh? OK, you're right. There's a bug. But, to be fair, my explanation (or hand-waving, you make the call) was spot on, too. :) The problem is actually kind of deep. YASim specifies control surface drag in relative units. A flap with a drag of 2 will double the surface's drag when deployed. And, in fact, it does. But in the wrong coordinates. Because the code works in the surface's orientation (each Surface object gets its own orientation matrix in YASim), the value I'm doubling is the drag along the surface plane -- what amounts to the parasite drag in most treatments. The induced drag, which constitutes the bulk of the actual force in anything but an unloaded dive, isn't changed. So drag goes up only a little. But lift goes up a lot, so the autopilot trims the aircraft to a lower AoA, and the overall drag goes *down* for the same lift. Which is the bogus effect you saw. So, the obvious solution would be to multiply the drag along the relative wind direction, instead of along the surface plane. Unfortunately, this causes the YASim solver to blow up and fail to find a solution. Here's an attempt at an explanation: The solver is basically a Newton-Raphson engine that twiddles two variables: the lift-to-drag ratio of the wings, and the overall drag coefficient. It modifies the L/D ratio to keep the plane in the air at the approach speed, and modifies the overall drag to make the drag equal to the thrust at the specified cruise speed (it also plays with the cruise AoA and tail incidence, but those aren't relevant to this problem). But in this situation, it gets into a divergent cycle. The solver bumps the L/D ratio a little bit. But this causes the drag to go up, too, since some of the lift is pointing backwards at non-zero AoA. So the overall drag coefficient gets pushed down a bit to compensate. But now, we need more lift! So the L/D ratio goes up again, and the drag down, and the thing diverges. There's a deep truth here that I'm not seeing. The functions here are all continuous, and real-world systems based on continuous functions can't show this kind of divergence (there's a theorem to that effect somewhere). I'll keep thinking; whack me if I've missed something obvious. I suspect the final solution is going to have to work in the surface's drag plane, and not the winds... Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Property Manager Changes
Jim Wilson wrote: David Megginson [EMAIL PROTECTED] said: I've fixed everything I could find in the code base (engine sound isn't working, but it wasn't working before my mods either), Engine sound seems to be working, but I notice on the c172-3d the volume is quite low (and the wheel rumble is very loud). It would be best to point to c310/c310-sound.xml from the c310u3a-set.xml file. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Andy Ross [EMAIL PROTECTED] said: Erik Hofman wrote: While I don't see a direct improvement in framerate I notice a real effect on the screen update. The old behaviour had a small bump in the update every second or so, while the new code elliminates that. This doesn't make much sense. All of the changes in that patch were inside the per-frame loop. They certainly couldn't cause or fix stutter over many frames, nor do I think have they been claimed to. Perhaps something happened in the tile loader to do this? I don't know, cpu cycles are cpu cycles...they're good for anything aren't they? If you reduce per-frame-code-load then that frees time up for other tasks like disk io. Or am I confused about this? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
I don't know, cpu cycles are cpu cycles...they're good for anything aren't they? If you reduce per-frame-code-load then that frees time up for other tasks like disk io. Or am I confused about this? You are confused about that. Most modern processors are memory bandwidth limited. That's what killed RISC. If you inline code, you save on the frame setup, but it costs memory bandwidth. So, you have to ask whether there will be more idled instructions, while waiting for the processor instruction cache to be filled with inline code, or instructions that are constructively doing the frame thing out of cache (because the subroutine itself is probably in cache). ___ 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
David Megginson writes: 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. Could this be a side effect of the property manager overhaul? I'm not sure what else has changed recently that could be related. - 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. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
David Megginson writes: 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 I'm not aware of changing anything there at all, unless someone submitted a patch that changed the default logging level and I didn't notice it. If it did get changed, could someone put it back to what it was? I'm not familiar with this section of code myself. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] 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] New SimGear does not Build Under MSVC 6.0
Jonathan Polley wrote: I just updated to the newest SimGear and tried to build under Windows using MSVC 6.0. When I did so, I got the following errors: I haven't tried it since the last major checkins :( Linux was just fine. Is there a problem with MS' implementation of STD? That's more likely to be a problem with the Linux STL, as the M$ one is very standard compliant and strict. So there used to be a lot of STL problems where Linux coders wrote non standard compliant STL code that brok on MSVC. (They are not really to blame as they have no chance to test their code on MSVC; and they are definitely not doing it on puropse) CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague Whoever that is/was; (c) by Douglas Adams would have been better... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Re: Obvious Speedups
Andy Ross 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 Cheers NOrman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Minor nits
It seems to be minor nit time, so here goes: The tiled panel has lines between the sections - is anyone else seeing this or is it a Windows only problem. As someone else has pointed out, resizing the screen can cause the panel to obscure the runway. In general the panel could be made slightly less tall IMHO - the registration mark takes up otherwise unused vertical space and the instruments could be squeezed a fraction closer together vertically. Thats probably a matter of taste though. It would be much better to start up with the brake on (IMHO. The vibration (JSBSim) with the brake on at standstill occurs whether the engine is on or off. And a long standing one that I've never heard anyone else mention - I get other colours and textures bleeding through at the runway touchdown zones and numbers, when viewed at certain shallow angles. This happens on several varieties and combinations of Windows, processor and graphics card. I've not seen it on any of the screenshots that John and Curt have put up - am I the only one seeing this? And now NaN (Not-a-Nit) :-) the new engine starting sounds are excellent. Great stuff whoever came up with those. (Erik?) Cheers - Dave -- [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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Mar 2002 22:31, you wrote: 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. Could we handle it with some form of arbitary level of detail? i.e. at a certain distance chance roads to lines, then make them disappear completely further away? I suppose similiar would need to be done to the terrain to drop the detail level there too. Thanks, David -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8mQqsF2H7v0XOYBIRAuiBAJ9vmWqLTLdcda35vas8pnOE8uQ9SQCdEllP /og6x9smZWL9YoC4stmZREE= =08iu -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC6.0
Jon S Berndt wrote:
On Wed, 20 Mar 2002 22:55:23 +0100
Christian Mayer [EMAIL PROTECTED] wrote:
So there used to be a lot of STL problems where Linux coders wrote non
standard compliant STL code that brok on MSVC. (They are not really to
blame as they have no chance to test their code on MSVC; and they are
definitely not doing it on puropse)
I remember there was also perfectly good code that broke
under MSVC. Is this one fixed:
{
for (int i=0;i5;i++) {
// do something
}
for (int i=7;i13;i++) {
// do something else
}
}
The second for loop was causing problems with MSVC because
it choked on the for-block-scoped int i declaration.
Yes, that's a known PITA of MSVC. But that's a limitation of MSVC, the
STL stuff is actually a feature (bug or feature, the old question...
While I'm here: does the current JSBSim compile without
problems under MSVC?
At least a version that's a couple of days old. Dunno about the property
system changes though.
CU,
Christian
--
The idea is to die young as late as possible.-- Ashley Montague
Whoever that is/was; (c) by Douglas Adams would have been better...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
On Wed, 20 Mar 2002 22:55:23 +0100
Christian Mayer [EMAIL PROTECTED] wrote:
So there used to be a lot of STL problems where Linux coders wrote non
standard compliant STL code that brok on MSVC. (They are not really to
blame as they have no chance to test their code on MSVC; and they are
definitely not doing it on puropse)
I remember there was also perfectly good code that broke
under MSVC. Is this one fixed:
{
for (int i=0;i5;i++) {
// do something
}
for (int i=7;i13;i++) {
// do something else
}
}
The second for loop was causing problems with MSVC because
it choked on the for-block-scoped int i declaration.
While I'm here: does the current JSBSim compile without
problems under MSVC?
Jon
___
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
RE: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Jon S Berndt writes:
I remember there was also perfectly good code that broke
under MSVC. Is this one fixed:
{
for (int i=0;i5;i++) {
// do something
}
for (int i=7;i13;i++) {
// do something else
}
}
The second for loop was causing problems with MSVC because
it choked on the for-block-scoped int i declaration.
AFAIK only in the new 'net' compiler
Note however that AFAIK the following variation
does work in MSVC
{
{
for (int i=0;i5;i++) {
// do something
}
} {
for (int i=7;i13;i++) {
// do something else
}
}
}
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Norman Vine wrote: Removed fgReshape() call from main loop That's undoubtedly a good thing. Never mind who can see a speed benefit and who can't. I can only imagine it was put there to work around some bug. If so, let's see if the bug shows up again, and fix it properly if it does. Removed fgIdle from the main loop once things are up and running 1) initially glutDisplayFunc() is set to new mySplashDraw function 2) when idle state reaches 1000 glutDisplayFunc() set to fgRenderFrame() glutIdleFunc() reassigned to fgMainLoop() This only saves a few integer comparisons at run time, but looks like a good logical clean-up. Made a local copy of a property value when it is used multiple times inside of the same function and used it moved static property nodes pointers from function scope to file scope. I'm ambivalent about these. I can't check frame rate because mine is continuously fluctuating by about 10% from one second to the next, and depends very strongly on the exact view. - Julian ___ 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
Not fixed in VC6. Fixed in VC7.
However, the STDLIB and STL implementations in VC6 and VC7 are very good.
But, they weren't written by Microsoft. They were written by P.J. Plauger's
company.
Regards.
Mark K Vallevand
Fat, dumb and happy. 2 out of 3 ain't bad.
I remember there was also perfectly good code that broke
under MSVC. Is this one fixed:
{
for (int i=0;i5;i++) {
// do something
}
for (int i=7;i13;i++) {
// do something else
}
}
The second for loop was causing problems with MSVC because
it choked on the for-block-scoped int i declaration.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] inlining
Are we finding that inlining is unneccesary? I am wondering if Tony and I need to un-inline most of our currently inlined items? We have a lot of access methods that simply return a private value. Those at least seem to be classic cases for inlining. What's everyone else doing? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Cockpit, cont'd
David Megginson wrote: 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. You miss the point. The code already *does* figure out the transformation given the corners. :) The only thing you have to do is fill in the corner coordinates to match the numbers you're already generating in the model file. It can be as simple as drawing a named quad to represent the panel in the cockpit model, grabbing the coordinates from that manually and typing them into the XML, or as complicated as providing the XML with the symbolic name of the quad and having the panel work it out. But really, there's no math or rendering code required -- you just have to fill in values for the a, b and c vectors in the panel code. (Well, there's an axis swap involved -- these values are in OpenGL screen coordinates, not model orientation, so X is left, Y up and Z backwards). I'd do this myself, but I'm clueless about cockpit authoring. What you have right now is as close as I could come without actually doing cockpit design. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rudder animation reversed in c172-yasim
Curtis L. Olson wrote: In the c172-yasim external view, the rudder animation on the 3d model is reversed. Everything else seems to go the correct direction. Does the YASim -set file use a different model from the JSB one? This is probably a convention collision between YASim and JSB. My guess is that the DC-3 rudder (which works correctly in YASim) rotates in the opposite direction from the C-172 (which presumably works right JSB). We should just pick one direction as positive. YASim natively has a positive rudder deflection producing a yaw to the left. Changing that can be done in the XML files by reversing the destination values of the property output. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Obvious Speedups
Julian Foad wrote: Norman Vine wrote: Removed fgReshape() call from main loop That's undoubtedly a good thing. Never mind who can see a speed benefit and who can't. I can only imagine it was put there to work around some bug. If so, let's see if the bug shows up again, and fix it properly if it does. With Norman's main, maximising the window and then returning it to 800x600 leaves the external view of the plane (and probably the scenery but its hard to tell) all scrunched up. I suspect this is probably what you're looking for... Cheers - Dave -- [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
Norman Vine wrote:
The second for loop was causing problems with MSVC because
it choked on the for-block-scoped int i declaration.
AFAIK only in the new 'net' compiler
In the new .NET compiler (i.e. version 7) it's fixed, the old one (MSVC
6) has that problem.
Note however that AFAIK the following variation
does work in MSVC
{
{
for (int i=0;i5;i++) {
// do something
}
} {
for (int i=7;i13;i++) {
// do something else
}
}
}
Yes, it does. But it's sort of ugly. But not as ugly as a #define I've
seen once that fixes that problem, too.
CU,
Christian
--
The idea is to die young as late as possible.-- Ashley Montague
Whoever that is/was; (c) by Douglas Adams would have been better...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
MSVC 6.0 still whines about
props.cxx
C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not a member of 'std'
C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol cannot be used in a using-declaration
C:\SimGear\simgear\misc\props.cxx(801) : error C2065: 'sort' : undeclared identifier
,,,
#include simgear/compiler.h>
#include simgear/debug/logstream.hxx>
SG_USING_STD(sort); -- This is line 24
...
vectorSGPropertyNode *>
SGPropertyNode::getChildren (const char * name)
{
vectorSGPropertyNode *> children;
int max = _children.size();
for (int i = 0; i max; i++)
if (compare_strings(_children[i]->getName(), name))
children.push_back(_children[i]);
sort(children.begin(), children.end(), CompareIndices()); -- Line 801
return children;
}
...
Jonathan Polley
On Wednesday, March 20, 2002, at 07:44 AM, David Megginson wrote:
Jonathan Polley writes:
I just updated to the newest SimGear and tried to build under Windows
using MSVC 6.0. When I did so, I got the following errors:
I've moved the include for algorithm> higher in the file -- try
checking it out again and see if it builds 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] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel_io.cxx,1.36,1.37
Cameron Moore wrote:
* [EMAIL PROTECTED] (Curtis L. Olson) [2002.03.21 08:58]:
Index: panel_io.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit/panel_io.cxx,v
retrieving revision 1.36
retrieving revision 1.37
diff -C2 -r1.36 -r1.37
*** panel_io.cxx 19 Mar 2002 16:12:15 - 1.36
--- panel_io.cxx 20 Mar 2002 14:57:31 - 1.37
***
*** 296,300
}
! if (propName != ) {
target = fgGetNode(propName.c_str(), true);
}
--- 296,300
}
! if (propName != (string)) {
target = fgGetNode(propName.c_str(), true);
}
As Bernie has mentioned before[1], this should be:
if (!propName.empty()) {
And for someone who has time, there's plenty more of these to be fixed:
$ cd FlightGear/src/
$ find . -type f -name '*.[ch]??' | xargs grep -n '[=!]= '
./ATC/ATCmgr.cxx:112: if(last_comm1_ident != ) {
[snip]
Just to make life more complicated, the latest changes to the property
system return const char* instead of std::string. Don't know if it will
have any impact on this todo item.
Bernie
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
David Megginson 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 :-))
== cut ===
#include iostream
#include time.h
#define NUM_TESTS 1
double jnk = 0.0;
double make_junk( double a );
inline double test_junk( double a )
{
return (a-NUM_TESTS/2) 0 ? 0 : 1;
}
int main(int argc, char **argv)
{
int i;
int start;
start = clock();
for( i=0; iNUM_TESTS; i++)
{
jnk = make_junk(i);
}
cout elapsed clock() - start endl;
start = clock();
for( i=0; iNUM_TESTS; i++)
{
jnk = test_junk(i);
}
cout elapsed clock() - start endl;
}
double make_junk( double a )
{
return (a-NUM_TESTS/2) 0 ? 0 : 1;
}
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
Jonathan Polley wrote:
MSVC 6.0 still whines about
props.cxx
C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not a member of
'std'
C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol cannot be used
in a using-declaration
C:\SimGear\simgear\misc\props.cxx(801) : error C2065: 'sort' : undeclared identifier
Dunno, but have you tried to add a
SG_USING_NAMESPACE(std);
above the SG_USING_STD(sort); ?
CU,
Christian
,,,
#include simgear/compiler.h
#include simgear/debug/logstream.hxx
SG_USING_STD(sort); -- This is line 24
...
vectorSGPropertyNode *
SGPropertyNode::getChildren (const char * name)
{
vectorSGPropertyNode * children;
int max = _children.size();
for (int i = 0; i max; i++)
if (compare_strings(_children[i]-getName(), name))
children.push_back(_children[i]);
sort(children.begin(), children.end(), CompareIndices()); -- Line 801
return children;
}
...
Jonathan Polley
On Wednesday, March 20, 2002, at 07:44 AM, David Megginson wrote:
Jonathan Polley writes:
I just updated to the newest SimGear and tried to build under Windows
using MSVC 6.0. When I did so, I got the following errors:
I've moved the include for algorithm higher in the file -- try
checking it out again and see if it builds now.
All the best,
David
--
David Megginson
[EMAIL PROTECTED]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
The idea is to die young as late as possible.-- Ashley Montague
Whoever that is/was; (c) by Douglas Adams would have been better...
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] inlining
Norman Vine wrote: Really ?? then try this both with and without optimization :-)) This program fits easily into the L1 cache. FlightGear does not. For small programs, total instructions executed is more important than code size. For most real programs on modern processors, just the opposite is true. Try writing a perl script that duplicates this code, say, 10k times (varying the symbol names each time) and iterates through each one of them. My guess is that you'll see the performance gain from inlining either disappear or turn into a loss. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] inlining
Norman Vine wrote: 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 even more complicated than that. If you call a function thousands of times in succession, then it almost always pays to inline it. If you call it the same number of times, but interspersed evenly with the rest of the code, inlining is only going to thrash the cache and hurt performance. I have nothing against re-inlining stuff once it's profiled and shown to have a performance benefit, but inlining by default because it looks faster is self-defeating. FWIW, my interest in un-inlining stuff has nothing to do with runtime performance at all. What I want to see is for FlightGear to compile in something under 20 minutes on my machine. Some parts are really just terribly slow to build. JSBSim and UIUC are big culprits here, but the WeatherCM stuff and the Main directory aren't far behind. I mean, think about it: this compilation, if run on a VAX 11/780, would take 13 days! FlightGear is a big program, granted. But is it big enough to justify two weeks of machine time to compile? Sure, programmers are writing bigger software these days, but not *that* much bigger. FlightGear strikes me as about the same level of complexity as the whole of 4BSD Unix. Naively, I'd want it to build in about the same time. I'm certain 4BSD didn't take two weeks to build. :) [I'm assuming that a VAX performs about the same as a 1 MHz Athlon here, which is roughtly in the ballpark.] Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New SimGear does not Build Under MSVC 6.0
On Wednesday, March 20, 2002, at 06:00 PM, Christian Mayer wrote: Jonathan Polley wrote: MSVC 6.0 still whines about props.cxx C:\SimGear\simgear\misc\props.cxx(23) : error C2039: 'sort' : is not a member of 'std' C:\SimGear\simgear\misc\props.cxx(23) : error C2873: 'sort' : symbol cannot be used in a using-declaration C:\SimGear\simgear\misc\props.cxx(801) : error C2065: 'sort' : undeclared identifier Dunno, but have you tried to add a SG_USING_NAMESPACE(std); above the SG_USING_STD(sort); ? If I replaced SG_USING_SD(sort) with SG_USING_NAMESPACE(std) it compiled just fine. I then found errors with FlightGear proper (but that is another email). CU, Christian Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] segfault on mini-panels
Here's a backtrace on this. Best, Jim #0 0x82ddfba in SGPropertyNode::clear_value (this=0x9747f90) at props.cxx:464 464 delete _value.string_val; #1 0x82de8e0 in SGPropertyNode::~SGPropertyNode (this=0x9747f90, __in_chrg=3) at props.cxx:672 #2 0x806c0e0 in FGComparisonCondition::~FGComparisonCondition ( this=0x95e9850, __in_chrg=3) at fg_props.cxx:1007 #3 0x806b39d in FGAndCondition::~FGAndCondition (this=0x97156c0, __in_chrg=3) at fg_props.cxx:859 #4 0x806d128 in FGConditional::~FGConditional (this=0x9747f50, __in_chrg=3) at fg_props.cxx:1163 #5 0x80b4f18 in FGInstrumentLayer::~FGInstrumentLayer (this=0x9747f50, __in_chrg=3) at panel.cxx:848 #6 0x80b52e1 in FGTexturedLayer::~FGTexturedLayer (this=0x9747f50, __in_chrg=3) at panel.cxx:939 #7 0x80b4b64 in FGLayeredInstrument::~FGLayeredInstrument (this=0x9747f18, __in_chrg=3) at panel.cxx:781 #8 0x80b2ac4 in FGPanel::~FGPanel (this=0x8f86838, __in_chrg=3) at panel.cxx:199 #9 0x80581fc in do_panel_load (arg=0x922c2d0, state=0x922c2c8) at fg_commands.cxx:209 #10 0x82b5105 in FGBinding::fire (this=0x922c2b0) at input.cxx:138 #11 0x82b551f in FGInput::doKey (this=0x8566300, k=115, modifiers=0, x=301, y=-10) at input.cxx:246 #12 0x82b7961 in GLUTkey (k=115, x=301, y=-10) at input.cxx:724 #13 0x400822aa in processEventsAndTimeouts () from /usr/X11R6/lib/libglut.so.3 Alex Perry [EMAIL PROTECTED] said: When I try to switch to a mini-panel, I always get a segfault (I've tested in c172 and c310). Is anyone else seeing this? I'm using a clean CVS build from yesterday (ie. prior to David's property code changes) with no command-line options. Thanks It was working for me a couple of days ago; but the viewport window was the wrong size so that shrinking the panel didn't make much extra scenery visible. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Problems Building JSBSim using MSVC 6.0
After getting SimGear to build under MSVC 6.0 (thanks Christian), I moved on to getting all of FlightGear to build. For some reason, MSVC does not like JSBSim (over 1200 errors generated) but I had no problem under RH 7.1 (as usual). I expect that everything is a snow ball started from the errors in FGPropertyManager.h. The full build result file can be found at: http://homepage.mac.com/eq_fidget/FG_Dox/FlightGear.html Thanks, Jonathan Polley ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug with c310
On Wed, 20 Mar 2002 09:32:22 +0100 (CET), Martin Spott [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: One other nit: retracting the gear while sitting on the runway doesn't work like it should. :-) I'm happy that is works as it does now, because I don't get an airplane crash when I forget the gear before landing :-) ..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. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: SuSE new release ad page
On Wed, 20 Mar 2002 09:29:39 -0800 (PST), Alex Perry [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: I totally forgot Are you (Alex) using an Nvidia graphics board ? Occasionally; the E-machines chassis I support for demo usage at LWCE SFO, for example, has a TNT2 card in it which runs FGFS under XF3 and Utah-GLX. The non-demo disk drive I use at home has the NV supplied driver, but I rarely actually use the console because I normally Xnest in from elsewhere. O.k., as I remember you do not. But many pople on this list do. So there seems to be very little objection to using closed source software, I have no objection to _using_ closed source software personally. I don't _support_ a collection of software that includes closed source unless my time is paid at full rate to do so. It's too frustrating. In any case, my engineering preferences should have no impact on y'all. ..I have one objection: on open source code, I can legally show the source code to anyone interested. And, to FAA people. For commercial products, that isn't a problem because the FAA oversight trickles through 'you' and interacts with NV directly. The oversight people get to see however much source code as they need ... but you might not. ..exactly why and how closed source becomes un-usable for EAA people. Remember, since this is costing NV time and money, they will expect you to cover their costs in this activity, and the associated paperwork hassles. ..agreed. And they would put it on the sales price tag, so I can buy it FAA-sertified. Which would be dumb of me as an EAA member, considering that I cannot do anything usable with it. As an EAA-member, I'd want to modify it to fit my newly designed plane. With open source, I can. Certification costs remains the same, but can be shared with the 1.1 mill. EAA membership, if I ask. And, I can try to get it certified as airworthy in the same fashion I can modify an auto engine for aero use and get it certified as airworthy, in the experimental or amateur-built classes. Legally. Code based on FlightGear running on Linux, That's certainly true; there are real advantages to being entirely open source when trying to get an STC or other airworthiness authorization. .. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bruce Perens Street Map of USA
On Thu, 21 Mar 2002 08:18:17 +1000, David Findlay [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 20 Mar 2002 22:31, you wrote: 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. Could we handle it with some form of arbitary level of detail? i.e. at a certain distance chance roads to lines, then make them disappear completely further away? I suppose similiar would need to be done to the terrain to drop the detail level there too. Thanks, ..in RL, this is also a function of _clean_ air; In the winter around the Lofoten/Vesteraalen archipelago on the Northern Norwegian coast, tourists often miss by orders of 10 to 40, on judging distances, as in 2 km for 50 km. ..typical conditions: Fresh high pressure regions in the first couple of days after a warm front has passed, washing out the air. Say -5°C, calm to light NW thru E winds, cavok, drying up as moisture is caught in the snow. Typically gone on the 3'rd to 5'th day, as smog can be seen over villages. ..believe those of you guys who has been to the Antarctic or Arctic, Alaska, Greenland, or possibly the western coast of Canada, may have seen this. And, for the record, a lot of you urban guys will tell me you have seen this too, and miss by a 2 digit order. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] inlining
Andy Ross wrote: FWIW, my interest in un-inlining stuff has nothing to do with runtime performance at all. What I want to see is for FlightGear to compile in something under 20 minutes on my machine. Some parts are really just terribly slow to build. JSBSim and UIUC are big culprits here, Personally I only ever fly the default fdm so compiling the others is a waste of my time and resources. Maybe we should add an argument to configure to select which FDM(s) to compile: --with-fdm=all the default, compiles all fdm modules --with-fdm=yasim compiles only the specified fdm Cheers, Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
Andy Ross writes: FWIW, my interest in un-inlining stuff has nothing to do with runtime performance at all. Understood but why didn't you just say this rather then talk about runtime performance ??? see below What I want to see is for FlightGear to compile in something under 20 minutes on my machine. Some parts are really just terribly slow to build. JSBSim and UIUC are big culprits here, but the WeatherCM stuff and the Main directory aren't far behind. WeatherCM can be bypassed with a configure switch I believe that JSBSim and UIUC and othe FDMs can be cut out of t he build by deleteing their entries from the FDM / Makefile.am and commenting out the appropriate lines in Main / fg_init.cxx :: void fgInitFDM() and removing their link lib directives from Main / Makefile.am You also have to #ifdef out UIUC aircraft_dir entries in fg_props.cxx main.cxx and fg_init.cxx This should speed up your YASim specific build time considerably FWIW Win2k 733 PIII 256 meg Cygwin without the above tricks #! /bin/sh # bootstrap.sh -- toplevel script for a fresh FlightGear Build make clean rm config.status rm config.cache CXXFLAGS=-O2 -W -Wall -march=i686 ./configure --with-network-olk=no --with-efence=no --with-logging=yes --with -jpeg-factory=yes make nhv@SFDEV3::/src/FlightGear% time ./bootstrap.sh .. real19m42.347s user17m30.419s sys 2m18.101s So it looks like 20 minutes is a reality on somewhat 'modest' machines And Cygwin is a slow poke :-) FWIW_2 with above tricks for optimized YASIM build times ./configure (as above plus) --with-new-enviroment nhv@SFDEV3::/src/FlightGear% time ./bootstrap.sh .. real11m39.212s user10m0.648s sys 1m40.002s Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] inlining
nhv@SFDEV3::/src/FlightGear% time ./bootstrap.sh .. real19m42.347s user17m30.419s sys 2m18.101s So it looks like 20 minutes is a reality on somewhat 'modest' machines And Cygwin is a slow poke :-) FWIW_2 with above tricks for optimized YASIM build times ./configure (as above plus) --with-new-enviroment nhv@SFDEV3::/src/FlightGear% time ./bootstrap.sh .. real11m39.212s user10m0.648s sys 1m40.002s I build JSBSim standalone in 1:45 (that's minutes:seconds for all you smarties out there). Norman: did you leave out both JSBSIm and LaRCSim in that build? Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Tony's JSBSim::FGTrim works nicely!
Tony,
I received your email to me a weaks ago.
I test it and read the source in the past 2 days.
Yes, It works very well!!! Now my plane can flying steadily with your trimming routine.
Thank you very much!
A good guy you are! :)
I belevie I almost understand how can you achieve the purpose of trimming now.
Yes thank you very much!
I have an idea that whether we can extend this iteration one-axis-at-a-time
arithmetic to more conditions which need accurate control, such as auto descent and
landing ?
Another Question:
the following is the code for starting the engine system.
Could you explain it to me?
//start the engine
int neng = Propulsion-GetNumEngines();
for(int i=0;ineng;i++) {
FGEngine* e = Propulsion-GetEngine(i);
e-SetRunning(false);
e-SetMagnetos(3);
FCS-SetThrottleCmd(i,0.25);
FCS-SetMixtureCmd(i,1.0);
e-SetStarter(true);
fdmex-RunIC(fgic);
}
cout Pre-start complete endl;
Propulsion-ICEngineStart();
for(int i=0;ineng;i++) {
Propulsion-GetEngine(i)-SetStarter(false);
}
cout Post-start complete endl;
//engine is running now
- Original Message -
From:Tony Peden [EMAIL PROTECTED]
To:[EMAIL PROTECTED]
Subject:Trimming with JSBSim
Date:Thu, 14 Mar 2002 07:06:03 +0800
Hello,
Find attached a version of JSBSim.cpp which performs a trim prior to
integrating. You'll probably want to back up you're current JSBSim.cpp.
Please copy the reset02.xml file to your JSBSim/aircraft/c172 directory.
If you are using a version of JSBSim that is less than
a couple weeks old, please update it as I found a bug in the trimming
routine and commited a fix to CVS last night.
Let me know if you have any questions or problems.
--
Tony Peden
[EMAIL PROTECTED]
We all know Linux is great ... it does infinite loops in 5 seconds.
-- attributed to Linus Torvalds
__
Óʼþµ½ÁËÂð?ÊÖ»ú¸æËßÄã(http://mail.263.net/mmail/index.html)
µã»÷ÏÂÔØ95963ÉÏÍøֱͨ³µ(http://www.263.net/0ji/StarDialer.exe)
ÎÒÄÃʲôÀ´ÓÕ»óÄã(http://95963.263.net/)
»¯×±Æ·ÈýÕÛ,ÏãË®°ë¼Û(http://shopping.263.net/class004.htm)
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
