If you are reading this you might have got already some experience either using Microsoft 's © FS98 , Looking Glass ' © Flight Unlimited II or any other of the commercially available PC flight simulators. As the price tag of those is usually within the 50$ range buying one of it should not be a serious problem given the fact, that running any serious PC flight simulator requires a hardware within the 1500$ range, despite dropping prices, at least.
Why then that effort of spending hundreds or thousands of hours of programming to build a free simulator? Obviously there must be good reason to do so:
The above-mentioned points make FlightGear different from other competitors in several respect. FlightGear aims to be a civilian, multi-platform, open, user-supported, user-extensible simulator:
There is ongoing effort to support more platforms such as the MacIntosh . At this time we are not aware of the existence of any other serious multi-platform flight simulator - neither commercial nor free. Initial ideas on support for DOS or OS/2 were dropped later because of diminishing interest in these platforms and the non-availability of OpenGL for DOS.
The Gnu Public License is often misunderstood. In simple terms it states that you can copy and freely distribute the program(s) licensed to it. You can modify them, if you like. You are even allowed to charge as much money for the distribution of the modified or original program as you want. However, you must distribute it complete with the entire source code and it must retain the original copyrights. In short:
At present, the Gnu Public License is not included in this document, but can be obtained from
http://www.gnu.org/copyleft/gpl.html.
Without doubt, the success of the Linux project initiated by Linus Torvalds inspired several of the developers. Not only has it shown that distributed development of even highly sophisticated software projects over the Internet is possible. It led to a product which, in several respect, is better than its commercial competitors.
This project goes back to a discussion of a group of net-citizens in 1996. This resulted in a proposal written by David Murr who, unfortunately, dropped out from the project (as well as the net) later. His proposal is still available from the FlightGear web site and can be found under
http://www.flightgear.org/proposal-3.0.
Although the names of the people and several of the details naturally changed in time, the spirit of that proposal was clearly retained up to the present status of the project.
Actual coding started in summer 1996 and by the end of that year essential graphics routines were completed. At that time, programming was mainly done and coordinated by Eric Korpela from Berkeley University (korpela@ssl.Berkeley.EDU). Early code was running under Linux as well as under DOS , OS/2 , Windows 95/NT , and Sun-OS . This was quite an ambitious project, as it involved, among others, writing all the graphics routines in a system-independent way just from scratch.
Development slowed down and finally stopped at the beginning of 1997 when Eric had to complete his thesis. At this point, the project seemed to be dead and traffic on the mailing list went down to nearly nothing.
It was Curt Olson from the University of Minnesota (curt@flightgear.org) who re-started the project in the middle of 1997. His idea was as simple as successful: Why invent the wheel a second time? There have been several free flight simulators available running on workstation s under several flavors of UNIX . One of these, LaRCsim , which was developed by Bruce Jackson from NASA (jackson@larc.nasa.gov) seemed to be well-adapted for the present approach. Curt took this one apart and re-wrote several of the routines in a way making them build-able as well as run-able on the intended target platforms. The key idea in doing so was selecting a system-independent graphics platform, i. e. OpenGL , for the basic graphics routines .
In addition, a clever decision on the selection of the basic scenery data was already made in this very first version. FlightGear Scenery is created on the basis of satellite data published by the U. S. Geological Survey . These terrain data are available for the whole world over the Internet for free from
http://edcwww.cr.usgs.gov/doc/edchome/ndcdb/ndcdb.html
for the US resp.
http://edcwww.cr.usgs.gov/landdaac/gtopo30/gtopo30.html
for other countries. Those freely accessible scenery data in conjunction with scenery building tools provided with FlightGear are an important prerequisite enabling anyone to create his or her own scenery, at least in principle.
This new FlightGear code - still largely being based on original LaRCsim code - was released in July 1997. From that moment the project gained momentum again. Here are some milestones from the further history of development:
With these two achievements FlightGear became flyable again even on weaker machines as long as they included a 3D graphics board with hardware OpenGL support. (With respect to this point one should keep in mind that the code at present is in no way optimized leaving a lot of room for further improvements of frame rate.)
ftp://ftp.kingmont.com/pub/kingmont/.
http://www.flightgear.org/News/.
While in principle you can run FlightGear on 3D boards without OpenGL support or even on systems without 3D graphics hardware, missing hardware OpenGL support can force even the fastest PII to its knees (frame rate s typically below 1 fps even on fast machines). Any cheap 3D graphics card will do as long as it features hardware OpenGL support. For Windows 98/NT drivers, you may contact the home page of the manufacturer. Moreover, you should have in mind that most OpenGL drivers are still marked as beta and moreover, often these drivers are provided by the makers of the graphics chip instead of the makers of the board. More detail on OpenGL drivers can be found under
http://www.x-plane.com/v4ibm.html
as well as under
http://www.flightgear.org/Hardware.
Moreover, you need around 16MB of free disk space for installing the executable including most of the scenery. In case you want to compile the program yourself you need around 50MB for the source code and for temporary files created during compilation, independent of the operating system.
If you want to hear the sound effects any decent sound card should serve. At present, support for using a joystick or yoke is just in its early stages, but is expected to work on most systems. At present, Pedals are supported under UNIX/Linux only.
With respect to operating systems, FlightGear is being primarily developed under Linux , a free UNIX clone developed cooperatively over the net in much the same way as the FlightGear project itself. Moreover, FlightGear runs under Windows 95 , Windows 98 and Windows NT and given you have a proper compiler installed it can be build under all of these platform as well. The primary compiler for all platforms is GNU C++ (i. e. the Cygnus compiler under Win32), however there is some support for MSVC 5 as well. Moreover, FlightGear runs and can be build on several UNIX /X11 platforms with GNU C++ installed.
At first: There is not much of the material in this Guide being originally invented by ourself. You could even say with Montaigne that we ''merely gathered here a big bunch of other men's flowers, having furnished nothing of my own but the strip to hold them together''. Most (but fortunately not all) of the information can as well be grabbed from the FlightGear home page being situated at
and its various sub pages. However, there still seem to be a small group of people preferring neatly printed manuals over loosely scattered Readmes and those may acknowledge our effort.
This Installation and Getting Started is intended as being a first step towards a more complete FlightGear documentation (with the other parts, supposedly, to be written by others). Its main addressee is the end-user who is not interested in the internal workings of OpenGL or in building his or her own scenery, for instance. It is our hope, that sometime there will be an accompanying FlightGear Programmer's Guide , which could be based on some of the documentation under
http://www.flightgear.org/Docs,
a FlightGear Scenery Design Guide , and a FlightGear Flight School , at least.
This Installation and Getting Started is organized as follows:
The first chapter 2, Getting the engine: Installing OpenGL graphics drivers, describes how to prepare the computer for handling FlightGear 's graphics routines. FlightGear is based on a graphics library called OpenGL, thus you must install either hardware or software OpenGL support for your graphics board (except, you did so before, of course).
Chapter 3, Building the plane: Compiling the program, explains how to build, i. e. compile the simulator. Depending on your platform this may or may not be required for you. There will at least be binaries available for those working on a Win32 (i. e. Windows 98 © or Windows NT ©) platform. For those on such systems, who want to take off immediately without going through the potentially troublesome process of compiling, we recommend just skipping that chapter and going directly to the next one.
In chapter 4, Preflight: Installing FlightGear , you find instructions for installing the binaries in case you did not so by building them in the previous chapter. Moreover, you'll have to install scenery and texture files, which will be described there, too.
The following chapter 5, Takeoff: How to start the program, describes how to start the program including an overview on the command line options.
Flight: Keystrokes, HUD, and all that, chapter 6, describes how to operate the program, i. e. to actually fly with FlightGear . This includes several lists of key strokes as well as a detailed description of the HUD (head up display) as the primary instrument for controlling the plane.
In chapter 7, Landing: Some further thoughts before leaving the plane, we would like to give credits to those who did the hard work and give an outlook on what remains to be done.
Finally: We kindly ask others to help us improving this document by submitting corrections, improvements, and more. Notably, we invite others to contribute descriptions referring to alternative setups (graphics cards, operating systems, and compilers etc.). We will be more than happy to include those into forthcoming versions of this Installation and Getting Started (of course not without giving credit to the authors).
We hope to continuously maintain this document at least for a foreseeable future, but probably will not be able to produce a new one for any single release of FlightGear . While we are both watching the mailing lists, it might help, if developers adding new functionality could send us a short note.
Unfortunately, there are so many graphics boards, graphics chips and drivers that we are unable to provide a complete description for all systems at present, but we hope to be able to extend that section with the help of others soon. To give beginners a hand, we just describe what we did to install drivers on our systems.
By any means, should you try getting hardware OpenGL drivers for your system, which is exemplary described in sections 2.1 to 2.4, resp. If you are unable to locate any such drivers you can try software support as detailed under 2.5.
An excellent place to search for documentation about Linux and 3D accelerators is the Linux 3Dfx HOWTO at
http://www.gamers.org/dEngine/xf3D/howto/3Dfx-HOWTO.html.
It describes all the following steps in an in-depth fashion and should be your first aid in case something goes wrong with your 3D setup.
The 3DFX graphics card is a quite popular one (We tested the Voodoo 1 to work). At first, you need the GLIDE library installed. Grab it at:
http://www.3dfx.com/software/download_glidel.html
and install it. Be careful, you need different Glide libraries for the different types of VooDoos (I, II, Banshee). There is even an install script included that will do things for you. The canonical place for GLIDE is /usr/local/glide, if you prefer another location, you'll have to edit the Makefile for FlightGear by hand. Be sure to read and understand the file /usr/local/glide/README. Next, you need to install the MESA library version 3.0 (or later). Grab it at
ftp://iris.ssec.wisc.edu/pub/Mesa,
unpack it and run
make linux-glide
in the Mesa directory. Follow the instructions in the README file, take a close look at README.3DFX and play with the demo programs.
Besides these, you need the GLUT library version 3.7 (or greater, aka GameGLUT) installed. Grab it at:
http://reality.sgi.com/opengl/glut3/glut3.html.
Note: Glut-3.7 is included with Mesa 3.0 so if you've already grabbed the latest version of mesa, you should have everything you need.
Finally, some more notes on the behavior of Voodoo boards:
Your card comes packaged with a loop-through-cable . If you have only one monitor, then the Voodoo will take it over when used. This means that all the applications on your desktop will continue running but you'll only see the FlightGear screen. If your window manager uses a focus-follows-mouse policy, don't move the mouse. If you lose the focus, there's no way to shut down FlightGear graciously! Better solution: Use two monitors, one for your desktop, connect the other one to your accelerator. You'll then get a window on your desktop which manages all keyboard events and you're still able to see your desktop.
Running FlightGear under Linux using a 3DFX accelerator board is somewhat tricky. Most of the boards behavior is controlled by environment variables. The two most important are:
http://www.bahnhof.se/~engstrom/e_3dfxvars.htm.
This section serves as an example for installing OpenGL drivers under Windows 98/NT . The Rendition 2100 chipset is, for instance, part of the Diamond Stealth II card performing especially well in somewhat weaker machines.
Diamond itself does not provide any OpenGL driver support for that board. However, Rendition, who make the graphics chip, do. Go to their Web site and grab the latest OpenGL Windows drivers from
http://www.rendition.com/download.html
Follow the description in readme.txt. We recommend making the drivers the default ones by copying them to \windows\system (which avoids the hassle of not being sure which driver actually runs).
With this step you're already done.
According to our experience, so-called mini-OpenGL drivers provided by some manufacturers for making Quake playable do not provide the level of OpenGL support required by FlightGear . At least, Rendition's mini-OpenGL driver definitely does not.
Because of its high performance, the RIVA TNT is one of the most popular chipsets today. The Diamond Viper 550 , ELSA Erazor-2, Creative Graphics Blaster , and more cards are equipped with this chip. At least the default Viper 550 drivers are known to us having native built-in OpenGL support making any add-on OpenGL drivers obsolete. Similar things should apply to the other RIVA TNT based cards. In any case, NVIDIA's reference drivers being available from
do the job as well.
The 3DXF based 3D add-on or 2D/3D boards are perhaps the most popular ones today at all. 3DFX made Beta OpenGL Windows 98 drivers available on their Website at
From the main page go to Develop 3DFX and further to SDKs and Demos and grab them there.
First, make sure you have the file glu32.dll either under \Windows\System or elsewhere in your path. If not, install the MS OpenGL kit opengl95 available from Microsoft or elsewhere on the net. (Which by itself only provides software rendering.)
Next, locate the file 3dfxopengl.dll. in the 3DFX driver package, rename it to opengl32.dll and copy it into \Windows\System overwriting the file with the same name installed from the MS kit. This should get you going.
If you have an accelerated 3D card, it is highly recommended you install hardware OpenGL drivers for your specific card.
However, in case you are really unable to find such drivers and want to try FlightGear despite this you can install SGI software OpenGL rendering. For this purpose, get the file sgi-opengl2.exe from
http://www.flightgear.org/Downloads/.
This is a Windows 98/NT self extracting installation program. Install it by double-clicking in Windows explorer. The package includes some demo games you may wish to try by invoking them from the Start menu.
As you will note, this chapter is far from being complete. Basically, we describe compiling for two operating systems only, Windows 98/NT and Linux . There is a simple explanation for this: These are just the systems we are working on. We hope to be able to provide descriptions for more systems based on contributions written by others.
If you are running Linux you probably have to build your own binaries . The following is one way to do so.
http://www.flightgear.org/Downloads/
tar xvfz FlightGear-x.xx.tar.gz.
./configure
and wait a few minutes. configure knows about a lot of options. Have a look at the file INSTALL in the FlightGear source directory to learn about them. If run without options, configure assumes that you will install the data files under /usr/local/lib/FlightGear.
make
and wait for the make process to finish.
make install.
This will install the binaries in /usr/local/bin.
There is a problem concerning permissions under Linux/Glide. All programs accessing the accelerator board need root permissions. The solution is either to play as root or make the /usr/local/bin/fgfs binary setuid root, i.e. when this binary is run root privileges are given. Do this by issuing (as root)
chmod +s /usr/local/bin/fgfs.
A solution for this problem is upcoming, keep an eye on the 3Dfx website if you run a 3Dfx board.
http://www.cygnus.com/misc/gnu-win32/.
You can download the Cygnus Gnu-Win32 compiler from:
ftp://ftp.cygnus.com/pub/gnu-win32/latest/cdk.exe.
To install it, just run the file cdk.exe by double-clicking in Windows explorer. Be sure to read this package's README :
http://www.cygnus.com/misc/gnu-win32/readme_toc.html.
Next, you need several UNIX developmental tools, being compiled for Windows 98/NT. These are bundled in the package usertools. Get it from
ftp://ftp.cygnus.com/pub/gnu-win32/latest/usertools.exe
and install it by double-clicking as well. After doing so you should find a program group called Cygnus Solutions in your start menu.
http://www.xraylith.wisc.edu/~khan/software/gnu-win32/egcs.html
Again, make sure you follow the directions. It is recommended that you unroll the EGCS stuff over top of your Cygwin32 installation. It will replace many of the files.
mkdir /mnt
mount d: /mnt
You only have to do this once. The drive stays mounted (until you umount it) even through reboots and switching off the machine.
http://www.flightgear.org/Downloads/Source
Grab the latest FlightGear-X.XX.zip and win32-libs-X.XX.zip files.
pkunzip -d FlightGear-X.XX.zip.
(Be sure to use the -d option. This will create all the needed subdirectories. Otherwise you will have one big mess!)
cd //D/FlightGear-X.XX
and unpack the Win32 libraries:
pkunzip -d win32-libs-X.XX.zip.
Side Note: We need to make a distinction between the build tree and the install tree . The build tree is what we've been talking about up until this point. This is where the source code lives and all the compiling takes place. Once the executables are built, they need to be installed someplace. We shall call this install location the install tree. This is where the executables, the scenery, the textures, and any other run-time files will be located.
./configure --prefix=/mnt/FlightGear.
Side note: The make procedure is designed to link against opengl32.dll, glu32.dll, and glut32.dll which most accelerated boards require. If this does not apply to yours or if you installed SGI's software rendering as mentioned in subsection 2.5 you may have to change these to opengl.dll, glu.dll, and glut.dll. (In case you're in doubt check your \windows\system directory what you've got.)
If this is the case for your video card , you can edit .../Simulator/Main/ Makefile and rename these three libraries to their "non-32" counterparts. There is only one place in this Makefile where these files are listed.
make.
make install.
You can save a significant amount of space by stripping all the debugging symbols off of the executable. To do this, change to the directory in the install tree where your binary lives and run:
strip fgfs.exe resp. strip fgfs-sgi.exe.
The following supposes you are on a Windows 98 or Windows NT system. Installing the binaries is quite simple. Go to the FlightGear downloads page
http://www.flightgear.org/Downloads/
and get the latest binaries from the binaries subdirectory named
fg-win32-bin-X.XX.exe
and unpack them via double clicking. This will create a directory FlightGear with several subdirectories. You are done.
Independent on your operating system and independent on if you built the binaries yourself or installed the precompiled ones as described above you will need scenery , texture , and sound files. A basic package of all these is contained in the binaries directory mentioned above as
fgfs-base-X.XX.
Preferably, you may want to download the .tar.gz version if you are working under Linux /UNIX and the .exe version if you are under Windows 98/NT . Make sure you get the most recent version.
If you're working under Linux or UNIX , unpack the previously downloaded file with
tar xvfz fgfs-base-X.XX.tar.gz,
while under Windows 98/NT just double click on the file (being situated in the root of your FlightGear drive.).
This already completes installing FlightGear and should enable you to invoke the program.
Some more scenery which, however, is not a substitute for the package mentioned above but rather is based on it can be found in the scenery subdirectory under
http://www.flightgear.org/Downloads/
These may be older versions which may or may not work with the most recent binaries.
In addition, there is a complete set of USA Scenery files available created by Curt Olson which can be downloaded from
ftp://ftp.kingmont.com/pub/kingmont/index.html.
The complete set covers several 100's of MBytes. Thus, Curt provides the complete set on CD-ROM for those who really would like to fly over all of the USA. For more detail, check the remarks in the downloads page above.
Finally, the binaries directory mentioned contain the complete FlightGear documentation including a .pdf version of this Installation and Getting Started guide intended for pretty printing using Adobe's Acrobat reader being available from
on any printer.
fgfs --option1 --option2...,
where the options are described in section 5.3 below.
In Windows explorer, change to \FlightGear\. Call runfgfs.bat by double-clicking if you want to invoke the hardware accelerated version of FlightGear fgfs.exe, or runfgfs-sgi.bat if you installed SGI's software OpenGL support.
Alternatively, if for one or the other reason the batch does not work, you can open an MS-DOS shell, change to the directory where your binary resides (typically something like d:\FlightGear\bin where you might have to substitute d: in favor of your FlightGear directory), set the environment variable with
SET FG_ROOT=d:\FlightGear\bin
and invoke FlightGear (within the same shell - Windows environment settings are only valid locally within the same shell) via
fgfs --option1 --option2....
For getting maximum performance it is highly recommended to minimize (iconize) the non-graphics window while running FlightGear .
Following is a list and short description of the command line options available. In case of Windows 98/NT it is recommended to include these in runfgfs.bat.
At present, support for using a joystick or yoke is just in its early stages. It may or may not work - just try it! In any case, you can use keyboard commands instead. For proper controlling via keyboard (i) the NumLock key must be switched on (ii) the FlightGear window must have focus (if not, click with the mouse on the graphics window).
After activating NumLock the following keyboard commands should work:
Tab. 1: Main keyboard commands for FlightGear .
Key | Action |
Pg Up/Pg Dn | Throttle |
Left Arrow/Right Arrow | Aileron |
Up Arrow/Down Arrow | Elevator |
Ins/Enter | Rudder |
5 | Center aileron/elevator/rudder |
Home/End | Elevator trim |
For changing views you have to de-activate NumLock. Now Shift + < Numeric Keypad Key > changes the view as follows:
Tab. 2: View directions accessible after de-activating NumLock.
Numeric Key | View direction |
Shift-8 | forward |
Shift-7 | left/forward |
Shift-4 | left |
Shift-1 | left/back |
Shift-2 | back |
Shift-3 | right/back |
Shift-6 | right |
Shift-9 | right/forward |
Moreover, the autopilot is controlled via the following controls:
Key | Action |
Ctrl + A | Altitude hold toggle on/off |
Ctrl + H | Heading hold toggle on/off |
Ctrl + S | Autothrottle toggle on/off |
Ctrl + T | Terrain follow toggle on/off |
The last one is especially interesting as it makes your
Navion
behave like a cruise missile.
Besides these basic keys there are some more special ones; most of these you'll probably not want to try during your first flight:
Tab. 4: More control commands.
Key | Action |
H/h | Change color of HUD/toggle HUD off forward/backward |
i/I | Minimize/maximize HUD |
m/M | Change time offset (warp) used by t/T forward/backward |
t/T | Time speed up/slow down forward/backward |
x/X | Zoom in/out |
z/Z | Change visibility (fog) forward/backward |
b | Toggle brakes on/off |
p | Toggle pause on/off |
W | Toggle fullscreen mode on/off (Mesa/3dfx/Glide only) |
F8 | Toggle fog on/off |
F9 | Toggle texturing on/off |
F10 | Toggle menu on/off |
ESC | Exit program |
At present, the main instrument for controlling the plane is the HUD (Head Up Display , see Fig. 1). Neither are HUD s used in usual general aviation planes nor in civilian ones. Rather they belong to the equipment of modern military jets. However, in view of the fact that the panel is still in the early stages of development the HUD is the main instrument for controlling the plane for now. Besides, it might be easier to fly using this one than exploiting a panel and several of the real pilots might prefer it because of combining the readouts of critical parameters with an outside view onto the real world. (Several Cessna pilots might love to have one, but technology is simply too expensive for implementing HUDs in general aviation aircrafts.)
The most important information for navigating, i. e. throttle , elevation , aileron can be found on the r.h.s of the HUD . These are just given on a scale between 0 and 1. Above these you find the AOA (angle of attack ; the angle between the wings and the relative wind i. e. the direction of airflow), the heading given in degrees, and the sideslip .
On the left hand side you find the speed in kts and the roll given in degrees. You may recall the Navion taking off at a speed of 100 kts. Still further left you find the FOV (= field of view ) in degrees. Zooming in and out with the x/X keys changes this one. The value below that, the number of triangles rendered is usually not of importance for you as a pilot (and can be switched off via a corresponding startup option). Below you find the frame rate , displaying the frames per second.
Besides these figures, most of the flight parameters and flight characteristics are displayed graphically in the upper half of the screen. In the center you find the pitch indicator (in degrees) with the aileron indicator above and the rudder indicator below. A corresponding readoff for the elevation can be found to the left of the pitch scale. Below the pitch indicator you will find a simple turn indicator .
There are two scales further left: The inner one displays the speed (in kts) while the outer one gives the vertical speed (climb/sink rate ). The two scales on the r.h.s display your height , i. e. the left of it shows the height above ground while the right of it gives that above zero, both being displayed in feet.
Based on these keystrokes and the HUD you should be able to properly control the plane. Try it! The functions already implemented are completely sufficient for even doing complicated manoeuvres.
In addition, FlightGear has a rudimentary menu which, however, is not yet working. If you're done and are about to leave the plane, just hit the ESC key to exit the program.
If you are looking for some interesting places to discover with FlightGear (which may or may not require downloading additional scenery) you may want to check
http://www.flightgear.org/Downloads/Places.
Did you enjoy the flight? In case you did, don't forget those who devoted hundreds of hours to that project. All of this work is done on a voluntary basis within spare time, thus bare with the programmers in case something does not work the way you want it to. Instead, sit down and write them a kind (!) letter proposing what to change. Alternatively, you can subscribe to the FlightGear mailing lists and contribute your thoughts there. Instructions to do so can be found under
http://www.flightgear.org/mail.html.
Essentially there are two lists, one of which being mainly for the developers and the other one for users.
These are the people who did the job (This information was essentially taken from the file Thanks accompanying the code):
Raul Alonzo
(amil@las.es)
Author of Ssystem and
moon texture.
Michele America
(nomimarketing@mail.telepac.pt)
Contributed to the HUD
code.
Steve Baker
(sjbaker@hti.com)
Author of PUI
(a graphical interface written entirely on top of
OpenGL
/GLUT
). Author of the basic
audio library
used in FlightGear . An immense amount of coaching and tutelage,
both on the subjects of flight simulation and OpenGL
. It has been
his comments and thoughts that have prompted the implementation of
most of the more sophisticated features of FlightGear .
Michael Basler
(pmb@knUUt.de)
Coauthor of Installation and Getting Started (together with Bernhard
Buckel).
John S. Berndt
(jsb@hal-pc.org)
Working on a complete C++rewrite/reimplimentation of the core FDM.
Initially he is using X15 data to test his code, but once things are
all in place we should be able to simulator arbitrary aircraft.
Paul Bleisch
(pbleisch@acm.org)
Paul redid the debug system so that it would be much more
flexible, so it could be easily disabled for production system, and
so that messages for certain subsystems could be selectively
enabled.
Also contributed a first stab at a config file/command line parsing system.
Jim Brennan
(jjb@foothill.net)
Provided a big chunk of online space to store USA scenery for Flight Gear.
Bernie Bright
(bbright@c031.aone.net.au)
Many C++ style, usage, and implementation improvements, STL
portability and much, much more.
Bernhard H. Buckel
(buckel@wmad95.mathematik.uni-wuerzburg.de)
Contributed the README.Linux. Coauthor of Installation
and Getting Started (together with Michael Basler).
Gene Buckle
(geneb@nwlink.com)
Gene has done a lot of work getting FlightGear to compile with the MSVC
++
compiler. Numerous hints on detailed improvements.
Didier Chauveau
(chauveau@math.univ-mlv.fr)
Provided some initial code to parse the 30 arcsec DEM files found at:
http://edcwww.cr.usgs.gov/landdaac/gtopo30/gtopo30.html.
Jean-Francois Doue
Vector 2D, 3D, 4D and Matrix 3D and 4D inlined C++ classes. (Based on
Graphics Gems IV ed. Paul S. Heckbert)
http://www.animats.com/simpleppp/ftp/public_html/topics/developers.html.
Francine Evans (evans@cs.sunysb.edu)
http://www.cs.sunysb.edu/~evans/stripe.html
Wrote the GPL'd tri-striper.
Oscar Everitt
(bigoc@premier.net)
Created single engine piston engine sounds as part of an F4U package
for FS98
. They are pretty cool and Oscar was happy to contribute
them to our little project.
Jean-loup Gailly
and Mark Adler
(zlib@quest.jpl.nasa.gov)
Authors of the zlib library
. Used for on-the-fly compression and
decompression routines,
http://www.cdrom.com/pub/infozip/zlib/.
Thomas Gellekum
(tg@ihf.rwth-aachen.de)
Changes and updates for compiling on FreeBSD
.
Jeff Goeke-Smith
(jgoeke@voyager.net)
Contributed our first autopilot
(Heading Hold).
Better autoconf check for external timezone/daylight variables.
Michael I. Gold
(gold@puck.asd.sgi.com)
Patiently answered questions on OpenGL
.
Charlie Hotchkiss
(chotchkiss@namg.us.anritsu.com)
Worked on improving and enhancing the
HUD
code. Lots of code style tips and code tweaks...
Bruce Jackson (NASA) (e.b.jackson@larc.nasa.gov)
http://agcbwww.larc.nasa.gov/People/ebj.html
Developed the LaRCsim code under funding by NASA which we use to provide the flight model. Bruce has patiently answered many, many questions.
Tom Knienieder
(knienieder@ms.netwing.at)
Ported Steve Bakers's audio library
to Win32.
Reto Koradi (kor@mol.biol.ethz.ch)
http://www.mol.biol.ethz.ch/~kor
Helped with setting up fog effects .
Bob Kuehne
(rpk@sgi.com)
Redid the Makefile system so it is simpler and more robust.
Vasily Lewis (vlewis@woodsoup.org)
Provided computing resources and services so that the Flight Gear project could have real home. This includes web services, ftp services, shell accounts, email lists, dns services, etc.
Eric Mitchell
(mitchell@mars.ark.com)
Contributed some topnotch scenery textures
.
Anders Morken
(amrken@online.no)
Maintains the European mirror of the FlightGear web pages.
Alan Murta (amurta@cs.man.ac.uk)
http://www.cs.man.ac.uk/aig/staff/alan/software/
Created the Generic Polygon Clipping library.
Curt Olson
(curt@flightgear.org)
Primary organization of the project. First implementation
and modifications based on LaRCsim
. Besides putting together all
the pieces provided by others mainly concentrating on the scenery
engine
as well as the graphics stuff.
Friedemann Reinhard
(mpt218@faupt212.physik.uni-erlangen.de)
Development of textured instrument panel
.
Petter Reinholdtsen
(pere@games.no)
Incorporated the Gnu automake/autoconf system (with libtool).
This should streamline and standardize the build process for all
UNIX-like platforms. It should have little effect on IDE type
environments since they don't use the UNIX make system.
William Riley
(riley@technologist.com)
Contributed code to add ''brakes''.
Paul Schlyter
(pausch@saaf.se)
Provided Durk Talsma with all the information he needed to write the astro code.
Chris Schoeneman
(crs@millpond.engr.sgi.com)
Contributed ideas on audio support.
Jonathan R Shewchuk
(Jonathan_R_Shewchuk@ux4.sp.cs.cmu.edu)
Author of the Triangle
program. Triangle
is used to calculate the Delauney triangulation of our irregular terrain.
Gordan Sikic
(gsikic@public.srce.hr)
Contributed a Cherokee flight model
for LaRCsim
. Currently is not
working and needs to be debugged. Use configure
--with-flight-model=cherokee
to build the cherokee instead of the Navion
.
Michael Smith
(msmith99@flash.net)
Contributed cockpit graphics, 3d models, logos, and other images.
Project Bonanza
http://members.xoom.com/ConceptSim/index.html.
http://edcwww.cr.usgs.gov/doc/edchome/ndcdb/ndcdb.html
Provided geographic data used by this project.
Durk Talsma
(pn_talsma@macmail.psy.uva.nl)
Accurate Sun, Moon, and Planets. Sun changes color based on
position in sky. Moon has correct phase and blends well into the
sky. Planets are correctly positioned and have proper magnitude.
Gary R. Van Sickle
(tiberius@braemarinc.com)
Contributed some initial GameGLUT
support and other fixes.
Norman Vine
(nhv@laserplot.com)
Many performance optimizations throughout the code. Many contributions
and much advice for the scenery generation section. Lots of Windows
related contributions.
Carmelo Volpe
(carmelo.volpe@csb.ki.se)
Porting FlightGear to the Metro Works
development environment
(PC/Mac).
Robert Allan Zeh
(raz@cmg.FCNBD.COM)
Helped tremendously in figuring out the Cygnus
Win32 compiler and
how to link with .dll's. Without him the first run-able Win32
version of FlightGear would have been impossible.
Despite, FlightGear needs - and gets - further development. Except internal tweakings, there are several fields where FlightGear needs basics improvement and development.
A first direction is adding airports , streets, rivers and all that bringing the Scenery to real life.
Second, the panel (being disabled by default at present) needs further improvement including more working gauges.
Besides, there should be support for adding more planes and for implementing corresponding flight models differing from the basic Navion .
Another major task is further implementation of the menu system , which at its present state basically does nothing.
Another direction concerns audio support . While the audio library itself is essentially complete there is a need for more sounds to play and for code to drive it.
There are already people working in all of these directions. But if you're a programmer and think you can contribute, you are invited to do so.
Beyond this we would like to say special thanks to Curt Olson, whose numerous scattered Readmes, Thanks, Webpages, and personal eMails were of special help to us and were freely exploited in the making of this booklet.
Further, we would like to thank Kai Troester for donating the solution of some of his compile problems to our Chapter 8.
In addition, we would like to thank Steve Baker for a careful reading and for numerous hints on the first draft of this guide.
In addition we gained from hints given to Newcomers on the Mailing lists, notably from those given by Norman Vine , to name only one.
Second, check if your drivers are properly installed. Several cards need additional OpenGL support drivers besides the ''native'' windows ones. For more detail check chapter 2.
Third, check if your hardware driver is called opengl32.dll or just merely opengl.dll. By the default compilation, binaries are linked against open gl32.dll. If you require the non-32 version, consider rebuilding FlightGear with the libraries opengl32.dll, glut32.dll, and glu32.dll replaced by their non-32 counterparts. For more details check chapter 3.
If you installed the pre-compiled binaries runfgfs.bat invokes fgfs.exe while runfgfs.sgi.bat invokes fgfs.sgi.exe with the first ones being linked against the 32-versions.
Usually, hardware accelerated drivers use the 32-libraries.
Since we don't have access to all possible flavors of Linux distributions, here are some thoughts on possible causes of problems. (This section includes contributions by Kai Troester Kai.Troester@rz.tu-ilmenau.de.)
chown root.root /usr/local/bin/fgfs ;
chmod 4755 /usr/local/bin/fgfs
to give the FlightGear binary the proper rights. There is development of a device named /dev/3dfx underway, so this probably being remedied in the near future.
http://www.flightgear.org/mail.html.
This will give you direct contact to the developers.
If the configure script could not find your Mesa and Glut libraries you should add the Mesa library-path (i.e. /usr/local/Mesa) to the EXTRA_DIRS variable in the file configure.in (i.e. EXTRA_DIRS=''/usr/local/usr/ X11R6/usr/local/Mesa''). After this you have to run autoconf. (Please read README.autoconf for running autoconf )
/* needed to compile fgfs properly*/
#undef FG_NDEBUG
#undef PACKAGE
#undef VERSION
#undef WIN32a
(a solution for this problem is coming soon )
Additionally there are two versions of the GNU C compiler around: egcs and gcc (the classic one). gcc seems to have its own notion of some C++ constructs, so updating to egcs won't hurt and maybe help to compile the program.
Another potential problem might be you did not download the most recent versions of scenery and textures required by FlightGear , or you did not load any scenery or texture at all. Have a close look at this, as the scenery/texture format is still under development and may change frequently. For more detail, check chapter 4.
A further potential source of trouble are so-called mini-OpenGL drivers provided by some manufacturers. In this case, FlightGear 's typically hangs while opening the graphics window. In this case, either replace the mini-OpenGL driver by a full OpenGL driver or or in case such is not available install software OpenGL support (see section 2.5).
Make sure you change to the Main FlightGear directory, e. g. with
cd //D/FlightGear-X.XX
before running Configure and Make.
http://www.flightgear.org/Downloads/Source.
Index (showing section)