Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
James Turner wrote: > The problem seems to be very bad in the case of the GPWS, because it's > actually a very complex instrument, and the author (who seems to > be ... absent?) clearly put in a lot of very accurate functionality, > but almost no documentation. Because it's so complex, I assume it > needs some accurate configuration to work with an aircraft - i.e the > 'out of the box' defaults are not correct - which is entirely > understandable. > > There also seems to be a lack of some reference installations in > aircraft, and the code hasn't had much love - I've been bumping up > against it doing my refactorings, but I think I'll take a step back, > and look over it properly, since it seems no one else has in some time. > > Also, don't get me wrong - I have no problem with people coding up > systems in Nasal, it's the right place for many, many such systems. > And indeed, probably the right place for a simple radar-altitude-based > GPWS with voice callouts. That's not what the Mk-VIII is - it's > modelling all the clever modes (look-ahead, terrain clearing, > approach, etc) and doing things like finding the nearest runway / > localiser to identify which runway the aircraft is inbound too. It's a > good case of a real-world instrument which makes sense to be in C++ > (until machines get quite a bit quicker), but it needs some love, and > some docs. > > So, I don't have a problem with a Nasal GPWS, but I'd far, far rather > have some collaboration and help to get the Mk-VIII into a state where > aircraft modellers can use it comfortably and correctly. > > >> In the meantime , IRC is a much >> freindlier , helpful place. >> > > But not a useable one for some of us - following the forums and here > is enough work for me. > > Regards, > James > > > Hi James , Im no expert coder , but I did take a look at it myself , and the lack of comments made that a no go for me. I tried to visit some of the sites he listed as reference material , but either they don't exist anymore or I just can't get to them .Judging by the code , it does seem to be a complex and accurate instrument , and if someone can figure it out , great. My nasal 'experiment' is meant to appease those who want it working , (and to see if I can do it ), but it wont be anywhere near as complex as the MK-VIII. I did try to contact Jean long ago , to see if there were setting that needed to be changed for individual aircraft (when I added it to the Bravo),but no luck there . I will continue to poke around with it , I think it should have more obvious user settings and thanks for looking into it . Cheers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
On 23 Sep 2008, at 20:26, Syd wrote: > So I gather your telling me I can't change my aircraft ? The gpws > issues > have been known for a long time , and I,m sure you well know that . > I wont post bugs here because of exactly this My past questions > were largely ignored , my minor patches were generally called crap , > and > the only way to get a real discussion going seems to be introducing a > mistake or a typo THEN watch the discussions fly ! The problem seems to be very bad in the case of the GPWS, because it's actually a very complex instrument, and the author (who seems to be ... absent?) clearly put in a lot of very accurate functionality, but almost no documentation. Because it's so complex, I assume it needs some accurate configuration to work with an aircraft - i.e the 'out of the box' defaults are not correct - which is entirely understandable. There also seems to be a lack of some reference installations in aircraft, and the code hasn't had much love - I've been bumping up against it doing my refactorings, but I think I'll take a step back, and look over it properly, since it seems no one else has in some time. Also, don't get me wrong - I have no problem with people coding up systems in Nasal, it's the right place for many, many such systems. And indeed, probably the right place for a simple radar-altitude-based GPWS with voice callouts. That's not what the Mk-VIII is - it's modelling all the clever modes (look-ahead, terrain clearing, approach, etc) and doing things like finding the nearest runway / localiser to identify which runway the aircraft is inbound too. It's a good case of a real-world instrument which makes sense to be in C++ (until machines get quite a bit quicker), but it needs some love, and some docs. So, I don't have a problem with a Nasal GPWS, but I'd far, far rather have some collaboration and help to get the Mk-VIII into a state where aircraft modellers can use it comfortably and correctly. > In the meantime , IRC is a much > freindlier , helpful place. But not a useable one for some of us - following the forums and here is enough work for me. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
On Mon, Sep 22, 2008 at 5:23 PM, James Turner wrote: > > On 22 Sep 2008, at 23:05, Vivian Meazza wrote: > > > A binary search, which I'm also trying, takes days. At some point we > > left > > OSG 2.4, used an interim version, then migrated to osg 2.6. An osg > > rebuild > > here takes well over an hour. So far, I've come about halfway > > forward from > > Apr, which is the last-known-good I have. The total rebuild takes > > about > > 3hrs. I can manage to find time for about 1 a day in all. > > Well, being selfish, one around the start of August would rule my > changes in or out - but if you're slogging through the binary search, > I'll leave you to it. > > > I have no evidence that it's anything that you have done, although > > AJ might > > take a different view. Still have hash.c in my sights. > > Well, hash.c might be to 'hot spot' but probably not the cause - AFAIK > is hasn't been touched in a good long time. Here's another idea to toss into the mix ... What aircraft is being flown in these tests? If hash.c looks like a hotspot, that could also be triggered by an aircraft that had a lot of new nasal code added. Or it could be newly added default system nasal code? I don't know how much of FlightGear functions anymore without nasal, but disabling the default nasal directory and picking an aircraft with little or no embedded nasal code might also be an interesting test. We could possibly have crossed a threshold in terms of the amount of nasal code used for some particular aircraft? Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
On 22 Sep 2008, at 23:05, Vivian Meazza wrote: > A binary search, which I'm also trying, takes days. At some point we > left > OSG 2.4, used an interim version, then migrated to osg 2.6. An osg > rebuild > here takes well over an hour. So far, I've come about halfway > forward from > Apr, which is the last-known-good I have. The total rebuild takes > about > 3hrs. I can manage to find time for about 1 a day in all. Well, being selfish, one around the start of August would rule my changes in or out - but if you're slogging through the binary search, I'll leave you to it. > I have no evidence that it's anything that you have done, although > AJ might > take a different view. Still have hash.c in my sights. Well, hash.c might be to 'hot spot' but probably not the cause - AFAIK is hasn't been touched in a good long time. James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
James > > > On 22 Sep 2008, at 22:25, Vivian Meazza wrote: > > > AJ and I _think_ we are talking about the same problem. We might not > > be, > > although the description of the symptoms, which we have discussed many > > times, seems to be the same. The underlying cause might not be the > > same. It > > might be the code, the compiler, the OS. We don't know, which is why > > we need > > some more evidence. It might be different causes for AJ and for me. > > What we > > do know is that we had a much better solution a while back. > > Since this might be my fault, I'll say that as far as I know (of > course I could be very, very wrong), none of my changes should have a > noticeable performance impact (yet). For example, the marker-beacon > instrument searches for nearby navaids of a certain type, and in the > future I might change how the search is implemented, but right now all > the old search methods are being used. > > Of course I could easily have made a mistake. The best solution is a > binary search of CVS - rewind to a date which is 'known good' and the > keep stepping forwards / back by half the time interval and checking- > out / rebuilding / testing. Generally it will only take 4-8 iterations > of this (tedious) process to narrow it down to a day, at which point > we can see how I screwed up :) > > It would also be good to know if everyone sees this issue (or some > variation), or only certain OS-es / people with slower machines / etc > A binary search, which I'm also trying, takes days. At some point we left OSG 2.4, used an interim version, then migrated to osg 2.6. An osg rebuild here takes well over an hour. So far, I've come about halfway forward from Apr, which is the last-known-good I have. The total rebuild takes about 3hrs. I can manage to find time for about 1 a day in all. I have no evidence that it's anything that you have done, although AJ might take a different view. Still have hash.c in my sights. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
On lundi 22 septembre 2008, Vivian Meazza wrote: > gerard > > > On lundi 22 septembre 2008, Vivian Meazza wrote: > > > Hi Fred, > > > > > > Fred wrote: > > > > Hi Vivian, > > > > > > > > Vivian Meazza wrote : > > > > > As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems > > > > to > > > > > > > be a _very_ significant CPU hog, but I can't link it to the > > > > staggers. I > > > > > > > note however that when I profile an old FG/osg from last Apr, it is > > > > > > > > stagger > > > > > > > > > free, and hash.c doesn't figure in the profiling. > > > > > > > > > > I can also say that staggering is visible in Fred's latest Win32 > > > > > binary. > > > > > > > > > > Really above my pay grade here. Can anyone else help? Negative > > > > > information is also useful. > > > > > > > > Could you tell me how you profiled FG under Windows ? > > > > > > > > Thank you > > > > -Fred > > > > > > I use LTProf here: > > > > > > http://www.lw-tech.com/ > > > > > > Small charge, but it seems to give some useful/meaningful results > > > > > > Vivian > > > > Are we sure that we are talking about the same topic and the same problem > > , > > as far i understand, > > => on one side, the cause is coming from compilation under an MS windows > > OS, > > => on the other side, there is problem within FG itself like described > > by AJ > > and Curt. > > AJ and I _think_ we are talking about the same problem. We might not be, > although the description of the symptoms, which we have discussed many > times, seems to be the same. The underlying cause might not be the same. It > might be the code, the compiler, the OS. We don't know, which is why we > need some more evidence. It might be different causes for AJ and for me. > What we do know is that we had a much better solution a while back. > > Vivian > > So, i can try to explain why i don't notice any significant stutter with my configuration 32 bits one. May be, the power of the CPU AMD 3200 Athlon and GPU 7800 GS Nvidia Agp (running with Fedora Core 8) are enough for it and could explain that i don't have the problem. I only have lost FPS versus the performance of FG 1.0 for instance FG OSG => 70 fps FG 1.0.0 (with cloud and shadow) 80 fps Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
On 22 Sep 2008, at 22:25, Vivian Meazza wrote: > AJ and I _think_ we are talking about the same problem. We might not > be, > although the description of the symptoms, which we have discussed many > times, seems to be the same. The underlying cause might not be the > same. It > might be the code, the compiler, the OS. We don't know, which is why > we need > some more evidence. It might be different causes for AJ and for me. > What we > do know is that we had a much better solution a while back. Since this might be my fault, I'll say that as far as I know (of course I could be very, very wrong), none of my changes should have a noticeable performance impact (yet). For example, the marker-beacon instrument searches for nearby navaids of a certain type, and in the future I might change how the search is implemented, but right now all the old search methods are being used. Of course I could easily have made a mistake. The best solution is a binary search of CVS - rewind to a date which is 'known good' and the keep stepping forwards / back by half the time interval and checking- out / rebuilding / testing. Generally it will only take 4-8 iterations of this (tedious) process to narrow it down to a day, at which point we can see how I screwed up :) It would also be good to know if everyone sees this issue (or some variation), or only certain OS-es / people with slower machines / etc Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
gerard > > On lundi 22 septembre 2008, Vivian Meazza wrote: > > Hi Fred, > > > > Fred wrote: > > > Hi Vivian, > > > > > > Vivian Meazza wrote : > > > > As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems > to > > > > be a _very_ significant CPU hog, but I can't link it to the > staggers. I > > > > note however that when I profile an old FG/osg from last Apr, it is > > > > > > stagger > > > > > > > free, and hash.c doesn't figure in the profiling. > > > > > > > > I can also say that staggering is visible in Fred's latest Win32 > > > > binary. > > > > > > > > Really above my pay grade here. Can anyone else help? Negative > > > > information is also useful. > > > > > > Could you tell me how you profiled FG under Windows ? > > > > > > Thank you > > > -Fred > > > > I use LTProf here: > > > > http://www.lw-tech.com/ > > > > Small charge, but it seems to give some useful/meaningful results > > > > Vivian > > > > > Are we sure that we are talking about the same topic and the same problem > , > as far i understand, > => on one side, the cause is coming from compilation under an MS windows > OS, > => on the other side, there is problem within FG itself like described by > AJ > and Curt. > AJ and I _think_ we are talking about the same problem. We might not be, although the description of the symptoms, which we have discussed many times, seems to be the same. The underlying cause might not be the same. It might be the code, the compiler, the OS. We don't know, which is why we need some more evidence. It might be different causes for AJ and for me. What we do know is that we had a much better solution a while back. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
Hi Erik > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits > system > > Vivian Meazza wrote: > > As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to > be a > > _very_ significant CPU hog, but I can't link it to the staggers. I note > > however that when I profile an old FG/osg from last Apr, it is stagger > free, > > and hash.c doesn't figure in the profiling. > > > One hint, try running with: --disable-ai-models > Er ... couple of words spring to mind there - grandmother and eggs :-). But I know that you are trying to help. I'm profiling with absolutely _everything_ disabled (including replay). _If_ that had shown that the stagger went away I would have reintroduced features one by one. But I can't even get that far atm. Still trying though, and still trying to identify the cause. I note, however, that not long ago we had a very good solution, so it's something we have done, and relatively recently. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
On lundi 22 septembre 2008, Vivian Meazza wrote: > Hi Fred, > > Fred wrote: > > Hi Vivian, > > > > Vivian Meazza wrote : > > > As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to > > > be a _very_ significant CPU hog, but I can't link it to the staggers. I > > > note however that when I profile an old FG/osg from last Apr, it is > > > > stagger > > > > > free, and hash.c doesn't figure in the profiling. > > > > > > I can also say that staggering is visible in Fred's latest Win32 > > > binary. > > > > > > Really above my pay grade here. Can anyone else help? Negative > > > information is also useful. > > > > Could you tell me how you profiled FG under Windows ? > > > > Thank you > > -Fred > > I use LTProf here: > > http://www.lw-tech.com/ > > Small charge, but it seems to give some useful/meaningful results > > Vivian > > Are we sure that we are talking about the same topic and the same problem , as far i understand, => on one side, the cause is coming from compilation under an MS windows OS, => on the other side, there is problem within FG itself like described by AJ and Curt. -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] mingw fixes
Hi!
Here are some fixes for the mingw platform that I had to make for a
successful build.
Note, in 2 places I have changed a #include to a #include
, but that should be ok. For safety, somebody using msvc
build please check.
As a result, a current mingw build (includes osg) can be downloaded
from here: http://www.sendspace.com/file/unio5y
--
Csaba/Jester
Index: src/GUI/gui_funcs.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/GUI/gui_funcs.cxx,v
retrieving revision 1.67
diff -u -r1.67 gui_funcs.cxx
--- src/GUI/gui_funcs.cxx 27 Jul 2008 15:18:35 - 1.67
+++ src/GUI/gui_funcs.cxx 18 Sep 2008 23:24:48 -
@@ -54,7 +54,9 @@
# include
# include
#endif
-
+#ifdef __MINGW32__
+#include
+#endif
#include "gui.h"
using std::string;
Index: src/Input/fgjs.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/fgjs.cxx,v
retrieving revision 1.16
diff -u -r1.16 fgjs.cxx
--- src/Input/fgjs.cxx 31 Jul 2008 12:04:33 - 1.16
+++ src/Input/fgjs.cxx 22 Sep 2008 19:54:03 -
@@ -28,7 +28,7 @@
#include
-#ifdef _MSC_VER
+#ifdef WIN32
#include
#endif
Index: src/Main/bootstrap.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/bootstrap.cxx,v
retrieving revision 1.34
diff -u -r1.34 bootstrap.cxx
--- src/Main/bootstrap.cxx 27 Jul 2008 16:25:15 - 1.34
+++ src/Main/bootstrap.cxx 22 Sep 2008 19:19:11 -
@@ -141,7 +141,7 @@
// Ignore floating-point exceptions on FreeBSD
signal(SIGFPE, SIG_IGN);
#endif
-#ifndef _MSC_VER
+#ifndef WIN32
signal(SIGPIPE, SIG_IGN);
#endif
Index: src/Main/fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v
retrieving revision 1.218
diff -u -r1.218 fg_init.cxx
--- src/Main/fg_init.cxx 13 Sep 2008 08:06:15 - 1.218
+++ src/Main/fg_init.cxx 22 Sep 2008 19:21:13 -
@@ -581,7 +581,7 @@
}
SGPropertyNode autosave;
-#ifdef _MSC_VER
+#ifdef WIN32
char *envp = ::getenv( "APPDATA" );
if (envp != NULL ) {
SGPath config( envp );
Index: src/Network/native_ctrls.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Network/native_ctrls.cxx,v
retrieving revision 1.34
diff -u -r1.34 native_ctrls.cxx
--- src/Network/native_ctrls.cxx 21 Jan 2008 19:11:32 - 1.34
+++ src/Network/native_ctrls.cxx 22 Sep 2008 20:14:50 -
@@ -37,7 +37,7 @@
// FreeBSD works better with this included last ... (?)
#if defined(WIN32) && !defined(__CYGWIN__)
-# include
+# include
#else
# include // htonl() ntohl()
#endif
Index: src/Network/native_fdm.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Network/native_fdm.cxx,v
retrieving revision 1.32
diff -u -r1.32 native_fdm.cxx
--- src/Network/native_fdm.cxx 7 Nov 2007 17:41:31 - 1.32
+++ src/Network/native_fdm.cxx 22 Sep 2008 20:14:38 -
@@ -40,7 +40,7 @@
// FreeBSD works better with this included last ... (?)
#if defined(WIN32) && !defined(__CYGWIN__)
-# include
+# include
#else
# include // htonl() ntohl()
#endif
Index: utils/GPSsmooth/UGear_main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/utils/GPSsmooth/UGear_main.cxx,v
retrieving revision 1.22
diff -u -r1.22 UGear_main.cxx
--- utils/GPSsmooth/UGear_main.cxx 29 Jul 2008 08:27:48 - 1.22
+++ utils/GPSsmooth/UGear_main.cxx 22 Sep 2008 20:16:42 -
@@ -2,7 +2,7 @@
# include
#endif
-#ifndef _MSC_VER
+#ifndef WIN32
# include // for bzero()
#else
# define bzero(a,b) memset(a,0,b)
Index: simgear/scene/sky/cloud.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/sky/cloud.cxx,v
retrieving revision 1.56
diff -u -r1.56 cloud.cxx
--- simgear/scene/sky/cloud.cxx 21 Dec 2007 06:25:13 - 1.56
+++ simgear/scene/sky/cloud.cxx 22 Sep 2008 20:01:34 -
@@ -55,9 +55,9 @@
#include "cloud.hxx"
using namespace simgear;
-// #if defined(__MINGW32__)
-// #define isnan(x) _isnan(x)
-// #endif
+#if defined(__MINGW32__)
+#define isnan(x) _isnan(x)
+#endif
// #if defined (__FreeBSD__)
// # if __FreeBSD_version < 50
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-deve
Re: [Flightgear-devel] [Flightgear-cvslogs]
Syd, Syd wrote: > `Did you already communicate the issue about the MK-VIII to other > > evelopers in order to get it fixed ? [..] > Well, this sounds like a case for a knowledgeable person to explain > instead of silently working around it instead of silently working around > it > So I gather your telling me I can't change my aircraft ? The gpws issues > have been known for a long time , and I,m sure you well know that . > I wont post bugs here because of exactly this My past questions > were largely ignored , my minor patches were generally called crap , and > the only way to get a real discussion going seems to be introducing a > mistake or a typo THEN watch the discussions fly ! > This used to be a friendly helpful place , but has deteriorated > drastically over the years . No, I didn't know that this GPWS has had issues for a long time. I've never used such a beast, neither in real life nor in simulation. So I was simply unable to tell wether it works or not. Instead _you_ apparently know how to operate this system and also which response to expect. Therefore I consider you to be the person that is predestined to list the misfeatures in detail Otherwise nobody will be able to fix it. Nevertheless, sure, you have CVS write permissons, so you're free to change your aircraft however you like. See, I play the violin in a symphony orchestra (unpaind, just as a hobby, being one among a large crowd). In theory, I'm permitted to produce whatever 'sound' I like as long as I don't hurt anyone's civil rights. Still, I try to play in sync with the crowd as best as I can, because the only way to 'succeed' as a whole is by having each of us making the best 'arrangement' with all the others I know this list had some day started to become a somewhat 'hostile' place. Some person called me being responsible for this state but apparently almost nothing had changed during my one-year absence. I _do_ understand that people have tried to avoid this place, but I also sense some harmony creeping back in during the past weeks. So, please, give it yet another try. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
Syd wrote: > In the meantime , IRC is a much freindlier , helpful place. Unfortunately IRC (like the forum) is not the place where problems are solved, only the developers mailinglist is. This is because not everyone can follow all he places where discussions are taking place. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
`Did you already communicate the issue about the MK-VIII to other > evelopers in order to get it fixed ? > > Martin. > A long long time ago I tried to contact Jean for pointers no response... Well, this sounds like a case for a knowledgeable person to explain instead of silently working around it instead of silently working around it So I gather your telling me I can't change my aircraft ? The gpws issues have been known for a long time , and I,m sure you well know that . I wont post bugs here because of exactly this My past questions were largely ignored , my minor patches were generally called crap , and the only way to get a real discussion going seems to be introducing a mistake or a typo THEN watch the discussions fly ! This used to be a friendly helpful place , but has deteriorated drastically over the years . There's always someone who wont pipe in until they spot that eagerly awaited mistake. I know I'm not the only one frustrated by the that goes on here, so hopefully we can try to resort to courtesy and respect again . In the meantime , IRC is a much freindlier , helpful place. Cheers - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
Vivian Meazza wrote: > As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a > _very_ significant CPU hog, but I can't link it to the staggers. I note > however that when I profile an old FG/osg from last Apr, it is stagger free, > and hash.c doesn't figure in the profiling. > One hint, try running with: --disable-ai-models Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
Hi Fred, Fred wrote: > Hi Vivian, > > Vivian Meazza wrote : > > As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to > > be a _very_ significant CPU hog, but I can't link it to the staggers. I > > note however that when I profile an old FG/osg from last Apr, it is > stagger > > free, and hash.c doesn't figure in the profiling. > > > > I can also say that staggering is visible in Fred's latest Win32 > > binary. > > > > Really above my pay grade here. Can anyone else help? Negative > > information is also useful. > > Could you tell me how you profiled FG under Windows ? > > Thank you > -Fred > I use LTProf here: http://www.lw-tech.com/ Small charge, but it seems to give some useful/meaningful results Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
Hi Vivian, Vivian Meazza wrote : > As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to > be a _very_ significant CPU hog, but I can't link it to the staggers. I > note however that when I profile an old FG/osg from last Apr, it is stagger > free, and hash.c doesn't figure in the profiling. > > I can also say that staggering is visible in Fred's latest Win32 > binary. > > Really above my pay grade here. Can anyone else help? Negative > information is also useful. Could you tell me how you profiled FG under Windows ? Thank you -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery - album photo http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Clouds - Update on (lack of) progress
On Mon, Sep 22, 2008 at 7:46 PM, Martin Spott <[EMAIL PROTECTED]> wrote: > "Vadym Kukhtin" wrote: >> 2008/9/21 Stuart Buchanan <[EMAIL PROTECTED]> >> >> > Tried apply the patch, but got >> >> patch: malformed patch at line 50: Index: Environment/fgclouds.cxx > > I didn't try it myself, but in general I'd say: If you require external > help to get the patch applied cleanly, then this is definitely not for > you. Did you read Stuart's elaborate comment ? Patch is broken in multiple places (missing line breaks, parts of lines) -- Csaba/Jester - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
AJ wrote > > On Monday 22 September 2008 12:16:13 gerard robin wrote: > > > Again on that topic, i was wrong about 64 bit , which has nothing to do > > with the stutter/jitter within FG. > > That's true (since we've seen the same stuttering on 32 bit machines as > well). > > However, even though in your case disabling fancy effects appears to cure > your > system it seems there is something in FG causing a distinct stutter, > happening around once per second, irrespective of framerate. > > On my own machine (Core2duo 1.86 GHz, 2Gb RAM, 7300GS graphics card) the > stutter is basically undetectable under most circumstances, but very > noticeable with the Brest photo scenery and slightly less so when using a > highly-detailed model over another highly-populated scenery area. > > It seems to me to have been a fairly recent thing, which seemed to show up > here around the same time as James' patches were committed (though I'm not > certain enough to blame them, and haven't had time to revert back and > build > again.) It also doesn't appear to be caused by nasal and occurs whether > or > not AI traffic or the traffic-manager, or multiplayer are enabled. > > Nobody else seeing the same thing? > As you know, I am. I have profiled the cvs-head. Nasal/hash.c seems to be a _very_ significant CPU hog, but I can't link it to the staggers. I note however that when I profile an old FG/osg from last Apr, it is stagger free, and hash.c doesn't figure in the profiling. I can also say that staggering is visible in Fred's latest Win32 binary. Really above my pay grade here. Can anyone else help? Negative information is also useful. Vivian - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS:
Heiko Schulz wrote: > But the real problem is, that nobody really knows how the stuff is > really working and how to activate them. Well, this sounds like a case for a knowledgeable person to explain instead of silently working around it Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Clouds - Update on (lack of) progress
"Vadym Kukhtin" wrote: > 2008/9/21 Stuart Buchanan <[EMAIL PROTECTED]> > > > Tried apply the patch, but got > > patch: malformed patch at line 50: Index: Environment/fgclouds.cxx I didn't try it myself, but in general I'd say: If you require external help to get the patch applied cleanly, then this is definitely not for you. Did you read Stuart's elaborate comment ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D Clouds - Update on (lack of) progress
2008/9/21 Stuart Buchanan <[EMAIL PROTECTED]> > Tried apply the patch, but got patch: malformed patch at line 50: Index: Environment/fgclouds.cxx And, can you make some screenshots, please? -- --- WBR, Vadym. - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
Heiko Schulz wrote: > The last errors I had were: > > -Bank-Angle-Callouts with real zero-angle after lift off or shortly above rwy > while landing. > - the callouts "50" "40" "30" "20" "10" could be never heard at all- even > with a very low sink rate > > "Low-Terrain"-warning on a corrct ILS-glidepath > Hello, I just want to confirm this. Especially the "bank angle" right after takeoff is a common issue. I encounter it in the Citation Bravo. Did not take care on the callouts, but the "low terrain" warning although perfectly on a 3° glidepath are happening here, too. If i'm not mistaken as well on the Bravo. Cheers, Chris - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
O.k. > > Yep, it's entirely possible that I messed up aspects of > the GPWS, but > I need a better test case than 'acting weird'. Most > of all, I need to > know an aircraft where it definitely worked correctly in > the past, > because it's never worked 'well' for me in any > version of FG. I'm not > sure if this is due to the aircraft I fly, location, or > some other > factor. > > Regards, > James > There was no aircraft in the past, that really worked like it should. Well, maybe the b1900d and later the 777 and the 787 was the one, which was origin for some other aircraft and were the "best"- working ones. Have a look into 1.0.0. Note that 1900d and 777 are by Syd. But the real problem is, that nobody really knows how the stuff is really working and how to activate them. The last errors I had were: -Bank-Angle-Callouts with real zero-angle after lift off or shortly above rwy while landing. - the callouts "50" "40" "30" "20" "10" could be never heard at all- even with a very low sink rate "Low-Terrain"-warning on a corrct ILS-glidepath Regards HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS:
> Well, participating in a 'club' like this one and > not giving reasonable > feedback doesn't count as good habits Maybe- But I think Syd will have a lot reasons for that. Nasal scripting is a lot of easier than C++ - so it is a nice workaround. And very often better than hardcoded. Example: 747-200 Auto-Landing. Nasal scripted. Works perfect and very much like the original. > BTW, a quick search on The Net revealed this thread - I > suspect you > already knew about it: > > > http://www.flightgear.org/forums/viewtopic.php?f=4&t=1574 > > At least as far as I understand, these people were able to > get a > working MK-VIII, > > Martin. It depends on what you define "working" - yes, it worked, but there was still a lot of wrong call-outs like the "Bank-angel"-Callout with zero banking after lift-off and so on And a lot of callouts we have, were never used- I think because nobody knows how to activate them. But right- maybe that should have been a topic here on the list. Maybe HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
On lundi 22 septembre 2008, Curtis Olson wrote: > > I am hearing a pretty distinct glitch in the audio about once per second > ... it's not so much of a hard break, but disruption in continuity. I'm > not sure if this is related to a pause in FlightGear, or the openal drivers > on Fedora 9, or what? The once per second audio glitch seems to be more > distinct on lower performance CPU's. (Referring to our cvs development > version of course.) > > Regards, > > Curt. Yes, "disruption in continuity" i hear it too , with my usual 32 bit system (fc8) ., and with the other 64 bit system (fc9). -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS:
Heiko Schulz wrote: > And the MKVIII was never ever working right, I can understand Syd doing a > workaround. Well, participating in a 'club' like this one and not giving reasonable feedback doesn't count as good habits BTW, a quick search on The Net revealed this thread - I suspect you already knew about it: http://www.flightgear.org/forums/viewtopic.php?f=4&t=1574 At least as far as I understand, these people were able to get a working MK-VIII, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] menu/dialog properties
On Mon, Sep 22, 2008 at 8:05 AM, Geoff wrote: > On Thu, 2008-09-18 at 16:45 -0400, Geoff wrote: > > Hello all - > > > > I have added a menu item to the Environment which brings up a dialog > > with some data fields for the user to fill in. > > > > My question is: what do I do when the field doesn't exist? > > How do I create a new one and where can I find out what ones are > > available. (The README.properties is sadly lacking). > > > > Having googled for answers for days and not gotten much pertinent > information, let me restate my problem and question. > > I add to the FG menu a selection for "Underway" which is my "addon". > When this menu item is selected a dialog pops up. One of the items in > the dialog is, for instance, an input field where the user needs to > enter an IP address. I would like to a) put a default value in the > input field and b) obviously be able to read the value when the user > ok's the dialog. The IP address would be *my* variable and not a > FlightGear variable. > > Is this possible? Is there an example of how to do this? I am 99.9% sure that if you make up a new variable name in the property system and reference it from your dialog, it will be automatically created. The property system is designed so a referenced property name will be automatically created if it doesn't exist yet. You just have to be aware that the variable isn't necessarily created when FlightGear first starts up, it is created when it is first referenced (which might be when the dialog box is opened.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] menu/dialog properties
On Thu, 2008-09-18 at 16:45 -0400, Geoff wrote: > Hello all - > > I have added a menu item to the Environment which brings up a dialog > with some data fields for the user to fill in. > > My question is: what do I do when the field doesn't exist? > How do I create a new one and where can I find out what ones are > available. (The README.properties is sadly lacking). > Having googled for answers for days and not gotten much pertinent information, let me restate my problem and question. I add to the FG menu a selection for "Underway" which is my "addon". When this menu item is selected a dialog pops up. One of the items in the dialog is, for instance, an input field where the user needs to enter an IP address. I would like to a) put a default value in the input field and b) obviously be able to read the value when the user ok's the dialog. The IP address would be *my* variable and not a FlightGear variable. Is this possible? Is there an example of how to do this? -- Geoff McLean McLean Research Associates "To be good is not enough when you dream of being great." - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
On Mon, Sep 22, 2008 at 7:54 AM, AJ MacLeod wrote: > On Monday 22 September 2008 12:16:13 gerard robin wrote: > > > Again on that topic, i was wrong about 64 bit , which has nothing to do > > with the stutter/jitter within FG. > > That's true (since we've seen the same stuttering on 32 bit machines as > well). > > However, even though in your case disabling fancy effects appears to cure > your > system it seems there is something in FG causing a distinct stutter, > happening around once per second, irrespective of framerate. > > On my own machine (Core2duo 1.86 GHz, 2Gb RAM, 7300GS graphics card) the > stutter is basically undetectable under most circumstances, but very > noticeable with the Brest photo scenery and slightly less so when using a > highly-detailed model over another highly-populated scenery area. > > It seems to me to have been a fairly recent thing, which seemed to show up > here around the same time as James' patches were committed (though I'm not > certain enough to blame them, and haven't had time to revert back and build > again.) It also doesn't appear to be caused by nasal and occurs whether or > not AI traffic or the traffic-manager, or multiplayer are enabled. > > Nobody else seeing the same thing? > I am hearing a pretty distinct glitch in the audio about once per second ... it's not so much of a hard break, but disruption in continuity. I'm not sure if this is related to a pause in FlightGear, or the openal drivers on Fedora 9, or what? The once per second audio glitch seems to be more distinct on lower performance CPU's. (Referring to our cvs development version of course.) Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
On Monday 22 September 2008 12:16:13 gerard robin wrote: > Again on that topic, i was wrong about 64 bit , which has nothing to do > with the stutter/jitter within FG. That's true (since we've seen the same stuttering on 32 bit machines as well). However, even though in your case disabling fancy effects appears to cure your system it seems there is something in FG causing a distinct stutter, happening around once per second, irrespective of framerate. On my own machine (Core2duo 1.86 GHz, 2Gb RAM, 7300GS graphics card) the stutter is basically undetectable under most circumstances, but very noticeable with the Brest photo scenery and slightly less so when using a highly-detailed model over another highly-populated scenery area. It seems to me to have been a fairly recent thing, which seemed to show up here around the same time as James' patches were committed (though I'm not certain enough to blame them, and haven't had time to revert back and build again.) It also doesn't appear to be caused by nasal and occurs whether or not AI traffic or the traffic-manager, or multiplayer are enabled. Nobody else seeing the same thing? - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
Heiko Schulz wrote: > So much as I know James Turner is working on that. > And the MKVIII was never ever working right, I can understand Syd doing a > workaround. > Last time I heard he was awaiting feedback. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
> Martin Spott wrote: > > Syd, > > > >> Converting to OSG , a lot of small updates stll to > do... > >> Added a simple nasal gpws since the mk-viii > appears to misbehave... > >> > > > > Did you already communicate the issue about the > MK-VIII to other > > developers in order to get it fixed ? > > > Yes, please report any problems that (seems to) have been > introduced > recently, there was a lot of needed overhauling and just > leaving it > buggy is a bad idea. > > Erik > So much as I know James Turner is working on that. And the MKVIII was never ever working right, I can understand Syd doing a workaround. Regards HHS __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear on 32 bits versus 64 bits system
On mercredi 17 septembre 2008, gerard robin wrote: > Hello, > > Running without any problem with FG on a 32 bits computer (which my usual > computer) > recently, I have had to build FlightGear on a 64 bit computer with FC9. > Both computers have the same GPU (Nvidia 7800 GS AGP 8). > I was disappointed with the result FG works with a huge Jitter, like we had > in the past, which is now , to me, solved (32 bits environment). > > Does anybody has got a similar problem ? > Where do i must look for to solve the problem ? did i forgot some > parameters with ./configure and/or make ? > > Cheers > > NB:Openscenegraphe had been automatically built 64 bits ( lib64 library). Again on that topic, i was wrong about 64 bit , which has nothing to do with the stutter/jitter within FG. The explanation is: the computer (a dual core AMD 64 x2 6400) which is involved has the Linux operating system FC9, which, unfortunately, include the last KDE desktop 4.1. That desktop "eat" some GL resources due to the desktop effects, and probably conflicts with any other applications which want GL, Tested, Celestia.. and FlightGear, the result is a huge stutter . Fortunately it is possible to deactivate the desktop-effect. And everything is coming back right and smooth. Cheers BTW I don't know if that problem is FC9 only, or if it happen to any Linux operating which include KDE 4.1. -- Gérard http://pagesperso-orange.fr/GRTux/ "J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire " - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
On 22 Sep 2008, at 08:20, Erik Hofman wrote: >> Did you already communicate the issue about the MK-VIII to other >> developers in order to get it fixed ? >> > Yes, please report any problems that (seems to) have been introduced > recently, there was a lot of needed overhauling and just leaving it > buggy is a bad idea. Yep, it's entirely possible that I messed up aspects of the GPWS, but I need a better test case than 'acting weird'. Most of all, I need to know an aircraft where it definitely worked correctly in the past, because it's never worked 'well' for me in any version of FG. I'm not sure if this is due to the aircraft I fly, location, or some other factor. Regards, James - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/b1900d b1900d-set.xml, 1.32,
Martin Spott wrote: > Syd, > >> Converting to OSG , a lot of small updates stll to do... >> Added a simple nasal gpws since the mk-viii appears to misbehave... >> > > Did you already communicate the issue about the MK-VIII to other > developers in order to get it fixed ? > Yes, please report any problems that (seems to) have been introduced recently, there was a lot of needed overhauling and just leaving it buggy is a bad idea. Erik - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
