Re: [Flightgear-devel] recent environment changes break airport elevation with metar altimeter settings
After 18 minutes sitting on the runway with the altimeter setting matching the current METAR, the altimeter is still showing 100 ft too high. Questions: Q1: Since there has not been a METAR change, why is interpolation smoothing necessary at launch. Q2: The rate of interpolation seems excruciatingly slow. Can this be increased? I'm off for work right now and can't look into it. You should see the raw data in /environment/metar From there it gets interpolated over time into /environment/config/aloft[n] and /environment/config/boundary[n] This is done in $FGDATA/Environment/metarinterpolator.xml From here, the code in environment_ctrl.cxx interpolates over altitude/elevation into /environment/config/interpolated without any interpolation over time. The last step is done in $FGDATA/Environment/interpolator.xml, this interpolates over time into /environment A1: This is on my todo-list and needs some thinking about. A2: That's easy, the timing rates are in the mentioned xml-files. They definitely need some tuning and I am open for suggestions. Greetings, Torsten -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Newsletter mailing list
Hi all, to fullfill some requests, we now have a special newsletter mailinglist, thanks to Curt! Please register yourself at https://lists.sourceforge.net/lists/listinfo/flightgear-newsletter. Emails will be sent when a newsletter is released, and possibly also a week in advance of the release, in order to remind anyone that their help is welcome. Cheers, Gijs -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Newsletter mailing list
On 10/5/2010 9:54 AM, Gijs de Rooy wrote: Hi all, to fullfill some requests, we now have a special newsletter mailinglist, thanks to Curt! Please register yourself at https://lists.sourceforge.net/lists/listinfo/flightgear-newsletter. Emails will be sent when a newsletter is released, and possibly also a week in advance of the release, in order to remind anyone that their help is welcome. The advance notice would be good. I haven't helped edit lately because I just keep forgetting about it. It doesn't help that my employer's Barracuda web filter blocks the wiki (but not flightgear.com itself) as a gaming site. To get to it (while on break, of course!) at work, I must ssh/proxy through my home computer :( -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Performance and compiler options
On 10/2/2010 5:40 AM, thorsten.i.r...@jyu.fi wrote: To follow up on my previous message: Not so with my GIT binary: Loading of the initial cloud configuration brings me down to 4 fps, and every time (!) a cloud is loaded from the buffer my framerate drops from 34+ to something like 20+ for a moment - which makes the whole experience rather jerky. I have now made a series of tests to quantify the effect. The test situation is --disable-fullscreen --geometry=1200x900 --aircraft=ufo --airport=KINS --timeofday=noon --disable-real-weather-fetch 2.0.0 prebuilt: empty sky: 190 fps with 3d clouds: 128 fps with static cold sector tile: 90 fps when loaded, 34 while loading with dynamical cold sector tile: 45 fps when loaded, 30 while loading (note that this is *not* a fair comparison between standard 3d clouds and local weather clouds as the visibility and cloud view distance is rather different - not the point of the exercise) GIT built against my self-compiled OSG 2.9.10: empty sky: 234 fps with 3d clouds: 145 fps with static cold sector tile: 95 fps when loaded, 6 (!) while loading with dynamical cold sector tile: 46 fps when loaded,7 (!) while loading GIT build against the prebuilt OSG 2.9.6 coming with my 2.0.0 binary: empty sky: 230 fps with 3d clouds: 128 fps cold sector, static: 90 fps when loaded, 6 while loading cold sector dynamical: 48 fps when loaded, 8 while loading From this I conclude that what I'm seeing is not associated with OSG or the way I compile OSG. I also conclude that it's not related to performance issues of GIT in general - I get actually a better framerate than in 2.0.0 with GIT once things are loaded. But there is a dramatical difference in the impact on performance while new models are loaded (if you're flying, 30 fps vs. 6 fps is an issue...). That difference must be somewhere in the simgear or flightgear code. I can only stress that finding that difference and making GIT as fast as 2.0.0 in loading models will decide if local weather runs smoothly or not. At this point, the system itself is now fairly optimized and runs reasonably fast. Any help would be most welcome. Cheers, * Thorsten I've had some luck using the Intel compiler instead of gcc on processor heavy applications. It would be interesting to see what effect it may have on FG performance. http://software.intel.com/en-us/articles/non-commercial-software-download/ -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] C172p KAP140 textranslate issue
I wrote: I've started seeing strange animation behaviour on the C172p KAP140 autopilot. Specifically, the values displayed when in VS mode seem to be incorrect. Going into VS mode an pressing UP gives a VS readout of -9000 fpm. AFAICT the autopilot behaves correct, setting an appropriate target pressure delta, just the display is wrong. I've now fixed this. The problem was that condition less-than value0/value property/autopilot/KAP140/settings/target-pressure-rate/property /less-than /condition is no longer the same as condition less-than property/autopilot/KAP140/settings/target-pressure-rate/property value0/value /less-than /condition I suspect this is a relatively recent change (well, in the last year or so!), as I'm positive that this animation was working previously before. Worth looking out for if you find an old animation no-longer working as you would expect. -Stuart -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear Shared Object Libaries [PATCH]
Hi, Just last week I happened to have done a patch to simgear to build with shared libs, as well as updates to flightgear to build with them. Patch attached. They should work against latest simgear and flightgear git. I did not fix the circular dependencies with the libs. I simply made sure binaries are linked with all libs that are needed. Pigeon. commit 32331e65a025d8ed486ead1360c2b49522c70117 Author: Pigeon pig...@pigeond.net Date: Fri Oct 1 20:45:03 2010 +1000 Shared libs build diff --git a/configure.ac b/configure.ac index 4d16ac8..f2057cf 100644 --- a/configure.ac +++ b/configure.ac @@ -44,6 +44,7 @@ AC_PROG_CPP AC_PROG_CXX AC_PROG_CXXCPP AC_PROG_RANLIB +AC_PROG_LIBTOOL AC_PROG_INSTALL AC_PROG_LN_S AX_BOOST_BASE([1.37.0]) diff --git a/simgear/Makefile.am b/simgear/Makefile.am index 9bd77ef..6eb8f19 100644 --- a/simgear/Makefile.am +++ b/simgear/Makefile.am @@ -24,14 +24,14 @@ SUBDIRS_ALWAYS = \ structure \ bucket \ ephemeris \ + serial \ + props \ + math \ + timing \ io \ magvar \ - math \ nasal \ - props \ - route \ - serial \ - timing + route SUBDIRS = $(SUBDIRS_ALWAYS) \ $(compatibility_DIR) \ diff --git a/simgear/bucket/Makefile.am b/simgear/bucket/Makefile.am index d1f7b69..e8d3206 100644 --- a/simgear/bucket/Makefile.am +++ b/simgear/bucket/Makefile.am @@ -1,10 +1,10 @@ includedir = @includedir@/bucket -lib_LIBRARIES = libsgbucket.a +lib_LTLIBRARIES = libsgbucket.la include_HEADERS = newbucket.hxx -libsgbucket_a_SOURCES = newbucket.cxx +libsgbucket_la_SOURCES = newbucket.cxx # noinst_PROGRAMS = testbucket diff --git a/simgear/debug/Makefile.am b/simgear/debug/Makefile.am index cdfba79..ed2e56a 100644 --- a/simgear/debug/Makefile.am +++ b/simgear/debug/Makefile.am @@ -2,10 +2,10 @@ includedir = @includedir@/debug EXTRA_DIST = logtest.cxx -lib_LIBRARIES = libsgdebug.a +lib_LTLIBRARIES = libsgdebug.la include_HEADERS = debug_types.h logstream.hxx -libsgdebug_a_SOURCES = logstream.cxx +libsgdebug_la_SOURCES = logstream.cxx INCLUDES = -I$(top_srcdir) diff --git a/simgear/environment/Makefile.am b/simgear/environment/Makefile.am index f6042f8..2cdc20e 100644 --- a/simgear/environment/Makefile.am +++ b/simgear/environment/Makefile.am @@ -1,9 +1,9 @@ includedir = @includedir@/environment -lib_LIBRARIES = libsgenvironment.a +lib_LTLIBRARIES = libsgenvironment.la include_HEADERS = metar.hxx visual_enviro.hxx precipitation.hxx -libsgenvironment_a_SOURCES = metar.cxx visual_enviro.cxx precipitation.cxx +libsgenvironment_la_SOURCES = metar.cxx visual_enviro.cxx precipitation.cxx INCLUDES = -I$(top_srcdir) diff --git a/simgear/ephemeris/Makefile.am b/simgear/ephemeris/Makefile.am index c6ea748..f577d9d 100644 --- a/simgear/ephemeris/Makefile.am +++ b/simgear/ephemeris/Makefile.am @@ -1,6 +1,6 @@ includedir = @includedir@/ephemeris -lib_LIBRARIES = libsgephem.a +lib_LTLIBRARIES = libsgephem.la include_HEADERS = \ celestialBody.hxx \ @@ -16,7 +16,7 @@ include_HEADERS = \ uranus.hxx \ venus.hxx -libsgephem_a_SOURCES = \ +libsgephem_la_SOURCES = \ celestialBody.cxx \ ephemeris.cxx \ jupiter.cxx \ diff --git a/simgear/io/Makefile.am b/simgear/io/Makefile.am index ee2294c..2355d05 100644 --- a/simgear/io/Makefile.am +++ b/simgear/io/Makefile.am @@ -1,6 +1,6 @@ includedir = @includedir@/io -lib_LIBRARIES = libsgio.a +lib_LTLIBRARIES = libsgio.la include_HEADERS = \ iochannel.hxx \ @@ -12,7 +12,7 @@ include_HEADERS = \ sg_socket_udp.hxx \ raw_socket.hxx -libsgio_a_SOURCES = \ +libsgio_la_SOURCES = \ iochannel.cxx \ lowlevel.cxx \ sg_binobj.cxx \ @@ -29,11 +29,15 @@ noinst_PROGRAMS = decode_binobj socktest lowtest tcp_server tcp_client tcp_server_SOURCES = tcp_server.cxx tcp_server_LDADD = \ - libsgio.a \ - $(top_builddir)/simgear/structure/libsgstructure.a \ - $(top_builddir)/simgear/debug/libsgdebug.a \ - $(top_builddir)/simgear/bucket/libsgbucket.a \ - $(top_builddir)/simgear/misc/libsgmisc.a \ + libsgio.la \ + $(top_builddir)/simgear/serial/libsgserial.la \ + $(top_builddir)/simgear/misc/libsgmisc.la \ + $(top_builddir)/simgear/bucket/libsgbucket.la \ + $(top_builddir)/simgear/debug/libsgdebug.la \ + $(top_builddir)/simgear/structure/libsgstructure.la \ + $(top_builddir)/simgear/props/libsgprops.la \ + $(top_builddir)/simgear/math/libsgmath.la \ + $(top_builddir)/simgear/timing/libsgtiming.la \ -lz \ $(network_LIBS) \ $(base_LIBS) @@ -41,11 +45,15 @@ tcp_server_LDADD = \ tcp_client_SOURCES = tcp_client.cxx tcp_client_LDADD = \ - libsgio.a \ - $(top_builddir)/simgear/structure/libsgstructure.a \ - $(top_builddir)/simgear/debug/libsgdebug.a \ - $(top_builddir)/simgear/bucket/libsgbucket.a \ - $(top_builddir)/simgear/misc/libsgmisc.a \ + libsgio.la \ + $(top_builddir)/simgear/serial/libsgserial.la \ + $(top_builddir)/simgear/misc/libsgmisc.la \ + $(top_builddir)/simgear/bucket/libsgbucket.la \ + $(top_builddir)/simgear/debug/libsgdebug.la \ +
Re: [Flightgear-devel] C172p KAP140 textranslate issue
On 5 Oct 2010, at 21:55, Stuart Buchanan wrote: I've now fixed this. The problem was that condition less-than value0/value property/autopilot/KAP140/settings/target-pressure-rate/property /less-than /condition is no longer the same as condition less-than property/autopilot/KAP140/settings/target-pressure-rate/property value0/value /less-than /condition I suspect this is a relatively recent change (well, in the last year or so!), as I'm positive that this animation was working previously before. Worth looking out for if you find an old animation no-longer working as you would expect. This is my fault, I changed the SGCondition logic to be order dependant, instead of the previous 'property is always take as the LHS, even if appears on the RHS' behaviour. At the time I did some greps of data/Aircraft to see if anyone was using the 'reversed' syntax, and didn't find any, but your result indicates my grep-ing didn't work - not good. The reason for the change was less-than, and the other comparison conditionals, now also support expression as a child, and I didn't want to define an arbitrary ordering between value, property and expression. Frankly until I looked at the old code, I would never have believed your two examples were identical. Does anyone have the necessary fu with an XML-grep tool, to find all instances of less-than and greater-than in data/Aircraft, where a value tag is the first child? That should find all the likely problem cases. James -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] static array of std::string valid?
- Original message - Looks like initialization order problem. I guess the static strings themselves have not been constructed yet when the array tries to copy them. You could check that from a debugger. The compiler should have generated proper order, assuming there are no circular dependencies. For me, on linux, the initializers run in the expected order: Excellent - that's it. SGCloudLayer::SG_FOO_BAR_STRING is not yet initialized. Interestingly this is on MacOS only (gcc 4.2.1) while Linux (gcc.4.4.1) runs fine. I'll think about a workaround - Many thanks for the hint, it saved me some hours of debugging! Funny enough, I have had the exact same problem (initialization order) when I was cross compiling for arm, gcc 4.2.x as well, though the crash is elsewhere. Have you found a workaround yet? I also notice there is a gcc extension (attribute) to specify initialization priority/order, but I have't tried myself yet. Pigeon. -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
