Re: [Flightgear-devel] Mac #ifdef clean-ups
Hi Tat, - "Tatsuhiro Nishioka" <[EMAIL PROTECTED]> a écrit : > Anyway, could someone apply his (and my) patches and commit to cvs? > RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v > retrieving revision 1.201 > diff -u -r1.201 fg_init.cxx 1.201 is a bit old. Current revision is 1.213 and includes these lines. > --- src/Main/fg_init.cxx13 Jun 2008 10:52:47 - 1.201 > +++ src/Main/fg_init.cxx29 Jul 2008 18:59:47 - > @@ -42,6 +42,10 @@ > # define getcwd _getcwd > #endif > > +#if defined(__APPLE__) > +# include > +#endif > + > // work around a stdc++ lib bug in some versions of linux, but > doesn't > // seem to hurt to have this here for all versions of Linux. > #ifdef linux -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] Mac #ifdef clean-ups
On 29 Jul 2008, at 20:41, Tatsuhiro Nishioka wrote: > I applied your patches and it seems working properly so far on my > environment (cvs/osg as of several days back). However, I needed the > following additional patch for avoiding compilation errors. > > Anyway, could someone apply his (and my) patches and commit to cvs? > > Cheers, > > Tat > > - > > RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v > retrieving revision 1.201 > diff -u -r1.201 fg_init.cxx > --- src/Main/fg_init.cxx13 Jun 2008 10:52:47 - 1.201 > +++ src/Main/fg_init.cxx29 Jul 2008 18:59:47 - > @@ -42,6 +42,10 @@ > # define getcwd _getcwd > #endif > > +#if defined(__APPLE__) > +# include > +#endif > + > // work around a stdc++ lib bug in some versions of linux, but doesn't > // seem to hurt to have this here for all versions of Linux. > #ifdef linux Weird, I know about that change - I thought it was in the diffs I sent to Erik. Hmmm. 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] Window controls
On Tue, Jul 29, 2008 at 11:23 AM, cullam Bruce-Lockhart wrote: > Hi there. I'm fairly new to this, so this is probably a very rudimentary > question. I apologize. I'm hooking up a lumenera Camera for a live video > feed from a UAV, so that the video gets handed to Flightgear, which then > draws its HUD over the video stream. In order to do this, I need to be able > to communicate with the window controls. My camera can display the video in > a new window, but I want it to draw to the video screen that Flightgear is > already using. The camera expects a handle to the window. Any idea where I > can find this, and all other information where the program keeps track of > its window (size, position, etc)? Thanks so much! > > I think the problem here is that only one application can "own" the window. It's very likely that any demo code you'll see for your camera opens up a window and owns and manages it, takes care of handling events, etc. etc. The problem is that FlightGear wants to own the window too. When I've pondered this sort of thing, I didn't imagine trying to embed FlightGear into some other application. Instead, I imagined embedding some minimal routine that talks to the camera and grabs an image frame. Then usually you can directly map this into an opengl texture if you figure out the pixel format of your frame grab and pass the right flags to the opengl texture create call. Then you should be able to draw this texture on top of any surface just like any other texture ... you could map it to a rectangular area of the screen, you could map it to a rotating cube, map it to the earth surface, etc. That's about as far as far as I've gone with thinking through the problem. 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] Mac #ifdef clean-ups
Hi James, Thanks for your clean-ups. I was about to eliminate obsolete APIs so this is a really great help. I applied your patches and it seems working properly so far on my environment (cvs/osg as of several days back). However, I needed the following additional patch for avoiding compilation errors. Anyway, could someone apply his (and my) patches and commit to cvs? Cheers, Tat - RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_init.cxx,v retrieving revision 1.201 diff -u -r1.201 fg_init.cxx --- src/Main/fg_init.cxx13 Jun 2008 10:52:47 - 1.201 +++ src/Main/fg_init.cxx29 Jul 2008 18:59:47 - @@ -42,6 +42,10 @@ # define getcwd _getcwd #endif +#if defined(__APPLE__) +# include +#endif + // work around a stdc++ lib bug in some versions of linux, but doesn't // seem to hurt to have this here for all versions of Linux. #ifdef linux On Jul 25, 2008, at 1:00 AM, James Turner wrote: > Some Mac / __APPLE___ cleanups for someone to (hopefully) commit: > > - remove the OSX_BUNDLE crap *I* introduced years ago - we're always a > a bundle on Mac now. > > - fix up the default fg-root on Mac to be > FlightGear.app/Contents/Resources/data - i.e the location used by the > macflightgear.org distro, and indeed the obvious 'correct' location. Not sure > why I didn't use that in the first place, back in the day. > > - remove the CPSForegroundEnable hack. For one thing, we're a bundle > and don't need it, and for another, osgViewer on Mac does the same logic > using a newer, public API rather than a hack into the OS. > > - remove the strange logic for doing fgOSInit 'early' (in bootstrap > rather than main) when running from the command line on Mac; again this is > obsolete, and no one seems to know why it was ever necessary. I guess it was > an interaction with SDL when running without a bundle. > > - (not Mac related) remove obsolete code bracketed by > ENABLE_PLIB_JOYSTICK and USE_GLIDE (neither of which are ever set, even from > config.h that I can see) in main.cxx > > There's also a Simgear diff that removes the workaround for the C++ / > stdlibary bug which existed aeons ago on Mac. > > > > 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 - 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] about the carrier used in scenario
hi all we did a scenario that use the carrier type to make an arresting cable with a flols working, at LFRJ airport (Landivisiau, France), but if we check the "turn to wind button" the cable and the flols are moving, considered like a normal carrier. Is there a way to make it fix relative to the ground, or the only way is to never use turn to wind? i join the scenario file (LFRJ_wires_demo.xml) Concerning the flols, last two red lights (the lowests) taking part of the wave off are not in the right place, compared to the flols model, as you can see here: http://wiki.flightgear.org/images/thumb/9/9d/Carrier5.jpg/800px-Carrier5.jpg here's a patch to synch them, that seems to be an inversion between y and z axis,here's the result: http://fr.flightgear.tuxfamily.org/lib/exe/fetch.php?cache=cache&w=900&h=670&media=school:move:porte-avion:flols:waveoff-nimitz.jpg have a nice landing on Nimitz jano Arrestor Cables for training of landing in a aircraft carrier. park-1 is a parking position for Heavy Military Aicraft park-2 is a parking position for Military Jet carrier LFRJ-bak26-1 AI/Airports/LFRJ/BAK26+flols.xml 098Y line 48.53306323 -4.137254038 335.4462275 253.32 25 -30 1.8 --> 0 0 0 0 carrier LFRJ-bak08-1 AI/Airports/LFRJ/BAK08+flols.xml 098Y line 48.52714689 -4.166412234 334.8964534 73.32 25 -30 1.5 park-1 10 365 610 -2 park-2 190 252 600 0 0 0 0 0 Index: Models/Geometry/Nimitz/Models/flols.xml === RCS file: /var/cvs/FlightGear-0.9/data/Models/Geometry/Nimitz/Models/flols.xml,v retrieving revision 1.6 diff -u -r1.6 flols.xml --- Models/Geometry/Nimitz/Models/flols.xml 21 Apr 2008 08:23:20 - 1.6 +++ Models/Geometry/Nimitz/Models/flols.xml 29 Jul 2008 18:33:25 - @@ -289,8 +289,8 @@ Models/Geometry/Nimitz/Models/wave-off.xml 0.1 - 0.77 - -1.18 + 1.18 + -0.77 @@ -298,8 +298,8 @@ Models/Geometry/Nimitz/Models/wave-off.xml 0.1 - -0.77 - -1.18 + -1.18 + -0.77 - 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] Window controls
Hi there. I'm fairly new to this, so this is probably a very rudimentary question. I apologize. I'm hooking up a lumenera Camera for a live video feed from a UAV, so that the video gets handed to Flightgear, which then draws its HUD over the video stream. In order to do this, I need to be able to communicate with the window controls. My camera can display the video in a new window, but I want it to draw to the video screen that Flightgear is already using. The camera expects a handle to the window. Any idea where I can find this, and all other information where the program keeps track of its window (size, position, etc)? Thanks so much! -cullam - 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] bad aircraft.livery.init() use
May I remind developers that the optional arguments to aircraft.livery.init() are *optional*? It seems to be common practice to use the "name-path" and "sort-path" arguments, which is generally a bad idea: it means that you have to *manually* sort the entries, which isn't only more work, but also makes user additions harder! (What if two contributers want to offer a livery? Then they have to agree on different indices!) Don't use the sort index argument if you want to sort by names *anyway*! And don't use the name-path argument if you are using the default property path for that, anyway (that is: "/sim/model/livery/name"). m. - 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
