Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Am Montag 20 Dezember 2004 22:20 schrieb Jorge Van Hemelryck:
...
1- the Control app launches and communicates with FlightGear, the latter
being for instance a child process (or fgrun could be extended to
communicate with FlightGear in this way)
2- FlightGear is launched at the same time as the Control app
3- FlightGear and the Control app can be run independently
I'd go with option three. I see the FG core (the simulator itself) as an
independent demon. Multiple 'control' clients can connect and interact
with the FG server ('GUI', Atlas Moving Map, Flight Tutor*, Flight
logger, ...). We might need a locking mechanism to have only 1 client writing
properties though.
* some future app that gives remarks on flight performance, i.e. Give
attention to engine rpm, More left rudder (just an idea :-))
...
What is already clear is that FlightGear should not depend on this
Control app. It must be possible to run FlightGear from the command-line
without anything else. That is why I would be in favor of option 3.
+1
Here is what is already possible with what we presently have. The
FlightGear telnet protocol allows an external program to get and set
properties. This already allows for environment / position / time /
radio / gps / view settings, to name a few.
The current gui (menubar) can do more than that, and in the future it
would probably a good thing to use the same API, in order for instance
to be able to launch a nasal command from the Control app.
That's a definite goal, to have a clean API to the simulator core, which is
used by an internal as well as an external GUI.
As we said before, the main problem would be to change aircraft (and
therefore reinit FDM, 3D model, systems) without restarting FG. I'll try
and have a look at the initialization code as soon as I find some time.
Great.
Thomas
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Compiling with Visual Studio 2003.net
Thanks Antoine, This could be the README I never manage to write. On remark : the pthreads-snap-something can be the latest ( advised ). It is just that it requires a name change in the project files. -Fred Quoting RENNUIT Antoine : There cannot exist a howto to compile these sources, because it depends on the cvs sources, and cvs files are always changing. Anyway, I did compile the whole project under msvc.net 2003 (both under win XP, and win 2k), 2 weeks ago, and I can testify that it works well, here are a few guidelines : - download glut for windows from http://www.xmission.com/~nate/glut.html, and unzip it - copy glut.h to %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\GL - copy glut32.dll to %WINDOWS_DIRECTORY\System32 - download the openAL sdk for windows at http://developer.creative.com/landing.asp?cat=1sbcat=31top=38, and install it. - create a directory AL in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\, copy the files you find in %OPENAL_DIRECTORY%\Include into this new directory, then you should find 8 files (al.h, alc.h, alctypes.h, altypes.h, alu.h, alut.h, aluttypes.h, and alutypes.h) in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\AL - copy the dll files you find in %OPENAL_DIRECTORY%\dll in %WINDOWS_DIRECTORY\System32 (there are 2 files : OpenAL32.dll, and wrap_oal.dll) - download the file FG-ProjectFiles-msvc71.zip at ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/MSVC/ (careful, this file only works under msvc.net 2003, not 2002), unzip it - download the version of pThread for windows indicated in the FG-ProjectFiles-msvc71 newly created directory (should be pthreads-snap-2004-06-22, so you must not download the latest version but an older one) at http://sources.redhat.com/pthreads-win32/, unzip it. In explorer, drag the newly created directory pthreads-snap-2004-06-22, and drop it on the directory FG-ProjectFiles-msvc71\pthreads-snap-2004-06-22 (pressing Ctrl key at the same time to copy the files, its safer than just to move them). - copy pthreadVCd.dll (that you can now find in FG-ProjectFiles-msvc71\pthreads-snap-2004-06-22), in %WINDOWS_DIRECTORY\System32 - download the cvs version (tarballs are ok) of flightgear, plib, and simgear at (http://www.flightgear.org/Downloads/source.html, http://plib.sourceforge.net/download.html, and http://www.simgear.org/downloads.html), unzip them (you can use 7-zip, http://www.7-zip.org/, to unzip .tgz, or .tar.gz files). - drag, and drop (copying them, it's safer...) these 3 newly created directories onto there respective counterpart in FG-ProjectFiles-msvc71\FlightGear\cvs - unzip zlib-1.1.4.tar.gz that you find in FG-ProjectFiles-msvc71\FlightGear\cvs\SimGear\src-libs, and drag and drop this new zlib-1.1.4 directory to FG-ProjectFiles-msvc71\FlightGear\zlib-1.1.4 Now we have to modify the project, and the code itself, because several things changed since FG-ProjectFiles-msvc71.zip was made : - open the solution named FlightGear-2.sln in FG-ProjectFiles-msvc71\FlightGear\cvs\FlightGear - find the files dme.cxx, dme.hxx, navcom.cxx, navcom.hxx, radiostack.cxx, radiostack.hxx in project FlightGear, directory Lib_Cockpit in solutions explorer UNDER MSVC, and delete them from the project : they do not exist anymore in the latest cvs versions of FlightGear find flightgear.ico, and flightgear.rc in project FlightGear, in solutions explorer UNDER MSVC, and delete them from the project - find the files jpgfactory.cxx, and jpgfactory.hxx in project SimGear, directory Lib_sgscreen in solutions explorer UNDER MSVC, and delete them from the project - add the file ssgAnimTransform.cxx to project ssg in solutions explorer UNDER MSVC - delete the projects magik_demo, tux_examples, fgadmin, and fgrun from the solution - open glut.h that you find in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\GL, find _CRTIMP void __cdecl exit(int);, and replace it with #if _MSC_VER = 1200 _CRTIMP __declspec(noreturn) void __cdecl exit(int); #else _CRTIMP void __cdecl exit(int); #endif Hope it helps... Antoine. PS : mail me back if you think something is strange... -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] la part de Andy messier Envoyé : lundi 20 décembre 2004 20:01 À : Flightgear-devel@flightgear.org Objet : [Flightgear-devel] Compiling with Visual Studio 2003.net Hey All, Are there step-by-step instructions on how to build the FlightGear source using Visual Studio? I've been fighting with this build all weekend, and am getting nowhere. I finally got all of the libraries and headers in the right places, and now it returns thousands of invalid external
[Flightgear-devel] torque computing
Hi people, i'm really new to this list and to FlightGear world. I've just had a look to the code for the LaRCsim model and to the YASim model. The second one does compute the torque applied to the yoke (calcForces), but not the first one. I've seen the list of the public variables from LaRCsim but i have no idea how i could compute the same torque. If anybody has an idea, i'm ready to consider it ;-) Any help is welcome. Thanks David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Reasonable vertex count for ground static?
On Tuesday 21 Dec 2004 07:34, Innis Cunningham wrote: The vertex count is down from near 1800 to 1200 and the number of 512x512 textures is halved. The static 747 and 737 at KSFO are 1100 and 400 vertices respectivley.So that may give you an idea how complex you think the 172 should be. Dave Martin Cheers Innis I'm going to have to scratch around and see what I can loose off it then :-) I tried loading 15 of them into Flightgear and getting them all in frame; I recieved about a 1/3 drop in framerate so the chances are that older cards would throw their toys out of the pram. Cheers for the info :) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Czech speaking users
Hi, Are there any Czech speaking users or developers who want to help me translate an aerospace related article? If so, could you please contact me? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Reasonable vertex count for ground static?
On Tuesday 21 Dec 2004 07:34, Innis Cunningham wrote: The static 747 and 737 at KSFO are 1100 and 400 vertices respectivley.So that may give you an idea how complex you think the 172 should be. Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I've now got 702 vertices and still a reasonable looking model that you can taxi past 20 feet away or fly over at 100 feet and think yes, thats a 172 ;-) Very close inspection gives the game away but your unlikely to find an aircraft that can taxi up to it without catching the prop. :-P One thing I've noticed is that lightplanes are definitely more complex in shape than commercial jets. The model now uses just one texture (which needs to be change to represent a different a/c to Fox Sierra.) Screenshot: http://www.cyfinity.com/fgfs/c172p-static.jpg I'm hoping to 'do over' the pa28 also so I can place some static aircraft at Midland airstrips - I hope to start on Wellesbourne Mountford (EGBW) but I need to get the taxi-ways / disused runways sorted with Taxidraw first. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Reasonable vertex count for ground static?
Dave Martin wrote: I've now got 702 vertices and still a reasonable looking model that you can taxi past 20 feet away or fly over at 100 feet and think yes, thats a 172 ;-) Very close inspection gives the game away but your unlikely to find an aircraft that can taxi up to it without catching the prop. :-P One thing I've noticed is that lightplanes are definitely more complex in shape than commercial jets. The model now uses just one texture (which needs to be change to represent a different a/c to Fox Sierra.) Screenshot: http://www.cyfinity.com/fgfs/c172p-static.jpg I'm hoping to 'do over' the pa28 also so I can place some static aircraft at Midland airstrips - I hope to start on Wellesbourne Mountford (EGBW) but I need to get the taxi-ways / disused runways sorted with Taxidraw first. Dave, Are you familiar with Level of Detail or LOD? This is a technique where you can build multiple versions of your aircraft with different level of details. The system then automatically picks which version to display depending on how far away it is. This let's you do a super high res version, one or two medium res versions, and a super low resolution version (which might just be a single dot.) It's more work to set this up, but if you carefully balance your polygon counts with your transition ranges, you can get a result such that you can display hundreds of models on the screen pretty easily. In most cases, 99% of the aircraft will be drawn in the ultra-low res LOD, and only the few closest will be drawn in the highest LOD. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Reasonable vertex count for ground static?
On Tuesday 21 Dec 2004 19:28, Curtis L. Olson wrote: Dave, Are you familiar with Level of Detail or LOD? This is a technique where you can build multiple versions of your aircraft with different level of details. The system then automatically picks which version to display depending on how far away it is. This let's you do a super high res version, one or two medium res versions, and a super low resolution version (which might just be a single dot.) It's more work to set this up, but if you carefully balance your polygon counts with your transition ranges, you can get a result such that you can display hundreds of models on the screen pretty easily. In most cases, 99% of the aircraft will be drawn in the ultra-low res LOD, and only the few closest will be drawn in the highest LOD. Regards, Curt. Now thats interesting stuff; I *had* noticed that FG has lod settings and such but I don't know much about how it works in FG (Although I fully understand the principal). I'll have a go at making another version of the 172 with say, 2d wings, solid windows and less polys in the fusealage. How many levels of LOD (no. of models) do you think would be worthwhile? (I suppose you can first sight individual a/c at 6 miles out.) Cheers. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Hey Guys, First, I want to thank you guys for all of your help. You've been very patient with me, since I'm really clueless as to how to get this working for the first time...I just want to make sure I get this compiled right to begin with (and with a stable release), so I avoid compounding existing problems with my own changes, and have trouble tracking down their cause. Anyway, I *think* I'm getting closer. Here are the errors I'm getting now. error C2381: 'exit' : redefinition; __decllspec(noreturn) differs fatal error C1083: Cannot open include file: 'jpeglib.h': No such file or directory That first error is in stdlib.h, which seems a bit bothersome. The second error is in jpgfactory.hxx, and is and #include jpeglib.h. Is there a standard C++ library I'm missing? Thanks again, Drew On Tue, 21 Dec 2004 08:18:24 +0100, Frederic Bouvier [EMAIL PROTECTED] wrote: Drew wrote : I'm getting the following errors (most of them several times) Cannot open include files: FL/Fl.h FL/Fl_File_Chooser.h FLTK 1.1.x, only needed to build fgadmin. Remove the project from the solution if you don't want to build it GL/glut.h GLUT, mandatory plib/ssg.h sg.h PLIB, mandatory Cannot open source files: .\majik_demo.cxx PLIB demo, optional .\simgear\scene\sky\clouds3d\camdisplay.cpp .\src\AIModel\AICarrier.cxx .\src\AIModel\submodel.cxx .\src\Cockpit\hud_rwy.cxx .\src\Fdm\groundcache.cxx .\src\fdm\sp\ACMS.cxx .\src\fdm\sp\ADA.cxx .\src\Instrumentation\encoder.cxx .\src\Instrumentation\kr_87.cxx .\src\Instrumentation\kt_70.cxx .\src\Instrumentation\marker_beacon.cxx .\src\Instrumentation\navradio.cxx .\src\Instrumentation\transponder.cxx .\src\Network\ATC-Inputs.cxx New, CVS only, ( or wait 0.9.8 ), files - remove them from the solution if you really want to compile 0.9.6 .\ssgLoadASC.cxx .\ssgSaveIV.cxx CVS plib files. same as above .\tux_example.cxx Plib demo, optional There are a bunch of warnings as well, but I won't worry about them yet. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Reasonable vertex count for ground static?
Dave, you can check out the animation file (specifically: engine animation) for the MD11 if you want to learn how to set different LOD's. Curt, as I was working on the MD11, I get a feeling that FlightGear is loading every single polygon into the scene graph. Is my feeling correct? If so, does that mean not implementing LOD's may actually consume less resources? Ampere On December 21, 2004 02:42 pm, Dave Martin wrote: Now thats interesting stuff; I *had* noticed that FG has lod settings and such but I don't know much about how it works in FG (Although I fully understand the principal). I'll have a go at making another version of the 172 with say, 2d wings, solid windows and less polys in the fusealage. How many levels of LOD (no. of models) do you think would be worthwhile? (I suppose you can first sight individual a/c at 6 miles out.) Cheers. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Monday, 20 December 2004 21:04, Curtis L. Olson wrote: That certainly sounds doable, although the particular details of how to launch, and kill, and detect if the child process is running will probably vary wildly from platform to platform. If one uses a socket connection it becomes very simple. One could find the running process quite easily by just entering the correct IP and port numbers into the client. (Obviously with a default setting like 127.0.0.1: for all the new XP users who just want to try FG out so that it works out of the box.) This way it can be run on a single machine or across a network. FG can be started and shutdown either independently or by the client app. No mutex's, no OS API calls, no semaphores, no checking for lock files ... The only trick is some people may have local firewall software on their PeeCees which may interfere with network connections. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Tuesday, 21 December 2004 12:10, Thomas Förster wrote:
I'd go with option three. I see the FG core (the simulator itself) as an
independent demon. Multiple 'control' clients can connect and interact
with the FG server ('GUI', Atlas Moving Map, Flight Tutor*, Flight
logger, ...). We might need a locking mechanism to have only 1 client
writing properties though.
It would be really nice to have all those features in a single controlling
client app with a single connection. One tab for aircraft selection, another
tab for a flight planner, one for instructor console, etc.
Having one app means you only need one connection without the risk of any
contention.
Of course getting several people to work on the same app with the same vision
can be tricky. :)
That's a definite goal, to have a clean API to the simulator core, which is
used by an internal as well as an external GUI.
I would love to see all the FG core stuff going that route - one network
capable API that everything can work through including FG itself.
As far as I can see FG looks like it's already half way there.
Paul
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
On Monday, 20 December 2004 22:34, Martin Spott wrote: Well, David Luff has proven that cross-platform-portability is not a miracle, his TaxiDraw compiles at least on Windows and five different Unices just with some small Makefile changes allthough he didn't tell us how much effort he had to spend in order to achieve this portability ;-) It's really easy when using a good, cross platform toolkit like wxWidgets. I've used wxWidgets for some cross platform network apps and so far I'm very, very impressed! I've tried other toolkits and as far as I'm concerned there's no other toolkit at the moment that is as feature filled and cross platform friendly as wxWidgets. 12 years of work has gone into wxWidgets (formerly wxWindows) and it really shows. The best thing about wxWidgets is it uses the native GUI controls of each OS so it looks totally native and you can't tell what platform the app it was written on. Paul ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] My 172P work for appraisal
On Monday 20 December 2004 17:04, Dave Martin wrote: On Monday 20 Dec 2004 09:58, Martin Spott wrote: Dave Martin wrote: Here we are: (screenshots) Well, after looking at the first shot: http://www.cyfinity.com/fgfs/c172p1.jpg I thought: Oh, how nice, someone added a C150 to the hangar, but after looking at the last one: http://www.cyfinity.com/fgfs/c172p7.jpg I am pretty much pleased ;-) Thanks, Martin. As it happens I'd quite like to make a 150/152 model from scratch as a fairly high-poly example which would be 'comfortably' realistic. However, I'm watching the development of the PA28-161 for now so I can get some tips on setting up 3d panels etc. I have a very good 3-view for a C-185, if anyone wants to do one of those. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 20, Issue 45
Paul Surgeon wrote: I would love to see all the FG core stuff going that route - one network capable API that everything can work through including FG itself. As far as I can see FG looks like it's already half way there. I have been working on extending the property code to add an SGRemoteProperty class to access properties on a remote host instead of locally. Most of the tree is cached locally, but queering the value of the end-node is done through a socket connection. I have this sort of working (but need more debugging). Unfortunately I got detracted by political issues (which went great BTW. It looks like my local airport is saved) and didn't do much programming ever since. Next to the SGRemotePropertyNode I've also been considering queering multiple properties in one shot, instead of one by one. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
Drew wrote : Hey Guys, First, I want to thank you guys for all of your help. You've been very patient with me, since I'm really clueless as to how to get this working for the first time...I just want to make sure I get this compiled right to begin with (and with a stable release), so I avoid compounding existing problems with my own changes, and have trouble tracking down their cause. Anyway, I *think* I'm getting closer. Here are the errors I'm getting now. error C2381: 'exit' : redefinition; __decllspec(noreturn) differs fatal error C1083: Cannot open include file: 'jpeglib.h': No such file or directory That first error is in stdlib.h, which seems a bit bothersome. The second error is in jpgfactory.hxx, and is and #include jpeglib.h. Is there a standard C++ library I'm missing? This one is listed in Antoine's message, and you should find it in the archive : - open glut.h that you find in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\GL, find _CRTIMP void __cdecl exit(int);, and replace it with #if _MSC_VER = 1200 _CRTIMP __declspec(noreturn) void __cdecl exit(int); #else _CRTIMP void __cdecl exit(int); #endif -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Reasonable vertex count for ground static?
Ampere K. Hardraade wrote: Dave, you can check out the animation file (specifically: engine animation) for the MD11 if you want to learn how to set different LOD's. Curt, as I was working on the MD11, I get a feeling that FlightGear is loading every single polygon into the scene graph. Is my feeling correct? If so, does that mean not implementing LOD's may actually consume less resources? Right, all versions of your models will be loaded so the system can pick which to display at any particular instance. OSG has a neat feature that will demand load your LOD levels, but we aren't quite to that point yet. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Reasonable vertex count for ground static?
Dave Martin wrote: Now thats interesting stuff; I *had* noticed that FG has lod settings and such but I don't know much about how it works in FG (Although I fully understand the principal). I'll have a go at making another version of the 172 with say, 2d wings, solid windows and less polys in the fusealage. How many levels of LOD (no. of models) do you think would be worthwhile? (I suppose you can first sight individual a/c at 6 miles out.) I would think that a super detailed version would be nice, some sort of middle range version, and some super tiny version that might be a dot or just a couple polygons. From there you could tune or add if you thought you needed to. At some point it would be nice to support Fade-LOD (I think OSG does that) but plib certainly can't. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Reasonable vertex count for ground static?
On Tuesday 21 Dec 2004 20:17, Curtis L. Olson wrote: I would think that a super detailed version would be nice, some sort of middle range version, and some super tiny version that might be a dot or just a couple polygons. From there you could tune or add if you thought you needed to. At some point it would be nice to support Fade-LOD (I think OSG does that) but plib certainly can't. Regards, Curt. If I regard the earlier 702 vertex model as the 'super-high', this one has about 300 vertices: http://www.cyfinity.com/fgfs/c172p-static-lod.jpg and is viewed from about 100 feet. (Could be used up to 2 miles or so.) I'll make another that is just four or five polys and no textures and then try that one as a scenery placement viewed from 2miles. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS - Problem compiling under Cygwin
This morning I updated FGFS cvs and tried to compile under Cygwin - it failed with configure: creating ./config.status config.status: creating \ .infig.status: error: cannot find input file: \ This evening I downloaded the whole file system to a new directory - same result. There are no other obvious faults: plib and SimGear are the correct versions. Any ideas? Or is cvs broken? Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New project at SF.net, macflightgear. Flightgear Mac OS X
In response to comments in the recent Mac OS X thread, I have registered a new project at Sourceforge.net: http://sourceforge.net/projects/macflightgear/ http://macflightgear.sf.net I have done nothing with it yet (It just got accepted). I am now calling for anyone here who wants to join. Here are the goals for this project: 1) Make FlightGear user friendly on Mac OS X. 2) Either port fgrun to Mac OS X or write a native application to include with our package. Email me at artooro AT users DOT sourceforge DOT net if you would like to join. Tell me what you would like to do and give your Sourceforge.net username. As soon as I have time I'll get the ball rolling. (And please don't throw flames at me for needlessly starting a project just for this.) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
That fixed the __dcllspec problem, but it's still not seeing jpeglib.h. And I tried commenting out this include line, and it couldn't find error.h, either...both of which are supposed to be standard C includes. Am I still missing a set of libraries? Thanks again, Drew On Tue, 21 Dec 2004 21:12:20 +0100, Frederic Bouvier [EMAIL PROTECTED] wrote: Drew wrote : Hey Guys, First, I want to thank you guys for all of your help. You've been very patient with me, since I'm really clueless as to how to get this working for the first time...I just want to make sure I get this compiled right to begin with (and with a stable release), so I avoid compounding existing problems with my own changes, and have trouble tracking down their cause. Anyway, I *think* I'm getting closer. Here are the errors I'm getting now. error C2381: 'exit' : redefinition; __decllspec(noreturn) differs fatal error C1083: Cannot open include file: 'jpeglib.h': No such file or directory That first error is in stdlib.h, which seems a bit bothersome. The second error is in jpgfactory.hxx, and is and #include jpeglib.h. Is there a standard C++ library I'm missing? This one is listed in Antoine's message, and you should find it in the archive : - open glut.h that you find in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\GL, find _CRTIMP void __cdecl exit(int);, and replace it with #if _MSC_VER = 1200 _CRTIMP __declspec(noreturn) void __cdecl exit(int); #else _CRTIMP void __cdecl exit(int); #endif -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Compiling with Visual Studio 2003.net
You either have to get libjpeg or remove the file that needs it. http://freshmeat.net/projects/libjpeg/ -Fred Drew wrote : That fixed the __dcllspec problem, but it's still not seeing jpeglib.h. And I tried commenting out this include line, and it couldn't find error.h, either...both of which are supposed to be standard C includes. Am I still missing a set of libraries? Thanks again, Drew On Tue, 21 Dec 2004 21:12:20 +0100, Frederic Bouvier [EMAIL PROTECTED] wrote: Drew wrote : Hey Guys, First, I want to thank you guys for all of your help. You've been very patient with me, since I'm really clueless as to how to get this working for the first time...I just want to make sure I get this compiled right to begin with (and with a stable release), so I avoid compounding existing problems with my own changes, and have trouble tracking down their cause. Anyway, I *think* I'm getting closer. Here are the errors I'm getting now. error C2381: 'exit' : redefinition; __decllspec(noreturn) differs fatal error C1083: Cannot open include file: 'jpeglib.h': No such file or directory That first error is in stdlib.h, which seems a bit bothersome. The second error is in jpgfactory.hxx, and is and #include jpeglib.h. Is there a standard C++ library I'm missing? This one is listed in Antoine's message, and you should find it in the archive : - open glut.h that you find in %VISUAL_DOT_NET_2003_DIRECTORY%\Vc7\PlatformSDK\Include\GL, find _CRTIMP void __cdecl exit(int);, and replace it with #if _MSC_VER = 1200 _CRTIMP __declspec(noreturn) void __cdecl exit(int); #else _CRTIMP void __cdecl exit(int); #endif ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
