[Flightgear-devel] startup position
Hi guys, I mentioned in an ealier post that I had changed the startup position in fg_init.cxx , line 913 and 790 : r._length * SG_FEET_TO_METER * 0.5 - 5.0, I've changed the - 5.0 offset to -30, and start in better positions with the 777, (model origin is a the wing root center) Considering the amount of large aircraft available now , should this be updated ? I see some commited from Melchior that suggest he might be working on a solution , just not sure what that is yet :) Syd - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
till busch wrote: > salut Benoît, > > your approach sounds reasonable to me. having all threads-related > functionality in OpenThreads is the way to go. imho there is no good reason > for maintaining another thread-wrapper in sg. > > a quick scan shows following classes in sg: > class SGThread > class SGMutex > class SGPthreadCond > > if they can all be safely replaced with corresponding OpenThread classes that > would be fine. > > i agree with curt's comments, but i'd say: please take the time to carefully > compare the code in sg and OpenThreads (like you did below). it is indeed > easy to introduce subtle bugs with threading code. I'm generally supportive of this kind of work too. Replacing home-grown code with packages that have a larger user base eases our own development and testing burden. In this specific case Benôit seems to have missed that SGThread is used in flightgear for the metar and voice threads, at least on Linux, so we can't just eliminate SGThread yet, but it does seem safe to eliminate SGMutex. Tim > > cheers, > > -till > > > p.s. probably your headline was bad. i think you want to "replace sg thread > classes with OpenThreads" (OpentThreads does use pthread on *nix) > > > > On Wednesday 30 April 2008, Benoît Laniel wrote: >>> Perhaps you could begin by explaining the problem you are going to solve, >>> and why your way is better. >> For windows version of fg, actually there are 2 solutions: >> - no threads >> - pthreads-win32 >> >> pthreads-win32 is, for me, a hack to ease the porting of *nix code to >> win32 and may not always be efficient. >> >> However, in fg you seem to use openthreads. Since osg is needed for both >> fg and sg, I thought you could use openthreads in sg too. >> >> So I started looking at the threads code in sg and noticed you use >> pthread for only one thing : SGGuard. >> >> >From what I understood, the code >> >> static SGMutex mutex; >> SGGuard locker(mutex); >> >> does this : >> >> - SGMutex constructor : calls pthread_mutex_init() >> - SGGuard constructor : calls SGMutex.lock() (which calls >> pthread_mutex_lock()) >> then >> - SGGuard destructor : calls SGMutex.unlock() (which calls >> pthread_mutex_unlock()) >> - SGMutex desctructor : calls pthread_mutex_destroy() >> >> Looking at openthreads code, changing SGMutex to OpenThreads::Mutex does >> this: >> >> - OpenThreads::Mutex constructor : calls pthread_mutex_init() >> - SGGuard constructor : now calls OpenThreads::Mutex.lock() (which calls >> pthread_mutex_lock()) >> - SGGuard destructor : now calls OpenThreads::Mutex.unlock() (which >> calls pthread_mutex_unlock()) >> - OpenThreads::Mutex destructor : calls pthread_mutex_destroy() >> >> However, when compiling for win32, you will have specific win32 threads >> managment calling EnterCriticalSection(), InterlockedExchange() etc >> which should be more efficient. >> >> So the effects are: >> - Do not worry about threads portability and always use optimized code >> from osg which seems a very active project. >> - Do not worry about threads-enabled/threads-disabled code, just check >> if openthreads is there. >> >> Regards >> Benoit > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Get rid of pthread
till busch wrote: > salut Benoît, > > your approach sounds reasonable to me. having all threads-related > functionality in OpenThreads is the way to go. imho there is no good reason > for maintaining another thread-wrapper in sg. > > a quick scan shows following classes in sg: > class SGThread > class SGMutex > class SGPthreadCond > > if they can all be safely replaced with corresponding OpenThread classes that > would be fine. > > i agree with curt's comments, but i'd say: please take the time to carefully > compare the code in sg and OpenThreads (like you did below). it is indeed > easy to introduce subtle bugs with threading code. I'm generally supportive of this kind of work too. Replacing home-grown code with packages that have a larger user base eases our own development and testing burden. In this specific case Benôit seems to have missed that SGThread is used in flightgear for the metar and voice threads, at least on Linux, so we can't just eliminate SGThread yet, but it does seem safe to eliminate SGMutex. Tim > > cheers, > > -till > > > p.s. probably your headline was bad. i think you want to "replace sg thread > classes with OpenThreads" (OpentThreads does use pthread on *nix) > > > > On Wednesday 30 April 2008, Benoît Laniel wrote: >>> Perhaps you could begin by explaining the problem you are going to solve, >>> and why your way is better. >> For windows version of fg, actually there are 2 solutions: >> - no threads >> - pthreads-win32 >> >> pthreads-win32 is, for me, a hack to ease the porting of *nix code to >> win32 and may not always be efficient. >> >> However, in fg you seem to use openthreads. Since osg is needed for both >> fg and sg, I thought you could use openthreads in sg too. >> >> So I started looking at the threads code in sg and noticed you use >> pthread for only one thing : SGGuard. >> >> >From what I understood, the code >> >> static SGMutex mutex; >> SGGuard locker(mutex); >> >> does this : >> >> - SGMutex constructor : calls pthread_mutex_init() >> - SGGuard constructor : calls SGMutex.lock() (which calls >> pthread_mutex_lock()) >> then >> - SGGuard destructor : calls SGMutex.unlock() (which calls >> pthread_mutex_unlock()) >> - SGMutex desctructor : calls pthread_mutex_destroy() >> >> Looking at openthreads code, changing SGMutex to OpenThreads::Mutex does >> this: >> >> - OpenThreads::Mutex constructor : calls pthread_mutex_init() >> - SGGuard constructor : now calls OpenThreads::Mutex.lock() (which calls >> pthread_mutex_lock()) >> - SGGuard destructor : now calls OpenThreads::Mutex.unlock() (which >> calls pthread_mutex_unlock()) >> - OpenThreads::Mutex destructor : calls pthread_mutex_destroy() >> >> However, when compiling for win32, you will have specific win32 threads >> managment calling EnterCriticalSection(), InterlockedExchange() etc >> which should be more efficient. >> >> So the effects are: >> - Do not worry about threads portability and always use optimized code >> from osg which seems a very active project. >> - Do not worry about threads-enabled/threads-disabled code, just check >> if openthreads is there. >> >> Regards >> Benoit > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft start up postion issue.
On Thu, May 1, 2008 at 7:03 AM, Markus Zojer wrote: > Just discovered that this can also be solved individually for every > aircraft. > > Inject within the tags of the -set.xml file: > > -0.024 > > > The unit for offset distance is nm and a negative number moves the > aircraft to the runway. > This can be applied individually for every aircraft, depending on their > datum placement. This value is also used to place the aircraft in the air, say on a 5 or 7 mile final, but command line options or menu options should override options specified in the aircraft file, so maybe this would work? But it makes me a little nervous to "abuse" a feature for something it wasn't necessarily intended to do. I can't think of anything that would get broken though ... ? Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Aircraft start up postion issue.
Just discovered that this can also be solved individually for every aircraft. Inject within the tags of the -set.xml file: -0.024 The unit for offset distance is nm and a negative number moves the aircraft to the runway. This can be applied individually for every aircraft, depending on their datum placement. Fly on, Markus Syd wrote: > While not the best solution , Ive set the set the start position to 30 > meters from end of runway instead of 5 , much better results ... > Syd > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Jon Stockill - please read this to protect your models database from copyright problems
Jon Stockill - please read this to protect your models database from copyright problems Our FG friend and very busy Gijs de Roy pointed out that someone was in the process to copy 3D-models from Google and give them away to the FlightGear community as self-created. Please read these posts to avoid taking these models into your database, what could cause some legal problems for FG: http://www.flightgear.org/forums/viewtopic.php?t=1419&highlight= Georg EDDW - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
