New Computer Setup - 2006-10-31

index - next page

This was my first few weeks with my new machine, so some things failed, and some succeeded. The follow on page is full of SUCCESS ... but, this was the story then, with LOTS of information on where to get things using cvs/svn where possible ... initial downloading, that is check out, and updating of cvs, and much more ;=))

My new computer, a Dell, was promptly delivered today, 31 Oct, 2006, by UPS - in their nice brown trucks ;=)) I had ordered it on the 27th - and the first thing I wanted to do was get FlightGear up and running, and these are the steps taken ... it came with a single 320 GB drive, split into a 218 GB C: drive, and a 74.5 GB backup drive D:, both formatted in NTFS file system. The OS is Microsoft XP Media Centre 2005 ... full computer description below ...

Unfortunately, or fortunately, depending on your perspective ;=)) FlightGear chose this same time to cut over to OpenSceneGraph (OSG), replacing the scene graph previously of PLIB, so this is in effect my first build with this new prerequisite, OSG. Also, being in a new machine, I wanted to use the latest Microsoft compiler, Visual Studio 2005 Express Edition (MSVC8), and not refer back to previous, older installations.

Also, there are other FlightGear developers, Mathias Froehlich, and Olaf Flebbe, who works with MSVC8, and OSG. Olaf maintains a helpful website - - with links to tools, patches and 'solution' project files. And Mathias has ftp downloads, like - -This is particularly important during this switch to OSG ...

While the download and build of most of the prerequisites, has been completed, OSG is taking more time than expected, thus the page is incomplete at this time. It does contain a lot of helpful 'hints' on building a number of prerequisites, so I have published it ahead of time. The following table contains many external links, which will open in a new page, and internal page links. NOTE THIS PAGE IS A WORK IN PROGRESS,  SO IS PRESENTLY BEING FREQUENTLY UPDATED - make sure you 'refresh' your browser - Enjoy ... Geoff R. McLane.

Utilities - CVS SVN ZIP
Prerequisites :-
Site - Download and Build
zlib - download build -
PLIB - download build -
freeglut - download build
openal - download build -
OSG - download build -
pthreads - download build -
SimGear - download build -
FlightGear - download build
first run osg dll second run abort2
fgolafosg fgpreosg fgbld3 fgbld4
FG build end

Folder arrangement -
current folder arrangement
Images: below, in-between,
and above

1. Microsoft Visual Studio 2005 Express Edition

From - - I made an initial error, and downloaded Microsoft Visual Web Developer 2005 Express Edition first! That's ok, because I also want this ... It downloaded, and installed Microsoft .NET Framework 2.0, Visual Web Developer 2005 Express Edition, and Microsoft MSDN 2005 Express Edition, the latter being a 312 MB download. This takes some time, even with my 1 GB internet connection, since the download through put is only around 126 KB/sec ... installation consumed about 700 MB ...

Of course, being a NEW computer, I was continually interrupted by Microsoft 'updates' ... and had to RESTART the computer many times ... after the download and install of the above completed, although the 're-boot' dialog interrupted several times, which would make a hands-free installation nearly impossible ;=((. at least one of the updates was to the just installed .NET Framework 2.0 ...

Next I installed Visual C++ 2005 Express Edition (68 MB), and for no particular reason, added Microsoft SQL Server 2005 Express Edition x86 (56  MB) ... the download page reminds you that you also need the 'Platform SDK' ... this installed Microsoft Platform SDK (R2) ...

Actually it is Microsoft Platform SDK for Windows Server 2003 ... quite a long process ... many files, some in the multi-megabyte range, and a lot related to the fast arriving win64 ... some 'delays' seemed to be due to the Microsoft server waiting for something, or doing something else ... and on reflection, perhaps I should have chosen the 'custom' install, and maybe I could have avoided a least some of the win64 stuff which I do not need yet ...

There is some important setup information on the download page - - after installing the SDK it is necessary to add paths to the appropriate subsection in the Options dialog box, or directly modify VCProjectEngine.Dll.Express.Config in the VC8 install folder. It is well worth the effort to create a new project, and compile it, just to make sure everything is working ;=))

And, to be able to compile the OpenAL (sound) library, you will also need to download, and install MicroSoft DirectX. I first tried - - which also requires a download of a Microsoft ActiveX component to verify the windows installation. This download seemed to install the DirectX SDK (February 2006), but this QUICK web install FAILED to include the most important header needed - dsound.h!

From - - I downloaded the 509 MB dxsdk_oct2006.exe (over 1 HOUR to download at 126 KB/sec), and installed this ... then I could add access the dsound.h headers.

To be sure, the following were added to Tools -> Options -> Projects and Solutions -> VC++ Directories -> Include files -

C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include
C:\Program Files\Microsoft DirectX SDK (October 2006)\Include
C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\MFC

The latter was NOT because I am using Microsoft Foundation Classes (MFC), but the openal project has a RC file which includes 'afxres.h' ... it is only needed to generate the 'language' macro ...

2. Utilities

Since, in most cases, I want the latest development code, of each of the 'component' libraries, the first things I needed was SVN (Subversion), CVS (Concurrent Version System) utilities. And in other cases, I will need to 'unpack' the compressed 'archive', so also need 'unzip' tools ...


It seem development has ceased on the site - - and you are automatically redirected to - - where clicking on 'CVS Downloads' leads to - - which, under 'CVS Clients' - Windows lists - - and - ...

I can no longer find the cvs.exe I use in my old machine - entering > cvs --version yields -

Concurrent Versions System (CVS) 1.11.17 (client) Copyright (c)
1989-2004 Brian Berliner, david d `zoo' zuhn, Jeff Polk, and other authors

And > cvs --help yields, among other things -

The Concurrent Versions System (CVS) is a tool for version control.
For CVS updates and additional information, see
the CVS home page at or
Pascal Molli's CVS site at 

But the link redirects to - - where I could only find GUI type versions for windows, but I did not 'search' very HARD ;=))

I decide to just copy my old, very reliable version from my old computer, to this new machine ;=() And put a copy in a zip here - MD5 ( = 58a6ae5eb66eb1641e441f9e86d5a791 - in case others want to use this simple command line client ... as usual, be warned about downloading and running EXE files from the web!

For what it is worth, I always put such applications in a folder called C:\MDOS ... just to remind me that this is a command line application, and so is FlightGear! ... and use Control Panel -> Performance and Maintenance -> System, selecting the 'Advanced' tab -> Environment Variables, and add ';C\MDOS' to the PATH in the 'System variables' ... then they can be used from any command prompt ...


The site - - announced subversion 1.4.0 released as of Sep 10, 2006, but it may obviously be subsequently updated ... so from - - I downloaded svn-1.4.0-setup.exe ... on running this setup EXE, by default it installed in C:\Program Files\Subversion\bin, and add this path to the environment PATH variable, whether you wanted it or not ;=(( this was new! The previous version, 1.3.0, I downloaded as a ZIP, and unzipped it to a folder of my choice, and added a batch file in my C:\MDOS folder ... is this progress ;=))

ZIP - Here meaning ALL forms of 'compress' archive files

There are quite a number of file types in this category - ARC, ARJ, B64, BHX, CAB, GZ, HQX, LZH, MIM, TAR, TAZ, TGZ, TZ, UU, UUE, XXE, Z, ZIP - just to mention those handled by WinZip on my system.

Some considerable time ago I purchased a licence for WinZip 9.0, and its command line add-in, wzcline.exe, but the current release WinZip 10.0 - - is no longer a 'free' upgrade. Yes, they offer a 50% off, but I was not prepared, at this time, to pay again, so I copied over my old winxip90.exe, and installed it, together with the command line add-in ...

There is a free 'archive' utility, 7-Zip - - I have downloaded and tried this, and it seemed to work fine, but since I have WinZip, then ... And from the site - - the files and contain a considerable number of GNU utilities for Win32 - a port of some common GNU utilities - including tar.exe, gzip.exe, unzip.exe, etc ... which offers another way to 'unpack' such 'archive' files ;=))

3. Prerequisite Dependencies - source downloads


I have chose a 'root' folder to add all these downloads to. In this case I have chose C:\FGCVS. To run either CVS or SVN, an environment variable CVSHOME must exist. I have established a setroot.bat batch file to do this. It contains the single line -


While in the folder C:\FGCVS, and after running the setroot.bat batch file, the following dependant sources can be downloaded ...


zlib - - download - build

A precompiled DLL, version 1.2.3 can be downloaded, but SimGear also requires the headers, and you would need to write a wrapper to satisfy the calls made by SimGear, so it is necessary to download the source, and compile it into a 'static' library, emitting the headers SimGear uses. They offer the source as a tar.gz, a tar.bz2, and a zip.

While the zip is marginally larger, it is all less than 600K, so should not present a problem. They do not presently seem to offer either a svn nor cvs source access, but since this source has not changed for some considerable time, there is little need to frequently 'update' it ...

I downloaded the, 570 KB, loaded it into my WinZip, and extracted all the files to C:\FGCVS\zlib-1.2.3.


PLIB - - download - build

The full PLIB source is available in many forms. You can download a recent archive, like plib-1.8.4.tar.gz, or you could use cvs, but this may cease soon, and is not being updated, being replaced with svn ... the command for the main development line (trunk) using svn is -

svn co plib

To do a subsequent update, the setroot.bat needs to be run, then changing into the folder plib, run -

C:\FGCVS\plib> svn update

Any changed files will be updated, and the current revision will be printed ...

At revision 2097


freeglut - - download - build

Stable releases can be be downloaded in a tar ball, or cvs can be used. The site - - give the anonymous cvs instructions for a full check out of the source. The site should be checked for the latest, but at this time the instructions are as follows, and remember to set the CVSROOT environment variable mentioned above -

When prompted for a password for anonymous, simply press the Enter key
cvs login
cvs -z3 co -P freeglut 

To do subsequent updates, the setroot.bat needs to be run, then changing into the 'freeglut' folder and run -

C:\FGCVS\freeglut> cvs up -dP

Each of the folders will be printed, as they are updated ...

C:\FGCVS\freeglut>cvs up -dP
cvs update: Updating .
cvs update: Updating freeglut
cvs update: Updating freeglut/doc
cvs update: Updating freeglut/freeglut-1.3
cvs update: Updating freeglut/freeglut-1.3/.deps
... and so on ...


pthreads - - download - build

This is not an 'essential' prerequisite. SimGear and FlightGear can be compiled WITHOUT this 'thread' library. I actually prefer 'without', but some feel they get some type of better performance this way ...

If desired, this can be downloaded with precompiled .DLL, .LIB, and the necessary header files in a ZIP, or it can be downloaded using cvs. Always check the site for the latest cvs instructions, but as of this date they were - remember to first run setroot.bat, to set the CVSHOME environment variable ...

{enter ``anoncvs'' for the password}
cvs -d login
cvs -d checkout pthreads

And for subsequent updates, after setting the CVSHOME environment variable, and changing into the 'pthreads' folder, run -

C:\FGCVS\pthreads> cvs up -dP

Each folder will be printed, as it is updated ...

C:\FGCVS\pthreads>cvs up -dP
cvs update: Updating .
cvs update: Updating manual
cvs update: Updating tests
cvs update: Updating tests/tmp

Some sources, like this are very stable, and are not 'changed' very frequently, but I usually do the updating as part of a batch process, so tend to do them ALL regardless ... Also by subscribing to the mailing lists, you can be aware of changes made ...


openal - - download - build

This is for 2D and 3D sound. It is effectively two separate items - openal and alut. And openal consists of a pair of DLL (shared) libraries ... As of July 2006, they added an OpenAL 1.1 installer for Windows, and a new OpenAL 1.1 SDK for Windows through - - but take care! While the windows installer might sound good, it 'permanently' installs the 3 DLL openal libraries, and will cause problems if you later want to compile and run FlightGear under the cygwin environment.

As usual, the source is available in tar.gz or zip format from the download page, for both openal and alut, or it can be all downloaded using svn. While you should always check the site for changes in the svn command, as of this date it was, remembering to set the CVSHOME environment variable -

svn checkout openal

And a subsequent update, after setting the CVSHOME environment variable, and changing into the openal folder, is -

C:\FGCVS\openal>svn up

This update each file/folder, and print out the revision, something like -

C:\FGCVS\openal>svn up
Fetching external item into 'OpenAL-Sample\common\specification'
External at revision 1410.
Fetching external item into 'OpenAL-Sample\common\include\AL'
External at revision 1410.
At revision 1410.

This source has been undergoing considerable change lately, but hopefully will settle down, but for the moment, fairly frequent updates are required


OSG - - download - build

Actually this download section also covers the perquisites of osg, namely OpenThreads and Producer.

This source is relatively NEW to me. As of this page creation date, the development branch of SimGear and FlightGear are switching to using OSG to replace some components of PLIB. PLIB is still required, for several other functions, like joystick, networking, etc, but the PLIB 'scene graph' is being replaced with this OSG ...

The download page offers a zip download of the source, windows binaries, stable version, nightly tar balls, and via cvs .. . Since this is fast being integrated into FG, the latest cvs source is not much use at this stage, but I chose to download and compile from it anyway - I learn better by making my own mistakes ;=)) ... as usual, you should check out the site for changed cvs instruction, but as of this date they were - (remember to set CVSHOME in the environment!) -

You can supply an empty password (just hit return).
cvs -d login
cvs -z 6 -d co OpenSceneGraph

And for the update, after setting CVSHOME, and changing into the folder OpenSceneGraph -

C:\FGCVS\OpenSceneGraph> cvs up -dP

As usual, each folder will print out as it is updated, like, in part -

... many lines chopped ...
cvs update: Updating include/osgWX
cvs update: Updating lib
cvs update: Updating lib/osgPlugins
cvs update: Updating src
cvs update: Updating src/Demos
cvs update: Updating src/Demos/cube
... etc, for many lines ...

At present, it seems some patches may have to be applied to this source to get it working with FG ... but I went ahead to try to compile and link it with SimGear/FlightGear anyway ... But this build attempt taught me that OSG also has two(2) prerequisites - OpenThreads and Producer ...


As always, check the osg site for updated cvs instructions, but at the time of writing they were -

You can supply an empty password (just hit return).
cvs -d login 
cvs -d co OpenThreads

As usual, after setting the CVSROOT in the environment, it can be updated by -

cvs up -dP


As always, check the osg site for updated cvs instructions, but at the time of writing they were -

You can supply an empty password (just hit return).
cvs -d login 
cvs -d co Producer

As usual, after setting the CVSROOT in the environment, it can be updated by -

cvs up -dP


But, as always, there is an ALTERNATIVE to using CVS. Next I tried the nightly tarballs ...

There is a site - - which, when you click on the 'Nightly CVS tarball' link leads you to - - which shows MANY separate tarballs - just listing the latest in each case - OpenSceneGraph-1.2.0-200610262325.tar.gz, Producer-1.1.0-200610262325.tar.gz, and OpenThreads-1.5.0-200610262325.tar.gz ...

I download these three - note, the  [Download] button does not seem to work in IE, but it can be downloaded by right mouse button clicking on the file, and selecting 'Save Target As...' from the context menu ... Just as a matter of interest, the [Download] buttons DO work in the FireFox browser ;=))

I unpack the above 3 tar.gz files (using WinZip), and copy them to simplified folder names in my main work folder, FG0910-5, using OpenSceneGraph, Producer and OpenThreads ... a compare of the CVS OpenSceneGraph with the tar.gz folder OpenSceneGraph-1.2.0-200610262325. As can be expected, about 14 of the tarball files were OLDER than the CVS, only 1 NEWER, and 4 NEW files, only in cvs ... I decide to use only all the files from the tarballs ...

I did succeed in finally linking FG using the libraries built form these, in the process switching from my preferred static library approach, to a shared library (DLL) approach. But FG was aborted by the OS, after trying to write to memory not belonging to it ...

Next I thought about using the last 'stable' version. For good measure, I downloaded (revision 2) md5sum e08e0ef1f250dfc17122926ef00b1559, which contains all the project source code and its main dependencies - OpenSceneGraph, Producer and OpenThreads ...

But Olaf/Mathias has also given a tarball of the modified version of this -
which I also download, and 'unpack' ... a compare of this with the above shows at least 3 source files have been modified - osg/LightModel.cpp, osgPlugins/ac3d/ac3d.cpp, osgPlugins/ac3d/Geode.cpp, and osgPlugins/rgb/ReadWriterRGB.cpp, plus a few other files ...

I also downloaded the multiple binaries produced by Olaf - - this contains some 522 files (154 MB). A long list of osg shared (DLL) libraries, and what seems to be their 'static' equivalent, and a very long list of what look like 'header' include files, without any extension? As well as OpenThreadsWin32.dll and Producer.dll, and other sundry DLLs and static libraries. At least it gives some guide as to what must be built ;=))


SimGear - - download - build

As usual, you can download a tar.gz file, like SimGear-0.3.10.tar.gz at this time, or do a check out via cvs. Always check the site for the latest instructions, in CVS Resources, but as of this date the cvs checkout, after setting CVSHOME, is -

CVS passwd: guest
cvs -d login
cvs -d co source

Note that this puts the source in a FOLDER called 'source', thus does not have the name 'simgear'. You may want to change this ;=/ In my case, I have renamed this folder to SimGear. And for subsequent updates, after setting CVSHOME, and changing into the 'source' folder, or whatever name you may have used -

C:\FGCVS\SimGear> cvs up -dP

This will update each file in each folder, printing out the names of changed files, and the folders as processed, something like -

C:\FGCVS\SimGear>cvs up -dP
cvs update: Updating .
cvs update: Updating projects
cvs update: Updating projects/VC8
cvs update: Updating simgear
cvs update: Updating simgear/bucket
... lot of lines omitted, ending ...
cvs update: Updating simgear/xml
cvs update: Updating src-libs

This package is an integral part of FlightGear, and should always be updated at the same time you update the FlightGear folder ...

4. Prerequisites Dependencies - building source libraries



I never directly use the download/update folders to build the product. There are several reason for this, but the main one is that when I get a fully functional working FlightGear, I do not want it 'changed' by an update until I have had a chance to quickly review what changes have taken place. If there is some doubt, this gives me the opportunity to 'save' what was working, before I overwrite the source files/data with updates.

Yes, some of this functionality can be done using cvs ... it is possible to checkout a previous 'version' for example ... but I have never learnt all the commands to do this, so I simply avoid it ;=))

We seem to be in a era when hard disks are LARGE and relatively cheap, so it is not uncommon for me to have many 'FG' full source folders ... some are where I have experimented with some changes of my own ... and at least one contains a recent working version so I can actually enjoy 'flying' in FlightGear without the difficulties that can sometimes come about in the building. And yes, there is no doubt, this in some ways defeats some of the purpose of cvs ... but hey, each to their own style ...

So, in this case I have created a second 'root' folder, called FG0910-5 - yes, this is the 5th such folder, related to the version 0.9.10 of FlightGear. Into this folder I copy each source, sometimes dropping some of the depth, sometimes removing the version numbers ... but all relative minor changes. It is in essence an XCOPY of the original download/updated folders.


Visual C++ 2005 Express has introduced a number of 'warnings' which I try to suppress. One of these is the 'depreciated' warning C4996 for things like strcpy, fopen, sprintf, _vsnprintf, strerror, strcat, ... etc. This warning can be suppressed by adding _CRT_SECURE_NO_DEPRECATE to Property Pages -> Configuration Properties -> Preprocessor -> Preprocessor Definitions ...

In addition, or sometimes as well, it is necessary to drop the pragma as follows into near the top of the source file -
#pragma warning( disable:4996 )

Runtime library:

From the Property Pages -> Configuration Properties -> C/C++ -> Code Generation -> Runtime library it can be seen there are five (5) choices for the Runtime library - Multi-threaded (/MT), Multi-threaded Debug (/MTd), Multi-threaded DLL (/MD), Multi-threaded Debug DLL (/MDd), and <inherit from parent or project default>. Excluding the <inherit ...>, one can see this is really only two(2), Multi-threaded (/MT) and Multi-threaded DLL (/MD), plus the 'Debug' configuration of each.

The difference is whether the code is drawn from 'static' libraries and embedded in the binary, /MT, or the code is 'imported' at runtime through shared libraries (DLL), /MD. I always choose the 'static' version, /MT, but it is probably possible to use either, BUT you MUST be consistent over all prerequisites, and the final FlightGear compile and link. Thus before you compile any project, it is usually VERY IMPORTANT to check and set this 'Runtime library'.

zlib - - build - download

While zlib does have MSVC solution files (sln/vcproj), I usually prefer to work with the original MSVC6 build file (dsw/dsp) ... quite frequently the 'solution' files will default to build a shared library (DLL), where possible, for FlightGear, I try to use 'static' libraries. Quite simply, this creates less dependency at runtime, at the cost of keeping all the code in one much larger runtime EXE (binary) ... Also the zlib project defaulted to Multi-threaded DLL (/MD), so I changed this the Multi-threaded (/MT), and /MTd for Debug configuration .

Also, like in this case, the converted 'zlib' solution contains 3 projects - example, minigzip and zlib, and many configurations - DLL ASM Debug/Release, DLL Debug/Release, LIB ASM Debug/Release, LIB Debug/Release - 8 configurations, I tend to 'unload' projects not needed, and 'skip' configuration not required. This latter is achieved by 'un-checking' the unwanted configurations in the 'Configuration Manager' ...

While there were a number of C4996 (depreciation) warnings, the build of Debug and Release ran fine, and I had two 'static' libraries -

Directory of C:\FG0910-5\zlib-1.2.3\projects\visualc6\Win32_LIB_Debug
02/11/2006 12:03 248,144 zlibd.lib
Directory of C:\FG0910-5\zlib-1.2.3\projects\visualc6\Win32_LIB_Release
02/11/2006 12:04 102,922 zlib.lib

The names, and relative paths of these two libraries must be remembered for later compiling and linking ...


PLIB - - build - download

Loading, and converting the plib.dsw shows 13 projects. While not all are required by SimGear/FlightGear most are, so it seems easier to build them all. Checking the Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime library show all 12 projects - the plib project is only the name that joins them all - they all seem to default to 'Multi-threaded (/MT)', and /MTd for Debug, but this should always be checked.

As with ALL DSW/DSP projects converted to SLN/VCPROJ files, it is necessary to add _CRT_SECURE_NO_DEPRECATE to Property Pages -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions unless you wish to see hundreds of the UGLY 'depreciation' warnings ... this is a BORING process to select each project, copy in the ';_CRT_SECURE_NO_DEPRECATE', change focus, click [Apply], change to the other 'Configuration' - Release or Debug - and repeat, and REPEAT this for 12 projects. One day I must write say a Perl script to perform this finger-clicking feat ;=)

While I generally ignore warnings, of course ERRORS must be fixed. One that has crept into PLIB is error C2440: cannot convert from 'const char *' to 'char *' ... this is usual easily fixed by add the correct cast. For example, netChat.cxx has the line -

 char* ptr = strstr(data,needle);

which generates this ERROR. In this case this can be 'fixed' by adding 'const' ...

 const char* ptr = strstr(data,needle);

It also occurs in several other places where a define exists for the Borland compiler, which obviously also has the 'problem'. In this case the lines -

#ifdef UL_BB

can be changed to

#if    (defined(UL_BB) || defined(UL_WIN32))

If I find the time, I should post this simple 'patch' to the PLIB mailing list ... there are a few other warnings, like C4800: forcing value to bool 'true' or 'false' (performance warning); some other C4996 which do not seem suppressed, all of  which I ignore ;=()

As part of the build process PLIB copy the static libraries to the root of its folder, this after the compile, I have the following list of libraries -

Directory of C:\FG0910-5\PLIB
02/11/2006 14:55     231,750 fnt.lib
02/11/2006 14:30     230,444 fnt_d.lib
02/11/2006 14:55      15,486 js.lib
02/11/2006 14:24     153,528 js_d.lib
02/11/2006 14:55      69,428 net.lib
02/11/2006 14:37     262,796 net_d.lib
02/11/2006 14:55     571,944 psl.lib
02/11/2006 14:24     630,840 psl_d.lib
02/11/2006 14:55   1,234,210 puAux.lib
02/11/2006 14:24   1,279,720 puAux_d.lib
02/11/2006 14:54   1,093,382 pui.lib
02/11/2006 14:24   1,117,954 pui_d.lib
02/11/2006 14:54      17,744 pw.lib
02/11/2006 14:23      54,342 pw_d.lib
02/11/2006 14:54     378,034 sg.lib
02/11/2006 14:23     399,786 sg_d.lib
02/11/2006 14:54     537,814 sl.lib
02/11/2006 14:23     499,118 sl_d.lib
02/11/2006 15:03   5,429,684 ssg.lib
02/11/2006 14:54   1,162,120 ssgAux.lib
02/11/2006 14:23   1,203,614 ssgAux_d.lib
02/11/2006 14:52   5,383,288 ssg_d.lib
02/11/2006 14:54     163,238 ul.lib
02/11/2006 14:23     164,496 ul_d.lib

Notice there is a pair of each, with the Debug version containing '_d'. Also all the required PLIB headers have been copied to this same PLIB root.


freeglut - - build - download

This is one case where I drop one of the folder names when the copy of the cvs download/update is made. Loading, and allowing the conversion of the freeglut.dsw to 'solution' files shows there are two projects, freeglut and freeglut_static. As usual I opt for the static, and disable the DLL build in the Configuration Manager. Checking the runtime, it seems to default to my chosen /MT and /MTd ... and if you want to avoid all the UGLY depreciation warnings, then add _CRT_SECURE_NO_DEPRECATE to Preprocessor Definitions ...

After the build, there were two static libraries, as follows -

Directory of C:\FG0910-5\freeglut\DebugStatic
02/11/2006 15:25   1,095,158  freeglut_static.lib
Directory of C:\FG0910-5\freeglut\ReleaseStatic
02/11/2006 15:22     502,146  freeglut_static.lib

The relative paths must be noted for later linking with FlightGear ...


openal - - build - download

As mentioned, openal is two(2) separate, but related projects, OpenAL and ALut ... Each must be build, and because they are shared libraries, later 'installed' to a place where they can be accessed by the FlightGear runtime EXE (binary).


After loading the OpenAL.dsw, although there is already an OpenAL.sln, it consists of four(4) projects, ALc, ALu, OpenAL32, and Router. In Windows, openal uses the DirectX layer to generate sound. Trying to compile ALc will abort with an error - missing dsound.h - unless you have also installed the Microsoft DirectX SDK ...

For some reason the coder of alc.cpp assumes we all have VISTA headers installed, with the code -

#ifndef __MINGW32__
#define _CRT_SECURE_NO_DEPRECATE // get rid of sprintf security warnings on VS2005

I had to comment out the #define HAVE_VISTA_HEADERS, since I do NOT have these installed, yet ;=))

And to compile the Router project, I had to add to Router Property Pages -> Configuration Properties -> C/C++ -> General -> Additional Include Directories -
C:\Program Files\Microsoft Platform SDK for Windows Server 2003 R2\Include\atl
to access the atlconv.h header file.

This gave me the 2x2 desired shared libraries (DLL) -

Directory of C:\FG0910-5\openal\OpenAL-Windows\OpenAL32\Debug
03/11/2006  11:58           696,320 wrap_oal.dll
Directory of C:\FG0910-5\openal\OpenAL-Windows\OpenAL32\Release
03/11/2006  11:53           188,416 wrap_oal.dll
Directory of C:\FG0910-5\openal\OpenAL-Windows\Router\Debug
03/11/2006  11:42           593,920 OpenAL32.dll
Directory of C:\FG0910-5\openal\OpenAL-Windows\Router\Release
03/11/2006  11:53           102,400 OpenAL32.dll

And their respective include libraries (LIB), plus some other static libraries, ALc and ALu -

Directory of C:\FG0910-5\openal\OpenAL-Windows\Alc\Debug
02/11/2006  18:56           140,686 ALc.lib
Directory of C:\FG0910-5\openal\OpenAL-Windows\Alc\Release
03/11/2006  11:52            49,616 ALc.lib
Directory of C:\FG0910-5\openal\OpenAL-Windows\Alu\Debug
02/11/2006  18:56            43,632 ALu.lib
Directory of C:\FG0910-5\openal\OpenAL-Windows\Alu\Release
03/11/2006  11:52            11,200 ALu.lib
Directory of C:\FG0910-5\openal\OpenAL-Windows\OpenAL32\Debug
03/11/2006  10:37            20,328 wrap_oal.lib
Directory of C:\FG0910-5\openal\OpenAL-Windows\OpenAL32\Release
03/11/2006  11:53            20,328 wrap_oal.lib
Directory of C:\FG0910-5\openal\OpenAL-Windows\Router\Debug
03/11/2006  11:42            20,004 OpenAL32.lib
Directory of C:\FG0910-5\openal\OpenAL-Windows\Router\Release
03/11/2006  11:53            20,004 OpenAL32.lib


Loading openal\alut\admin\VisualStudio6\alut.dsw,  despite the fact that there is a 'solution' file as well, shows three(3) projects - alut, hello_world, and playfile. I only want alut, at this time, so uncheck the others in the Configuration Manager ... also I change the Runtime Library to my preferred choice /MT-/MTd, although this is not so important for a DLL project. And of course, I add the inevitable _CRT_SECURE_NO_DEPRECATE to the preprocessor definitions to avoid the UGLY warnings ...

The first run at the build (F7) shows an error message in alutInternal.h where no data types are defined. But it has an #elif HAVE___INT8, so I add this define to alut Property Pages -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions ... simple ;=))

The next F7 shows it can not find alc.h ... the alut Property Pages -> Configuration Properties -> C/C++ -> General -> Additional Include Directories assumes I have installed the OpenAL SDK in C:\Program File\OpenAL 1.1 with EFX SDK\include, which I haven't! It is found in the folder openal/include/AL (and one other place), so I adjust this path to the relative path of '..\..\..\include\AL' but this also FAILS!

The reason is that alut.h includes alc.h via #include <alc.h>, under a _MSC_VER define, and not #include "alc.h" ;=() Since I KNOW alut.h will later also need to be included in SimGear and FlightGear some care should be taken in adjusting this. After trying various variations, I GIVE IN and supply an absolute path -

And finally, I supply an absolute path the OpenAl32.lib for the linker ("C:\FG0910-5\openal\OpenAL-Windows\Router\Release"). I do not particularly like this 'absolute path' approach, but do not have time to try more variations today ;=() This may bite me again when I get to SimGear and FlightGear ...

This gives me the paired DLL and LIB files -

Directory of C:\FG0910-5\openal\alut\admin\VisualStudio6\alut\Debug
03/11/2006  13:39           598,016 alut.dll
Directory of C:\FG0910-5\openal\alut\admin\VisualStudio6\alut\Release
03/11/2006  13:40           131,072 alut.dll
Directory of C:\FG0910-5\openal\alut\admin\VisualStudio6\alut\Debug
03/11/2006  13:39             5,922 alut.lib
Directory of C:\FG0910-5\openal\alut\admin\VisualStudio6\alut\Release
03/11/2006  13:40             5,922 alut.lib

Note, with DLL projects like these are, normally I will only use the Release configuration files, since it is hoped there should be no debugging of these shared libraries needed. I live in HOPE ;=))

The DLL files need to be copied to a place where the EXE loader can find them. Usually such DLL files can be copied to (a) the folder from which the EXE needing them is run, (b) to any PATH in the PATH environment variable, but last time I checked the openal code, OpenAL32.DLL searches for the wrap_oal.dll only in certain places ... as the comment in the current code, in ALc.cpp, states -

		// Directory[0] is the directory containing OpenAL32.dll
		// Directory[1] is the current directory.
		// Directory[2] is the current app directory
		// Directory[3] is the system directory

The last of these uses the function GetSystemDirectory(...), which on my system returns -
so this is where I copy the Release version of the shared library (DLL) files. Note, this will cause a 'conflict' with a cygwin build of FlightGear, so I have a batch file to copy them to this folder, and another to later delete them ...


OSG - - build - download

Wow, on loading VisualStudio/OpenSceneGraph.dsw, and allowing the conversion, one is presented with some 161 projects, one of which - Example osgsimple - FAILED to load! There are some - 5 'Application' = osgarchive, osgconv, osgdem, osgverion, and osgviewer; 12 'Core' = osg, osgDB, osgFX, osgGA, osgIntrospection, osgParticle, osgShadow, osgSim, osgTerrain, osgText, and osgUtil; 89 'Example', included the one that failed to load; 27 'osgPlugin'; and 10 'osgWrapper' ... Awk! What to include, exclude, or try to build all?

Of course, a trial build (F7) yields a missing file, in ../../include/osg/Referenced(29) : fatal error C1083: Cannot open include file: 'OpenThreads/ScopedLock': No such file or directory ... this portends of a prerequisite OpenThreads?


Loading and converting win32_src/OpenThreads.dsw shows it only has one project, with 2x2 configurations - Release/Debug for shared library (DLL), and Debug Static/Release Static for a 'static' library build. I check that the runtime library for the 'static' is /MT-/MTd, and build (F7). It builds quickly, and cleanly ;=))

I end up with two(2) static libraries -

Directory of C:\FG0910-5\OpenThreads\lib\win32
04/11/2006  14:12           547,990 OpenThreadsWin32d_s.lib
04/11/2006  14:14           192,372 OpenThreadsWin32_s.lib

These are now ready for a link ...

Subsequently, having problems linking with the 'static' libraries, I build all ;=))

Directory of C:\FG0910-5\OpenThreads\lib\win32
05/11/2006  14:33            22,842 OpenThreadsWin32.lib
05/11/2006  14:33            22,908 OpenThreadsWin32d.lib
04/11/2006  14:12           547,990 OpenThreadsWin32d_s.lib
04/11/2006  14:14           192,372 OpenThreadsWin32_s.lib
Directory of C:\FG0910-5\OpenThreads\bin\win32
05/11/2006  14:33            18,944 OpenThreadsWin32.dll
05/11/2006  14:33            90,112 OpenThreadsWin32d.dll



Despite the existence of 'solution' files, I load and convert the VC++6.0/Producer.dsw ... likewise this shows only one project, and 2x2 configurations -  Release/Debug for shared library (DLL), and Debug Static/Release Static for a 'static' library build. I check that the runtime library for the 'static' is /MT-/MTd, and build (F7) the Static Debug and Static Release ... again a relatively clean - only 3 warnings, ignored - and fast build (F7). This is going well ;=))

I end up with two(2) static libraries -

Directory of C:\FG0910-5\Producer\lib\win32
04/11/2006  14:26        13,803,400 Producerd_s.lib
04/11/2006  14:26         4,234,382 Producer_s.lib

These are now ready for a link ...

Subsequently, having problems linking with the 'static' libraries, I build all ;=))

Directory of C:\FG0910-5\Producer\bin\win32
05/11/2006  14:35           270,336 Producer.dll
05/11/2006  14:35           966,656 Producerd.dll
Directory of C:\FG0910-5\Producer\lib\win32
05/11/2006  14:35           253,124 Producer.lib
05/11/2006  14:35           253,784 Producerd.lib
04/11/2006  14:26        13,803,400 Producerd_s.lib
04/11/2006  14:26         4,234,382 Producer_s.lib



I load and convert VisualStudio/OpenSceneGraph.dsw. As expected, per the cvs, there are 161 projects, but 'Example osgsimple' failed to load. There are 2x2 configurations - Release/Debug for shared library (DLL), and Debug Static/Release Static for a 'static' library build. I check that the runtime library for the 'static' is /MT-/MTd, and build (F7) the Static Debug and Static Release ...

How fortuitous that I chose the folder I did for on checking Core osg Property Pages -> Configuration Properties -> C/C++ -> General -> Additional Include Directories I find it contains -

Although, as mentioned above, I have downloaded and unzipped the provided by Olaf, I do NOT move this into the relative path given above. I try a single compile of 'Core osg' - right click on this project, and select 'Build' ... and it compiles cleanly ;=)) things are looking up ... to try to 'discover' exactly what components are required, I decide to move onto SimGear build ...

I presently have two(2) osg static libraries ready -

Directory of C:\FG0910-5\OpenSceneGraph\lib\win32
04/11/2006  14:46       123,769,688 osgd_s.lib
04/11/2006  14:54        22,495,130 osg_s.lib

I will need much more than these, but for now I move onto SimGear and FlightGear, skipping pthreads for the moment ...

After compiling SG & FG below, I note, from the file OpenSceneGraph/include/osg/Export, that to use the 'static' version of OSG, OSG_LIBRARY_STATIC must be defined, or else OSG_EXPORT will be defined using __declspec(ddlexport), if OSG_LIBRARY, else __declspec(dllimport). What these do is generate a function with the __imp__ preamble, which is to be resolved using shared libraries (DLL) ... This means fully re-compiling SG & FG after adding this definition ... I note that Core osg Property Pages -> Configuration Properties -> C/C++ -> Preprocessor -> Preprocessor Definitions already has this defined, in -


Below is the code from the 'Export' file (with no extension!) ...

#if defined(_MSC_VER) || defined(__CYGWIN__) || defined(__MINGW32__) || defined( __BCPLUSPLUS__)  || defined( __MWERKS__)
    #  if defined( OSG_LIBRARY_STATIC )
    #    define OSG_EXPORT
    #  elif defined( OSG_LIBRARY )
    #    define OSG_EXPORT   __declspec(dllexport)
    #  else
    #    define OSG_EXPORT   __declspec(dllimport)
    #  endif
    #  define OSG_EXPORT

The FG link indicates that I must also build Core osgDB and Core osgUtil - I now have 6 static libraries built -

Directory of C:\FG0910-5\OpenSceneGraph\lib\win32
05/11/2006  11:55        35,444,676 osgDBd_s.lib
05/11/2006  11:54         5,012,542 osgDB_s.lib
04/11/2006  14:46       123,769,688 osgd_s.lib
05/11/2006  11:58        74,282,960 osgUtild_s.lib
05/11/2006  11:59        15,234,110 osgUtil_s.lib
04/11/2006  14:54        22,495,130 osg_s.lib

The first run of the Debug configuration of FlightGear indicated 'Warning: Could not find plugin to read objects from file "data/Aircraft/c172p/Models/"', so must build more of osg ... building the osgPlugin ac3d produced another static library pair -

Directory of C:\FG0910-5\OpenSceneGraph\lib\win32
05/11/2006  12:41         7,143,606 osgdb_acd_s.lib
05/11/2006  12:40         1,483,650 osgdb_ac_s.lib

But how to link this in? ... the FG link did not complain of anything missing ... is it sufficient to simply add this to the link? ... I try to read something about it on the OpenSceneGraph site ... Ha, ha - found what looked like a useful heading - Using the plugins - but the text is only a placeholder - 'Will go here' ;=(( But, as tracing through the FG coded showed, it seems to only search for a DLL - osgdb_ac.dll ... so can I build just that? ...

I set the configuration to 'Release' ... hoping there is not need to debug through DLL code ... Right clicking on the osgPlugin ac3d project, and selecting Build first build the 'Core osg' project, then build the project, osgPlugin ac3d, but get an error on the link - LINK : fatal error LNK1181: cannot open input file 'OpenThreadsWin32.lib' ... checking the osgPlugin ac3d Property Pages -> Linker -> General -> Additional Library Directories shows -


These relative paths will not work with my present folder arrangement, so I reduce it to -


and change the Input library name to OpenThreadsWin32_s.lib, my static library ... but then is can not find osgutil.lib, which is paired with osgutil.dll ... BAH!


BIG SWITCH-A-ROO! As Olaf had indicated some where, there seems a problem using the 'static' library approach ... so I SWITCH TO the DLL approach!!! First build the OpenThreads DLL, then the Producer DLL, then build the DLL version of projects 'Core osg', 'Core osgDB', 'Core osgUtil', and 'Plugin ac3d' ... I select these projects in the 'Batch Build' dialog, and click [ Build ] ... after undoing a few 'changes', and batch building again, I eventually end up with -

Directory of C:\FG0910-5\OpenSceneGraph\bin\win32
05/11/2006  15:31         1,249,280 osg.dll
05/11/2006  15:27         4,268,032 osgd.dll
05/11/2006  15:31           262,144 osgDB.dll
05/11/2006  15:28         1,048,576 osgDBd.dll
05/11/2006  15:32           106,496 osgdb_ac.dll
05/11/2006  15:29           425,984 osgdb_acd.dll
05/11/2006  15:31           700,416 osgUtil.dll
05/11/2006  15:29         3,751,936 osgUtild.dll

Directory of C:\FG0910-5\OpenSceneGraph\lib\win32
05/11/2006  15:31         1,704,672 osg.lib
05/11/2006  15:27         1,709,092 osgd.lib
05/11/2006  15:31           223,590 osgDB.lib
05/11/2006  15:28           224,098 osgDBd.lib
05/11/2006  11:55        35,444,676 osgDBd_s.lib
05/11/2006  12:41         7,143,606 osgdb_acd_s.lib
05/11/2006  12:40         1,483,650 osgdb_ac_s.lib
05/11/2006  11:54         5,012,542 osgDB_s.lib
04/11/2006  14:46       123,769,688 osgd_s.lib
05/11/2006  15:31           383,414 osgUtil.lib
05/11/2006  15:29           384,322 osgUtild.lib
05/11/2006  11:58        74,282,960 osgUtild_s.lib
05/11/2006  11:59        15,234,110 osgUtil_s.lib
05/11/2006  13:38        22,495,130 osg_s.lib

Getting more every day ;=))


Next OSG build: Mathias Froehlich had put an updated tar.gz on - - dated 8 Nov, 2006, which I download, and unzip ... It contains three(3) folders, OpenSceneGraph, OpenThreads and Producer ... I copy these folders into my work, C:/FG0910-5, and move out the 3rdParty folder that I had used for the last trial ... now, with a little more understanding of OSG, I decide to go back to trying to use the static libraries at least for the Core items. Of course the Plugins must stay as shared libraries (DLL) ...


I load and convert the win32_src/OpenThreads.dsw ... it is one project, with four (4) configurations - Debug, Debug Static, Release, and Release Static ... I check the two static are using runtime /MT and /MTd ... and build these two ... this produces 2 static libraries -

Directory of C:\FG0910-5\OpenThreads\lib\win32
09/11/2006  13:20           547,990 OpenThreadsWin32d_s.lib
09/11/2006  13:20           192,372 OpenThreadsWin32_s.lib

These are now ready for the link ... but later built ALL ... getting -

Directory of C:\FG0910-5\OpenThreads\bin\win32
09/11/2006  14:38            18,944 OpenThreadsWin32.dll
09/11/2006  14:38            90,112 OpenThreadsWin32d.dll
Directory of C:\FG0910-5\OpenThreads\lib\win32
09/11/2006  14:38            22,842 OpenThreadsWin32.lib
09/11/2006  14:38            22,908 OpenThreadsWin32d.lib
09/11/2006  13:20           547,990 OpenThreadsWin32d_s.lib
09/11/2006  13:20           192,372 OpenThreadsWin32_s.lib


I load and convert the VC++7/Producer.sln ... likewise this is one project with four (4) configurations - 2 x DLL and 2 x static ... I check the runtime for the static is /MT and /MTd respectively ... and build these two (2) ... there 3 warnings, which I ignore ... this produces 2 static libraries -

Directory of C:\FG0910-5\Producer\lib\win32
09/11/2006  13:29        13,802,900 Producerd_s.lib
09/11/2006  13:29         4,234,344 Producer_s.lib

These are now ready for the link ... but later built ALL ... getting -

Directory of C:\FG0910-5\Producer\bin\win32
09/11/2006  14:39           270,336 Producer.dll
09/11/2006  14:39           749,568 Producerd.dll
Directory of C:\FG0910-5\Producer\lib\win32
09/11/2006  14:39           252,852 Producer.lib
09/11/2006  14:39           253,512 Producerd.lib
09/11/2006  13:29        13,802,900 Producerd_s.lib
09/11/2006  13:29         4,234,344 Producer_s.lib


I load and convert the VisualStudio/OpenSceneGraph.dsw ... as before, some projects - osgWrappers/osgParticle/wrapper_osgParticle.dsp, osgWrappers/osgProducer/wrapper_osgProducer.dsp - fail to open ... there are some 149 projects ... of those I checked, each appears to have the four (4) configurations - 2 X DLL and 2 X static ... Debug and Release ... I build only Core osg, Core osgDB, Core osgUtil as static libraries (LIB), and osgPlugin ac3d as shared libraries (DLL/LIB) ... the first batch build fails on some so I go back and do them 1 by 1 ... but this trying to mix static and shared FAILS ...

I next try a build ALL ... but must also build ALL of OpenThreads and Producer first ... and in returning to OpenSceneGraph, I am able to fix the two failed project loads by removing the trailing '0000644' from these two DSP files ... this is a BIG LONG build, over 1-2 hours, and during the batch building of ALL, certain projects FAILED, usually due to a missing header. Over 3200 object (OBJ) files,  119 library (LIB), 114 shared libraries (DLL), and 160 executables (EXE) were created. It failed on, like -

gdal_priv.h - GDAL - - Geospatial Data Abstraction Library - This was one of those cases where downloading gdal-1.3.2.tar.gz got written to disk as gdal-1.3.2.tar.tar, which WinZip baulks on ... renaming it fixes the problem, or there is a ... this contains the missing gdal_priv.h, and others ... but building GDAL also look like it requires OGR - - and maybe other prerequsites, so I forget this for now ...

Others missing, and possible source locations, were tiffio.h ( ), jpeglib.h ( ), ft2build.h ( ), gif_lib.h ( ), png.h ( ), even GL/glut.h ... for the moment I left these projects un-completed - 

Core osgTerrain - include file: 'gdal_priv.h'
osgPlugin tiff – include file: 'tiffio.h'
osgPlugin png - 'zlib.h', ‘png.h’, libpng.lib
osgPlugin jpeg – include file: 'jpeglib.h', and lib ... 
osgPlugin gif - include file: 'gif_lib.h'
osgPlugin gdal - include file: 'gdal_priv.h'
osgPlugin freetype - include file: 'ft2build.h'
Example osgsimulation - input file 'gdal_i.lib'
Example osgGLUTsimple - include file: 'GL/glut.h'
Application osgdem - input file 'gdal_i.lib'
osgWrapper osgTerrain - include file: 'gdal_priv.h'
Build: 0 succeeded, 38 failed, 372 up-to-date, 0 skipped

While it is possible to supply the missing headers in some cases, usually it still fails on the link - missing input library! But this should give me enough to compile SG and FG OSG ;=)) Back to FG ...


SimGear - - build - download

After making the copy of the cvs download, I load and convert SimGear.dsw, despite there also being a 'solution' build file ... this DSW/DSP build set may not be fully up-to-date. There is a development tool to automatically update this DSW/DSP build set using the contents of the files, but this is not done very regularly. When compile or link errors are found, it is sometimes necessary to check the file, to see exactly what has been recently include or excluded.

Here there is only one(1) project, with two(2) configurations - Debug and Release. A check of the SimGear Property Pages -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library shows it is set to /MT - /MTd as desired, but the -> General -> Additional Include Directories presently shows -
.,..,.\SimGear,..\zlib-1.2.3,..\OpenAL 1.0 Software Development Kit\include
which will need to be fixed to fit my relative folders ...

Also, while there is a custom step to copy simgear/simgear_config.h.vc5 to simgear_config.h, this custom step does not always seem to work, so I do a manual copy ... and I note the Preprocessor Definitions is -
which looks fine. I was particularly looking for ENABLE_THREADS, but it seems Lib_sgthreads is not included by default.

I subsequently find I have to add NOMINMAX to this list. This is defined in simgear_config.h, but I guess not every file included this header ...

My 'method' to get the 'Additional Include Directories' correct, is to try to compile one file, say Lib_sgbucket/newbucket.cxx, by right clicking while hover over this file name in the Solution Explorer, and choosing 'Compile' and see what is missing. Often, just hitting F7 causes a runaway large listing of errors. Ok, got a fatal error C1083: Cannot open include file: 'osg/Vec3f' ... then I do a search for 'Vec3f' in my root folder, in my case FG0910-5 ...

This shows me -

Directory of C:\FG0910-5\OpenSceneGraph\include\osg
18/07/2006  17:21             6,674 Vec3f

Now I know I need a relative path ..\OpenSceneGraph\include ...

Trying Lib_sgmodel/animation.cxx shows a missing 'OpenThreads/ScopedLock', and adding the relative path ..\OpenThreads\include fixes that ... compiling simgear/sound/soundmgr_openal.cxx shows a missing 'AL/al.h', which ..\openal\include fixes; and a missing 'AL/alut.h', which ..\openal\alut\include fixes; 'alc.h' by ..\openal\include\AL ... a few individual compiles like this eventually establishes a complete 'include' string. In my case this was -


After compiling and linking both the Debug and Release configurations, I have the following static libraries ready for the final FlightGear link -

Directory of C:\FG0910-5\SimGear\Debug
04/11/2006  17:22        39,191,590 SimGear.lib
 Directory of C:\FG0910-5\SimGear\Release
04/11/2006  17:31        13,942,068 SimGear.lib

Although I deleted some files which seem no longer to be part of the osg version of SimGear, there may be other modules to be added ... on attempting to compile FlightGear found I needed to do a cvs update 4 Nov 1006, and recompile ...

Directory of C:\FG0910-5\SimGear\Debug
04/11/2006  21:39        39,204,650 SimGear.lib
Directory of C:\FG0910-5\SimGear\Release
04/11/2006  21:36        13,942,068 SimGear.lib

After trying a FG compile and link, I note two defines are missing - OSG_LIBRARY_STATIC and FREEGLUT_STATIC ... so another full compile ... quite frequently, this type of mess pushes developers to use the shared library (DLL) approach, but where at all possible I try to stick to using 'static' libraries.

Added persparam.cxx to mix -

Directory of C:\FG0910-5\SimGear\Debug
05/11/2006  11:45        41,042,012 SimGear.lib
Directory of C:\FG0910-5\SimGear\Release
05/11/2006  11:44        14,459,646 SimGear.lib

Must be getting close ... this succeeds in getting FG to link ...


BUT on running FG, it aborts due to a missing osg Plugin ac3d . Eventually I decide to abandon the static library approach for osg, build the DLLs, and must re-build SimGear to suit, now removing the newly added OSG_LIBRARY_STATIC define ... now the build is working fine, I begin using the 'Batch Build' mode, and can thus time the complete re-build of both Debug and Release configurations - approx. 3 minutes ... and note there are 27 warnings remaining ;=))

Directory of C:\FG0910-5\SimGear\Debug
05/11/2006  15:57        39,760,222 SimGear.lib
Directory of C:\FG0910-5\SimGear\Release
05/11/2006  15:58        14,047,578 SimGear.lib

Then back to FG ...


This is a re-compile of SimGear against the '3rdParty' folder from Olaf's zip ... having (temporarily perhaps) moved out the folders OpenSceneGraph, OpenThreads and Producer, I have to remove the 'Additional Include Directories' - ;..\OpenSceneGraph\include;..\OpenThreads\include - and replace them with - ../3rdParty/include ...

Never satisfied, I decide to ALSO try out my script, thus copy and modify am2dsp.cfg to am2dsp6.cfg ... people always say something like 'be wary of many many changes at one time', but I seldom listen ;=)) hmm, there is a small bug in - it included 2 items from simgear/xml/, that are listed an noinst_HEADERS, which are actually NOT headers - xmltok_impl.c and xmltok_ns.c ... AND I had forgotten to apply the diff from Olaf's site, to SGQuat.hxx and SGDebugDrawCallback.hxx ... I applied these manually ... and I note it lists the include directories with a comma separator, which MSVC8 accepts, but says 'use semi-colon delimited list' - this seems to be done during the MSVC6 -> MSVC8 conversion, so who am I to argue with Microsoft!  ... At my peril I ignore the suggestion to use /MD instead of /MT ;=() ...

Behold, 3 minutes later I have new SimGear libraries, ready to roll ;=)) albeit with still around 27 warnings, which I ignore ...

Directory of C:\FG0910-5\SimGear\Debug
06/11/2006  18:28        39,539,850 SimGear.lib
Directory of C:\FG0910-5\SimGear\Release
06/11/2006  18:30        14,043,870 SimGear.lib

Then back to FG ...


As a check I next back peddled, and decided to build the PLIB version. Having created a folder sgpreosg, I copied in the current cvs update, set CVSHOME in the environment, and used the command -

cvs up -rPRE_OSG_PLIB_20061029

to update this folder to PRE-OSG ... then I use my 'fixed' to generate new DSW/DSP build files, with a few minor adjustments in the am2dsp7.cfg I created. Loading this in MSVC8, I built two new static libraries -

Directory of C:\FG0910-5\sgpreosg\Debug
07/11/2006  15:51        33,841,210 SimGear.lib
Directory of C:\FG0910-5\sgpreosg\Release
07/11/2006  15:53        13,156,370 SimGear.lib

Then back to FG ...

But after this build, which FLIES, I head back to OSG, rebuilding ALL in there, then pointing SimGear to the OSG folders, rebuild SimGear static libraries ...

Directory of C:\FG0910-5\SimGear\Debug
09/11/2006  18:41        39,554,894 SimGear.lib
Directory of C:\FG0910-5\SimGear\Release
09/11/2006  18:38        14,043,870 SimGear.lib

Then back to FG ...


5. FlightGear - - download build

FlightGear is essentially made up of two(2) sources. First the C++ source, to build the runtime executable (binary) file, but equally important is the 'data' source, which include many components necessary for FlightGear to run. As usual, there are several ways to download both these components, but here I am using cvs.

First I create a FlightGear folder, in my C:\FGCVS root, and set the CVSHOME environment variable, then changing into this FlightGear folder, run the following. Always check out the latest instructions on - - but as of this date they were -

Source code:
CVS passwd: guest
cvs -d login
cvs -d co source
Data (base package)
CVS passwd: guest
cvs -d login
cvs -d co data

Note, since they are in the same repository, you only need to do the 'login' once. This will create two new folders, 'source' and 'data', filled with files ... depending on your internet connection speed, the source should be quite quick, but there are a large number of files in the 'data' directory, and this is only the BASE PACKAGE. The source folder will have in the order of 1,558 files, about 9.3 MB, while the data folder will contain around 13,387 files, about 581.8 MB ...

In the base package only the scenery for San Francisco is included - that is w130n30 - in the data/Scenery, terrain and Objects folders. If you want more, and other areas, then you can download these either using a http interactive world map, the Graphical interface from - - or using direct ftp downloading - - and choosing which 10x10 degree block you want ... or you can use this FTP address in you favourite ftp client software - I use FileZilla for this ...

Also, during the compile of SimGear and FlightGear you can choose to add in the 'terrasync' option. This utility runs in the background and monitors your flight location, and proceeds to do download (or update) the latest scenery from the master scenery server ... a "just in time" scenery model ...

Jon Stockill maintains a database of scenery objects - - and some additional aircraft are available from - - of course there is more details information available from the main FlightGear site - -

After setting CVSHOME in the environment, and entering the 'source' folder, the following will update the source -

C:\FGCVS\FlightGear\source>cvs up -dP

This will output many line, something like -

C:\FGCVS\FlightGear\source>cvs up -dP
cvs update: Updating .
cvs update: Updating docs-mini
cvs update: Updating examples
cvs update: Updating examples/netfdm
cvs update: Updating man
... many line omitted ...
cvs update: Updating utils/gui
cvs update: Updating utils/js_server
cvs update: Updating utils/metarproxy
cvs update: Updating utils/xmlgrep

And likewise the data folder can be updated with -

C:\FGCVS\FlightGear\data>cvs up -dP

which will output MANY lines, ending something like -

C:\FGCVS\FlightGear\data>cvs up -dP
... many lines omitted ...
cvs update: Updating Weather
cvs update: Updating gui
cvs update: Updating gui/dialogs
cvs update: Updating gui/styles
cvs update: Updating man

Subscribing to at least the cvs-log and developer mailing lists will alert you to when this needs to be updated, but in simple terms it should be done at a minimum of once a week to stay current ;=)) The last FG update was 4 Nov 2006.


6. FlightGear - - build download

Phew - lots of steps, some quite big, to get to this stage ... again I use the FlightGear.dsw file, but I have an advantage in that quite some time ago I downloaded and modified the module. It reads the current set, and builds a new FlightGear.dsp using the files found. Usually the original module can be found in cvs at - - the configuration file, am2dsp.cfg is part of the cvs source download ...

My modified version is here ... you need to copy the am2dsp.cfg to am2dsp6.cfg ... this may take some work to set up, but once done, you can always generate the latest DSP build file, directly from the source download ... as part of the modification, I removed the many folders created by the current, and present the FlightGear project as a single list of source file. The Perl script is quite MESSY, since I originally had the idea of also 'modifying' the MSVC8 solutions file as well, but I abandoned this before full completion ... praise me if it works, but do not blame me if it fails ;=))

As with SimGear, there is/was a custom build step to copy the src/Include/config.h-msvc6 to config.h, but over time the config.h-msvc6 file got changed to, and anyway, the custom step did not always seem to work, so like SimGear I do this copying manually ... there is also a 'completing' file config.h-msvc8 in the include folder, which enables thread by default. Also, after the copy, you should amend around line 49 to reflect the current version - here I use '0.9.10 OSG' in place of the word '@VERSION@' ... but unless you also modify the source, you will never see this string output ...

As with SimGear, the FlightGear Property Pages -> Configuration Properties -> C/C++ -> General -> Additional Include Directories has to be adjust to suit you relative source and folder arrangements ... and as always, the runtime library should be checked, and set to /MTd - /MT ... again, like SimGear, I usually start by compiling only one file at a time, adjusting the 'paths' until all headers are found ...

OOPS, got STUCK on locating SGQuatd::fromRotateTo( dir, 0, up, 2 ); in viewer.cxx ...but that just turned out to be a need to update SimGear ... it has only been 4 days, but this can happen with a 'new' feature like osg ... now both SimGear and FlightGear are updated to 5 Nov 2006.

Finally the link ;=)) At present FlightGear Property Pages -> Configuration Properties -> Linker -> Input -> Additional Dependencies only contains ws2_32.lib. There are lots of 'standard' libraries included, which are not shown. Some libraries are included through a pragma in their header file, but others must be listed here, and Linker -> General -> Additional Library Dependencies must contain a 'path' to find the library.

The first error - LINK : fatal error LNK1104: cannot open file 'freeglut.lib', indicates that I have included a freeglut header without defining FREEGLUT_STATIC in the Preprocessor Definitions ... of course adding this causes the whole FG to be recompiled ... this take its time ... by not adding the relative path at this time I can check that it is searching for freeglut_static.lib ... the pragma that causes the 'automatic' library inclusion is -
#pragma comment( lib, "freeglut_static.lib")
which is this case can be found in freeglut/include/GL/freeglut_std.h ...

Now I get the error I want to see - LINK : fatal error LNK1104: cannot open file 'freeglut_static.lib' ... now all I need to do for this is add the relative path ../freeglut/DebugStatic ...if you want to be clever and use the same relative path for Debug and Release configurations, then you can make this ..\freeglut\$(IntDir)Static ... and we move on to the next link error ...

This time MSVC8 lists some 5142 errors, representing some 1116 unresolved externals. Unresolved externals are sometimes difficult to track down, and sometimes easy ... using a search on the root folder, C:\FG0810-5 will show where the function is declared, but then you must work out which library it is in in multiple projects like PLIB ... the fact that MSVC8 also searches the BuildLog.htm, you get multiple useless hit from it. It is possible to eliminate this file, by expanding the Find Options, and selecting the appropriate 'Look at these file types:', a string which can also be edited ...

Ok, it is declared in PLIB/sg.h, and later the actual code in PLIB/src/sg/sgd.cxx, but which PLIB static library is it linked into? Reopening the PLIB.sln, shows this source in the 'sg' project, and checking the sg Property Pages -> Configuration Property -> Librarian -> General -> Output File shows this as Debug/sg_d.lib for Debug, and Release/sg.lib for Release. Adding this library, and a path, ../PLIB, removes this item ... the errors are reduced to some 4933, 1108 unresolved externals.

Be warned, sometimes the inclusion of a library can actually INCREASE the errors and unresolved externals ... this can be the case when you include SimGear.lib, and a path to it, ..\SimGear\$(IntDir), for example, because that library will have a large number of unresolved external also ... but in this case, after adding SimGear the errors fell to 3936, with 998 unresolved externals. Adding zlibd.lib for debug, and zlib.lib for release, and the path, ..\zlib.2.3\projects\visualc6\Win32_Lib_$(Intdir) and errors become 3612, 990 unresolved ... and I can see most start with osg::...

Time to learn something more about osg ... at this stage I have only build the Core osg library, osgd_s.lib, on path ../OpenSceneGraph/lib/win32 ... after adding this I am down to 767 errors, 403 unresolved externals ... I note netSocket in the list, which I find in PLIB netd_lib, so add this ... and alDopplerVelocit, actually listed as __imp__alDopplerVelocity indicating that it is in a shared library (DLL), so add OpenAl32.lib, on path ..\openal\OpenAL-Windows\Router\Debug ... and __imp__alutGetError, so add alut.lib, on path ..\openal\alut\admin\VisualStudio6\alut\Debug ... then only 666 errors, 346 unresolved externals ;=))

I find ulStrDup in PLIB ul_d.lib, the path already done, and add the OpenThreadsWin32d_s.lib, with path ..\OpenThreads\lib\win32, and get 611/336 ...

I find 2 new SimGear files, SGStateAttributeVisitor.cxx and SGTextureStateAttributeVisitior.cxx ... so add these to the SimGear library ... 610/327, and many of the remaining are osg::... items, like osg::BlendFunc::BlendFunc,  osg::Group::Group/~Group, osg::Switch::Switch/~Switch, osg::Referenced::ref/unref, osg::NodeVisitor::... etc ... so it seems time to revisit the osg build for these ... but that is to be on another day ...

Since some of these are in 'Core osg', which I am including in the link, I look for another problem. Ah, I had forgotten to defined OSG_LIBRARY_STATIC - recompiling with this define reduced the link to 372 errors, 177 unresolved externals ;=)) marvellous what a new day brings ... and adding pui_d.lib drops this to just 67/66 ... we're really zinging ;=)) added puAux_d.lib, and down to 48/47 ... added fnt_d.lib, and now 38/37 ... js_d.lib - 35/34 ... added persparam.cxx to SimGear - 34/33 ...

Most of the balance seem to be osg, like osgUtil::SceneView::setSceneData, osg::Image, osgDB::readImageFile ... so back to find these in osg ... and thus add osgDBd_s.lib and osgUtild_s.lib to the link. Osg is putting all these in the same folder, so the path is already there ... AND AM REWARDED WITH -
1>FlightGear - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

That is the Debug configuration done ... now to cvs update the data to today, 5 Nov 2006, and let it fly ;=)) of course, I make a xcopy of the data to C:\FG0910-5\data - the BEAUTY of having massive hard disk capacity ;=)) The debug version takes ages to load, and is slower running, but let's see ...

OOPS, exit with error -

C:\FG0910-5>C:\FG0910-5\FlightGear\Debug\FlightGear.exe --fg-root=data
Warning: Could not find plugin to read objects from file "data/Aircraft/c172p/Models/".
Failed to load aircraft from Aircraft/c172p/Models/c172p.xml
(Falling back to
Warning: Could not find plugin to read objects from file "data/Models/Geometry/".
Fatal error: Failed to load 3D model
 at data/Models/Geometry/

Now, how to add a plugin??? There is an osgPlugin ac3d project in osg ... I try running it under the MSVC8 debugger, and set a breakpoint in acmodel.cxx, when it calls osg to load the model ... WOWEE! Tracing through the code, osg ONLY searches for a shared library (DLL) osgdb_ac.dll ... back to osg to try to build that ... but have some trouble, so ...


THE BIG SWITCH-A-ROO! As noted in OpenThreads, Producer and OpenSceneGraph I switch these over to using the shared libraries (DLL) ... this means recompiling SimGear and FlightGear once again, removing the OSG_LIBRARY_STATIC ... and adjusting the osg libraries to their DLL names, and I am ready to FLY again ... the build took some 10 minutes for the Debug configuration - but the last minute or so was creating the browse information - I may turn this off, since I have seldom found 'browsing' helpful, or offering little more than can be achieved using the search function ... there are a massive number of warnings - some 289, including some 24 from the linker, which I choose to IGNORE ;=()

But before I FLY again I must give consideration to installing the osg DLL files ... just as a test, I try, but get the dialog - Unable To Locate Component - osg.dll was not found ... as with the OpenAL DLLs I choose to build a batch file to copy the DLLs to C:\WINDOWS\systems32, and have a switch, D, to be able to delete them again ...

The set of DLL I 'install' is - osg.dll, osgDB.dll, osgdb_ac.dll, osgUtil.dll, OpenThreads.dll and Producer.dll. As is my habit, I only install the Release versions of the DLLs, unless I really need to debug into the shared library code  ...

ZUTE! An OS abort ... of course, I choose NOT to send a report the Microsoft ... but I have no console output ... so in main.cxx I alter the code to -

    // set default log levels
    // sglog().setLogLevels( SG_ALL, SG_ALERT );
    sglog().setLogLevels( SG_ALL, SG_DEBUG );

Yes, this can be done from the command line, but the command line parsing is a little later, and I want to see the messages from the beginning ... And also take the opportunity to turn off the generation of 'browse' information, which causes another full Debug configuration build, but it is just less than 10 minutes, just for one(1) configuration ....

The full console output up until the OS aborted the application is given below, but the abort was soon after the output - 'Initializing scenery subsystem' ... Now to try to trace into here, and discover more about this abort ... it is in sgLoad3DModel() ... the full stack trace is given below. I may need the Debug DLLs to trace fully into this. The instruction is add eax, dword ptr [edx+ecx*4], but  CPU registers show ECX = BAADF00D EDX = 00000000 ...

THE ECX VALUE BAADF00D LOOKS LIKE AN UN-INITIALIZED VARIABLE, deliberately filled with a DEBUG value ... carefully setting the next statement, and getting back to the code, the line of code is -

 osgDB::FilePathList pathlist = osgDB::getDataFilePathList();

which calls std::deque(...) ... about line 532 of model.cxx ... the path looks ok as "Aircraft/c172p/Models/c172p.xml" ... and likewise the modelpath {data/Aircraft/c172p/Models/} ...

But another days is nearly over so this seems a good time to shutdown for tonight ... SAD, but no FLYING tonight ;=))

Time to call in the troops! ;=))

Perhaps the next quickest route would be to compile SimGear and FlightGear against the 'include' files from Olaf's ... this would at least test if FlightGear will run in my new machine ... how to do this? I had already unzipped it, of course using folder names, and it creates a folder '3rdParty' ... so I move this folder into my chosen root directory, C:/FG0910-5, and move out the existing OpenSceneGraph, OpenThreads and Producer folders ... this is just an extra precaution to NOT have these available for the re-compile, first of SimGear, then FlightGear ...

As with SimGear, I remove ;..\OpenSceneGraph\include;..\OpenThreads\include and add ..\3rdParty\include to the Additional Include Directories ... and adjust the library path to ..\3rdParty\lib for the link ... in cases like this I also do a 'Clean' before starting the build ... 10 minutes later I have a new executable -

Directory of C:\FG0910-5\FlightGear\Debug
06/11/2006  18:54        12,083,200 FlightGear.exe

Now to FLY it ;=)) but before this I must decide how to 'install' the DLLs in 3rdParty/bin ... I make sure I delete my earlier efforts from C:/WINDOWS/system32 ... I do NOT want to copy these 132 DLLs to my system folder ... I decide to try out the knowledge that DLLs can be available in the folder of the EXE, or in any folder in the PATH environment variable ...

Copying the EXE to this 'bin' folder is quick and easy, so I decide to try this first ... as usual with the Debug version, it takes AGES to load the airport and navigation data, especially when waiting with baited breath ;=)) ... BUT ALAS, I STILL GET THE DREADED OS DIALOG ;=(( - 'FlightGear.exe has encountered a problem and needs to close' ... why do Microsoft deem it necessary to add 'We are sorry for the inconvenience' ;=/ Needless to say, I do not click [ Send Error Report ] ... the console output is the same as, similar to last time, ending on the line 'Initializing scenery subsystem' ...

Alas, another day has been eaten up, so again NO FLYING ;=))

But where to go next? I could go BACKWARDS ;=((  To get the PRE OSG cvs, of both FG and SG, and maybe the 'data', the following cvs command will update the respective folders with the code prior the cut over to using OSG -

cvs up -rPRE_OSG_PLIB_20061029

I create 3 new folders - sgpreosg, fgpreosg, and datapreosg ... copy in the latest csv updates, and apply the above 'sticky' tag to these 3 folders ... not sure exactly what 'sticky' means here ... use my 'fixed' script to generate new DSW/DSP build files for SG and FG ... load MSVC8, first with SG, and build - no problems ;=)) load FG, and build - no problems ;=)) Then run my new PRE OSG EXE - AND IT FLIES, WITH SOUND ;=))

The console output was small -

C:\FG0910-5\fgpreosg\Debug>FlightGear --fg-root=..\..\datapreosg
Created a 256x256 RenderTexture with BPP(8,8,8,8)
  Model Author:  Unknown
  Creation Date: 2002-01-01
  Version:       $Id: c172p.xml,v 1.17 2006-03-13 15:27:14 ehofman Exp $
  Description:   Cessna C-172
altitude         = -1.12977
sea level radius = 2.08996e+007
latitude         = 0.653236
longitude        = -2.13554
Initializing Nasal Electrical System

.One wonders why there is any output at all. The default SG_LOG flag is SG_ALERT ... why are these messages alone output under the 'alert' flag? But who cares about that -


My new Logitech joystick, EXTREME 3D PRO worked immediately, and the sound seems better than before ... as I did a tight 500 foot circuit in the C-172, I noted for the first time variation in the propeller/engine sound as I pulled up - FANTASTIC STUFF ... bringing up the HUD (H), and switching the mini-HUD, I can see the frame rate is NOT fantastic at 20-27 fps - this IS the Debug configuration, in full screen mode, 1280 x 1024, on my 19" Dell flat screen - but quite respectable, and flyable ;=))

It takes me some time to remember the F8 key clears the FOG ... I do not like the fog, but I guess it makes the scene more realistic ... and then to remember F3 write the screen to a rather large ppm file (2.1 MB) ... This is a screen shot, a few thousand feet over San Francisco, with the Golden Gate bridge in the back ground, reduced to a 40 KB file (using MS Word export html function) ...

In Cessna, over SF, looking towards bridge ...

Another day has flittered by, but at least I have had some FLYING today ;=)) Another day, must get back to building FlightGear with OSG ... this build, back with full PLIB at least shows me that FG can run in my new machine. I should also take the time to build the Release version, just to see what the frame rate will be, as a comparison when I eventually get the OSG version running ...

So, first to build the Release version in fgpreosg ... although my new does a good job, another part of it I have not yet completed is being able separate the debug and release include libraries and paths, so I have to manually adjust this for now ... AWK: I got the warning LNK4098: defaultlib 'LIBCMT' conflicts with other libs; ... which can sometimes lead to a ERROR - LNK1169: one or more multiply defined symbols, which I got ...

But WHICH library causes this? - I thought I had built them ALL with /MT ... I do not get this with the Debug, so it means loading each prerequisite and checking - BAH! ... a quick search can be done checking the 'RuntimeLibrary' variable in each vcproj file used is either "1" (Debug /MTd) or "0" (Release /MT) ... but in multiple projects and configurations like say zlib is, then this is not so easy to see ...

This is not so important for DLL creation, since DLL code is only dynamically linked at runtime, thus will cause no conflict in the final EXE link, with other static libraries ... the values for /MD and /MDd are "2" and "3" respectively. And I am not concerned about projects other than the static library I want ... so there seems no other solution but to load 1 by 1, and check ... zlib - ok, PLIB - ok, freeglut - ok, simgear - ok - that only leaves openal and alut, but these are through DLLs ...

Maybe it does make a difference, even with DLLs? But even checking OpenAL and ALut, I have set them all to /MT-/MTd - SO WHY DO I GET THIS ERROR??? YUCK! It seems I had set the Release configuration of FlightGear to /MTd, the debug runtime - It is good to know this error can also show up my mixing /MT and /MTd ...

Now I have two PRE OSG FlightGear runtime EXE files -

Directory of C:\FG0910-5\fgpreosg\Debug
08/11/2006  14:32        12,607,488 FlightGear.exe
Directory of C:\FG0910-5\fgpreosg\Release
08/11/2006  15:29         4,538,368 FlightGear.exe

Note the Debug is some 3 times the size of the Release ... Now to see if it FLIES also ... the start up time is immensely shorter, and I have a frame rate, sitting on the runway, of over 50 fps ;=)) I take the C172 for a quick spin, in the DARK ... checking my world clock confirms it is night in SF ... This is a screen shot lined up, in the dark ...

On runway, in Cessna, at night

During the short flight I did, I saw frame rates over 150 fps ;=)) Unfortunately I crash on landing, and after a show of a tumbling plane, I got the dreaded OS abort dialog ... but as stated, this was after a CRASH ... I had flown around for about 10-15 minutes without any big problems ... at times my joystick would not give me full up elevation, but again this is perhaps something to do with my elevator trimming attempts ...

This will be a good comparison for testing when I get the OSG version compiled and running ... My wife want us to do some shopping today, so this is a very SHORT computer day ;=(( but it included some FLYING, so not too bad ...

Where to next? Mathias Froehlich has placed a new tar.gz at - - from here I downloaded two(2) files, both dated 8 Nov. 2006 -

08/11/2006  20:56            78,132 OSG_OP_OT-1.2-Flightgear.diff
08/11/2006  20:56         3,572,922 OSG_OP_OT-1.2-Flightgear.tar.gz

Since the diff file contains a compare of OSG_OP_OT-1.2 with OSG_OP_OT-1.2-Flightgear, it is assumed these fixes have already been applied to the files in the tar.gz file ... and doing my own diff seems to confirm that ... The tar.gz contains three folders OpenSceneGraph, OpenThreads and Producer, so it is time to do another build of OSG ... this time I build ALL - well nearly all - some failed needing other headers and/or libraries, but I HOPE I have enough ;=))

As always, this starts with rebuilding SG ... I must take it away from the 3rdParty folder used last time, and directly point it to OpenThreads and OpenSceneGraph again ... I get an EXE built -

Directory of C:\FG0910-5\FlightGear\bin
09/11/2006  19:04        12,083,200 FlightGear.exe

Note it is in a 'special' bin folder. This is so that I can 'install' all the OSG shared libraries (DLL) in the same runtime folder, and be able to remove them easily later. So, also into this folder I copy all the OpenSceneGraph, and OpenThreads DLLs, as well as the ILK and PDB (program database Debug) files. This give me access to all the symbols when tracing into these DLLs ...

BUT ALAS, I AM STILL GETTING LOTS OF DEBUG ASSERTIONS, AND TRIGGERED BREAKPOINTS. The console out seems a little further, in that it show the loading the the aircraft AC file ... the break occurred when reading an RGB file from within the AC file ... so still no flying today, but it seemed further along the rocky road, but maybe this is just wishful thinking ;=))

Another day frittered away ... maybe tomorrow will bring some success ... I begin to really wonder how other developers have got all this working in WIN32, using MSVC8 ;=()

I try the sample given in the osg page - - namely -


and this loads, and works fine ... a full screen (1280 x 1024) globe, which can be rolled with the mouse ... it seems the ESC key can be used to exit, but it takes a few seconds ... I download the, with the idea to try the other examples ... they provide a runexamples.bat ... after 'fixing' it to point to where I downloaded the data samples, everything seemed to run fine - some fantastic images - usually the left mouse did rotations, and the right mouse zoomed the object - and the ESC key exited the example ... GREAT STUFF ...

I also tried setting up a folder C:/FG0910-5/FlightGear/bin/air containing -

Directory of C:\FG0910-5\FlightGear\bin\data\air
19/02/2005  11:51           128,065 c172p-01.rgb
19/02/2005  11:51           133,852 c172p-02.rgb
19/02/2005  11:51           520,345 c172p-int-01.rgb
19/02/2005  11:51           467,485 c172p-int-02.rgb
19/02/2005  11:51           235,305

And then running the osgviewer example application with -

C:\FG0910-5\FlightGear\bin>osgviewer data\air\

And this produced a great image, after using the left mouse to orient it as I wanted -

image of Cessna 172 standard

This, more or less, shows that loading an ac3d file,, together with the RGB 'texture' files, WORKS WELL ... then why does this FAIL when running the FG application? Why do I get an 'abort' in the FlightGear application, when this direct load works fine? ;=))

OSG DEBUG: How to liven up the osg notify() output? Reading through the osg code, I note that osg::initNotifyLevel() checks for either "OSG_NOTIFY_LEVEL" or "OSGNOTIFYLEVEL" in the environment, and accepts values of "ALWAYS", "FATAL", "WARN", "NOTICE", "DEBUG_INFO", "DEBUG_FP", "DEBUG" and "INFO" ... this is fine when running from a command prompt, where it is easy to set the environment specifically for that console, but when running under the MSVC debugger this is more difficult. Yes, I can add to the environment through Control Panel -> Performance and Maintenance -> System, Advanced tab in System Properties dialog, [ Environment Variables ] button, either setting it as a User or System variable ... this I might have to do ...

But there is a function osg::setNotifyLevel(value), so first I try calling the function ... in all the some 80 osg examples, not one has this call ;=(( but it is simple to create a module, sgosgnotify.cxx, and do the call using 'ALWAYS', which equals ZERO (0) ... the module contains the simple code -

#include <osg/Notify>
void fgosgnotify( void ) { osg::setNotifyLevel(osg::ALWAYS); }

I call this function from fgMainInit(...) with the code -

extern void fgosgnotify( void );

But in running FG under the debugger, the check is - if (severity <= g_NotifyLevel) -, which seems to contrary to using ALWAYS (=0) ;=? It seems I should use the MAXIMUM level (DEBUG_FP?) to get all output ? But this sets it to 4!!! Try setting it to 20! ... but this still misses some early messages ... but I do get LOTS MORE messages output ...

While the osg function tries to find the osgdb_acd.dll in each path given in my environment variable PATH, it LEAVES THE CHECK THE PATH OF THE RUNTIME TO LAST ... I get output like, deleted some lines -

FindFileInPath() : trying C:\Program Files\Microsoft Visual Studio 8\VC\bin/osgPlugins\osgdb_rgbd.dll ...
FindFileInPath() : trying C:/Windows/System//osgPlugins\osgdb_rgbd.dll ...
Opened DynamicLibrary osgdb_rgbd.dll
FindFileInPath(data/Aircraft/c172p/Models/c172p-01.rgb): returning data/Aircraft/c172p/Models/c172p-01.rgb
raw->sizeX = 512
raw->sizeY = 512
raw->sizeZ = 4
raw->bpc = 1
image read ok 512  512
Adding to object cache data/Aircraft/c172p/Models/c172p-01.rgb
Reading image "data/Aircraft/c172p/Models/c172p-01.rgb"

 While this SEEMS to indicate that it FOUND the shared library (DLL), IT IS NOT VERY CLEAR ... and it was after a MASSIVE search ... it should have been the FIRST search ... the MSDN help is quite CLEAR after some information about a SafeDllSearchMode value in the registry, and other obfuscating items, and abbreviated somewhat ;=)) -

... the search order is as follows:
1. directory from which the application loaded. 
2. system directory ... from GetSystemDirectory()
3. 16-bit system directory ...
4. Windows directory ... from GetWindowsDirectory()
5. current directory. 
6. directories listed in the PATH environment variable ...

This clearly indicates the first place to look is the applications directory ... which is where I have 'installed' them ... I decide to HELP osg, and modify the 'search' code ... there is a function osgDB::appendPlatformSpecificLibraryFilePaths( FilePathList & filepath ), which for WIN32 should also added FIRST the fully qualified path obtained from GetModuleFileName(), after removing the file name of course. I add a little bit of code to FileUtils.cpp ...

#elif defined(WIN32)

    void osgDB::appendPlatformSpecificLibraryFilePaths(FilePathList& filepath)
        char modname[MAX_PATH];
        char* ptr;
        unsigned long len;
        ptr = modname;
        len = GetModuleFileName( NULL, ptr, MAX_PATH );
        while ( len > 0 )
            if ( ptr[len] == '\\' )
                ptr[len] = 0;
                if ( len > 0 )
        if ((ptr = getenv( "PATH" )))

#elif defined(__APPLE__)

I also do not like the unconditional adding of "C:/Windows/system" - this is the so called 16-bit directory - who would be installing these 32-bit shared libraries in there? ... maybe this should be "C:/Windows/system32", but this would always be in the PATH, which it does use ... but I decided to leave that for another day ;=))

With this patch, my shared libraries (DLL) are found quickly and efficiently ... but I am sure this is not the problem I am experiencing ... it is definitely during the loading the the aircraft ac file, more specifically the loading the an rgb texture file during the parsing of the ac file ...

But I have been playing with this project for over a week now ... it is time to do a complete UPDATE ... maybe my problems has already been solved, and I just need to use the updated code. As mentioned above I have a C:/FGCVS folder where I do all cvs/svn updates, then I can compare it with the contents of my chosen root C:/FG0190-5 ...

The update showed me there have been MANY files changed. For example, just about EVERY rgb file in FlightGear/data had been changed ... and as stated MANY OTHERS ... I use a variety of tools to compare the updated CVS folder with my working ROOT - I have my own 'Directory Compare for Windows (DC4W), the wonderful Beyond Compare from Scooter Software, a simple File Compare Utility (FC4), and even the GNU Unix utility 'diff' ...

 YEEK! In a compare, I note the ReaderWriterRGB.cpp I am using is the SAME as the CVS ??? It seems it was MISSED from the 2nd tar.gz update of 8 Nov, 2006 ... I switch to using that from the first tar.gz ... a size of 19,299 bytes, instead of 19,711 bytes ...

NOPE! I still get a BUG when reading the c172p-01.rgb ... maybe if I use the later CVS data ... NOPE! Still the SAME crash reading the RGB file ... out of PUFF ;=)) decide to give it a rest ... will continue another day ...

16 November, 2006 - Refreshed and read for another try ;=))

This time I decide to use the 'quick' instructions from Olaf - -

  1. Obviously I have already downloaded and install Microsoft Visual C++ .NET 2005 Express - -
  2. I have also downloaded and installed the Platform SDK (PSDK) - -
  3. Not that I need it now, but I did find a site to download the MS Assembler (ML.EXE) - -
  4. Open a new 'root' folder, in my case C:/FG0910-6, which ended up being populated as follows - Folder list in FG0610-6
  5. Downloaded the, and it unpacked into the '3rdparty' folder.
  6. Downloaded the, and it unpacked into the 'plib' folder.
  7. Downloaded the, and it unpacked into the 'OpenSceneGraph' and 'OpenThreads' folders.
  8. cvs updated my FGCVS SimGear, FlightGear source and data folders. X-copied the cvs SimGear to the 'SimGear' folder, and FlightGear source to the 'FlightGear' folder.
  9. Downloaded the, and unpacked it, overwriting the SG & FG vcproj files.
  10. Loaded SG/projects/VC8/SimGear.sln, and built SimGear, but had to MANUALLY copy simgear/simgear_config.h.vc5 to simgear_config.h
  11. Loaded the FG/projects/VC8/FlightGear.sln, and built FlightGear. I note it also included SimGear, so I saw '1 up-to-date', and got some LINK errors about missing debug information.
  12. Now to follow the last instruction - you need all the DLLs ... in the SAME directory as FlightGear.exe - and of course, you need at least the base FlightGear data available to point at ...

Since I only want to use all the shared libraries (DLL) supplied by Olaf, I make sure I remove my own OpenAL and alut from my system path. Thankfully I built the batch file (openal/upd.bat), shown below, to also do delete as well as the original copy. But this turned out WRONG. See below ...

I choose to add two(2) other folders to the above, called bin, and data. I copy all the DLLs from 3rdparty/bin, OpenSceneGraph/bin/win32, and OpenThreads/bin/win32, and the FlightGear/projects/VC8/Release/FlightGear.exe into 'bin', and the updated cvs FG data into 'data' - thank goodness for super large hard disks today ;=)), and I am ready to roll ;=))

C:\FG0910-6>md bin

C:\FG0910-6>copy 3rdparty\bin\*.dll bin\.
        7 file(s) copied.

C:\FG0910-6>copy OpenSceneGraph\bin\win32\*.dll bin\.
       14 file(s) copied.

C:\FG0910-6>copy OpenThreads\bin\win32\*.dll bin\.
        2 file(s) copied.

C:\FG0910-6>copy FlightGear\projects\VC8\Release\*.exe bin\.
        1 file(s) copied.

C:\FG0910-6>md data

C:\FG0910-6>xcopy /s C:\FGCVS\FlightGear\data\*.* data\.
... listing too BIG to include ... ends with ...
13744 File(s) copied

The run command is simple -

C:\FG0910-6\bin>FlightGear --fg-root=..\data

OOPS, I had overlooked the fact that Olaf has NOT included OpenAL stuff, so got the ERROR -

error dialog, showing missing OpenAL DLL

So I had to put back my own OpenAL and alut stuff - 3 DLLS - thankful that I have a batch file for this ... after that IT FLIES, with sound ;=))


I see frame rates of 44-74 fps, which is comparable to the PLIB version, but this is also a THREADED version, so it is not example comparing apples with apples ... I switch to noon - flying in the dark is not so much fun - and take off and do a short circuit, and land - WOW there is a lot of other AI traffic around that was not there before - this is becoming a busy airport ... I taxi and turn for another take off, open the throttle, start the roll, but BANG - the dreaded OS abort dialog ... so I got no chance to 'compare' other things ...

But HEY, this is a fast developing OSG work, and things are looking good ... can not wait for the NEXT INSTALMENT ;=)) stay tuned ...

To see a full list of the command options, you can use the command -

C:\FG0910-6\bin>FlightGear --fg-root=..\data --help --verbose

Since I want daytime, and a faster aircraft, I expand my command to - this has to all be in one line, not broken like here - I tend to put these in batch file, like rfgmig.bat, so I do not have to type it all the time - it is so easy to make an typo ;=))

C:\FG0910-6\bin>FlightGear --fg-root=..\data --timeofday=noon
 --aircraft=MiG-15bis --fdm=yasim

This requires you 'know', or look up using the Help menu, or reading the documents ...
C - to close the canopy. It is open at start up.
B - to take parking brakes off. It is a toggle, and ON at start up, in this aircraft.
'.' - I open the throttle, and have to use the right wheel brake, like on the Cessna, to keep on the centre line.
g - Gear Up. G is gear down.
F8 - clear the FOG. This can also be done from the command line.
h - to change HUD colour to red, for better visibility.
I - To toggle the HUD to one which shows the frame rate.
7/1 - to adjust the elevator trim for (hands off) level flight, once at the desired altitude, and throttled back.

I noted what looked like an OSG display problem - at start up, and up to the first layer of cloud, clouds are visible in the sky, but after the first layer, and just below the 2nd, at about 5/6 thousand feet, the sky appears completely blue - no clouds, and the Golden Gate bridge is in view. Then when you climb above both cloud layers, you can see more clouds above, and the Golden Gate bridge disappears ... I was trying to get screen shots from the right position (F3) when the dreaded OS abort dialog appeared ...

I ran FlightGear again, and tried hard to get screen shots, but they are a little 'messy'. The first image is below both cloud layers, at 4636 feet - the bridge is visible, as are the clouds above -

screen shot, below the clouds. all looks fine

This is in the 'layer' between the two cloud layers, at 5484 feet - no cloud are visible - looks like a clear, cloudless sky - great day for the BEACH ;=)) the bridge is still visible in this -in-between- layer, but not in this image - it is quite an effort to position this fast aircraft and take images as well ;=/

screen shot in the inbetween, like clear sky

And this is above both 'layers' of cloud, at 6632 feet - the cloud is visible below, and above, but the bridge is MISSING ??? see the roads coming to the water front in the bottom left ...

screen shot above the cloud layers, no bridge!

You can see my frame rate is in the mid-40s, which seems quite good on a windows machine ;=)) Anyway, time to pack it in for tonight. So the bugs noted are this 'missing bridge', and of course the OS abort after about 5-10 minutes flying - BUT AT LEAST I HAD SOME FLYING TODAY, so no complaints - just a big thank you to Curt and the team that provides this FABULOUS flight simulator ...

The has been a Wiki page - - created, mentioning some of the 'things-to-do' for this change over to OSG, and it does mention some objects fail to get rendered, and this is an easily repeatable 'bug' - just fly into between the cloud layers ... I took out the UFO to get a 'stable' view -

Below - Clouds and Bridge Middle - No Clouds, but Bridge Above - Clouds, NO Bridge
Below - clouds and bridge visible Inbetween - No clouds, but bridge visible Above - clouds return, but the bridge disappears ;=))

I am sure this will be fixed over time, but the OS abort is a hard one. I added --log-level=debug to see if there was any indication as to where the problem is - at this time, with LOTS of output going to the console screen, which has to be scrolled for each new line, my frame rate fell to 7 fps. Without this log output, I was getting into the high 80s with the UFO! On the middle image, I have enhanced the frame rate display, before suing 'debug' log level - but the last 15 or so lines of the console output only show -

lat 1.1241e-307lon 9.5057e-315
elev -1.60294e-161
range 4.96941e-091
 mp tanker transmitter valid start 0
 mp tanker number 0
findbyFreq 109.25 size 0
transmitter invalid 0
carrier_lat 1.1241e-307
carrier_lon 9.5057e-315
carrier_valid 0
distance_nm 6913.74 bearing 68.5714 horiz_offset 68.5714
y_shift 2525.87 x_shift 6435.82
 tacan range 81.1953 max range 150
Updating adjusted fog parameters.

This does not indicate much - the lat,lon of the tanker seem way off the mark, but the code seems to get through this, and be updating the FOG! Maybe it has something to do with the fact that I have DISABLED FOG (F8)? Also, on every iterations I saw over 100 messages of the form -

interpolate(): lookup error, x to small = 0

I wonder what this is all about, but do not think is has anything to do with the CRASH!

Anyway, things seem to be moving FAST on the OSG code front, so maybe if I just WAIT a little time, all will become well again ;=))

Flight Build End 

*** CONTINUED NEXT PAGE, under construction images ***


Full Computer Description: - back to top

Dimension 9200 Core 2 Duo E6400 2.13GHz (1066MHz)
PROMO "Passez à McAfee Security Center 3 ans"
PROMO "double your memory" - From 512DDR 2-533Mhz to 1024DDR 2-533Mhz
MS Logo Label for Vista Capable
Documentation Anglaise pour Dimension 9200 et câble d'alimentation UK
Memoire bicanal 1024 Mo (2x512) 533 Mhz DDR2
Lecteur de cartes multimedia interne 13-en-1
Disque dur 320 Go (7 200 tpm) SATA
Logiciel pour graveur de DVD (Sonic "Record Now","My Dvd")
Logiciel pour lecteur DVD ("Power DVD")
Graveur DVD +/- RW 16 X
FP/BL - Euro - 19in (E197FP TCO99) Value Black Flat Panel
256MB ATI Radeon X1300 Pro (1xDVI, 1xVGA, 1xS-Video)
Solution Audio Intégrée avec capacité Dolby Digital 7.1
Tapis de souris avec logo DELL
Souris Dell filaire USB (2 boutons + molette) noire
US Intl. - Clavier Dell Standard (QWERTY) - noir
Anglais - Microsoft Windows XP Media Center 2005
Anglais - CD de réinstallation pour Windows® XP Media Center Edition 2005 Authentique SP2
Anglais - Microsoft Works 8 (traitement de texte+Outlook Express)
Support technique Hotline
Anglais - Adobe Reader 7.0.8 (création de documents sous format PDF)
Anglais - Ghost 10-offre d'essai 90 jours
Network Assistance (90 jours)
Corel PSP Photo XI- 60 day trial
Corel Snapfire Starter Edition
Anglais-3 ans d'abonnement McAfee
Garantie de base
Garantie :1 an "aller retour atelier "
PROMO - Digital Music e-Learning Lite Pack, 60-day, En/Fr/De/Es/It - Go to to register
Commande Dimension - France
Sous-total H.T. 840,28 + TVA 164,69
Total T.T.C. 1.004,97 Euro.
back to top

Sample OpenAL batch file, which I called UPD.BAT - back

@echo Deal with installing shared library (DLL) files ...
@set TEMPD=C:\WINDOWS\system32
@set TEMPS1=wrap_oal.dll
@set TEMPS2=OpenAL32.dll
@set TEMPS3=alut.dll
@set TEMP1=OpenAL-Windows\OpenAL32\Release\%TEMPS1%
@set TEMP2=OpenAL-Windows\Router\Release\%TEMPS2%
@set TEMP3=alut\admin\VisualStudio6\alut\Release\%TEMPS3%
@if "%1." == "D." goto DODELETE
@if "%1." == "d." goto DODELETE
@if "%1." == "." goto DOCOPY
@echo Only 1 argument allowed - D for DELETE ...
@goto END

@echo Installing shared library (DLL) files ...
@if NOT EXIST %TEMP1% goto ERR1
@if NOT EXIST %TEMP2% goto ERR2
@if NOT EXIST %TEMP3% goto ERR3
@if EXIST %TEMPD1% goto NOOVR1
@if EXIST %TEMPD2% goto NOOVR2
@if EXIST %TEMPD3% goto NOOVR3
copy %TEMP1% %TEMPD1% > nul
copy %TEMP2% %TEMPD2% > nul
copy %TEMP3% %TEMPD3% > nul
@goto END

@echo Note [%TEMPD1%] already exists ...
@goto RUNDEL
@echo Note [%TEMPD2%] already exists ...
@goto RUNDEL
@echo Note [%TEMPD3%] already exists ...
@goto RUNDEL

@echo Will NOT overwrite a file ...
@echo Run DELETE - D command - first ...
@goto END

@echo Deleting shared library (DLL) files from %TEMPD% ...
@if NOT EXIST %TEMPD1% @echo %TEMPD1% does not exist.
@if NOT EXIST %TEMPD2% @echo %TEMPD2% does not exist.
@if NOT EXIST %TEMPD3% @echo %TEMPD3% does not exist.
@if EXIST %TEMPD1% del %TEMPD1% > nul
@if EXIST %TEMPD2% del %TEMPD2% > nul
@if EXIST %TEMPD3% del %TEMPD3% > nul
@goto END

@echo ERROR: Can NOT locate [%TEMP1%] file ...
@echo Check name and location ... aborting ...
@goto END

@echo ERROR: Can NOT locate [%TEMP2%] file ...
@echo Check name and location ... aborting ...
@goto END

@echo ERROR: Can NOT locate [%TEMP3%] file ...
@echo Check name and location ... aborting ...
@goto END


back top

Console output on 2nd run

back top

C:\FG0910-5>C:\FG0910-5\FlightGear\Debug\FlightGear.exe --fg-root=data
FlightGear:  Version MSVC-WIN32-0.9.10 OSG
Built with Microsoft Visual C++ version 1400

Scanning command line for: --fg-root=
argv[1] = --fg-root=data
fg_root = data
Reading global preferences
Finished Reading global preferences
Unable to detect the language
Selecting language: C
Reading localized strings from data/Translations/strings-default.xml
Scanning command line for: --aircraft=
argv[1] = --fg-root=data
No user specified aircraft, using default
Reading default aircraft: c172p from data/Aircraft/c172p/c172p-set.xml
Reading user settings from C:/Documents and Settings/Geoff McLane/Application Data/
First time reading user settings
Finished Reading user settings
Processing command line arguments
Finished command line arguments
Initializing splash screen
256MB ATI Radeon X1300PRO x86/SSE2
Max texture size = 4096
Depth buffer bits = 24
Loading Airport Database ...
Data file version = 810
End of file reached
Loading Navaid Databases
opening file: data/Navaids/carrier_nav.dat
opening file: data/Navaids/TACAN_freq.dat
Attempting to set starting position for KSFO:28R
runway =  -122.375, 37.6211 length = 3610.36 heading = 117.9
Position for KSFO is (-122.357, 37.6135) new heading is 297.9
Initializing Time
Current greenwich mean time = Sun Nov 05 16:15:40 2006

Current local time          = Sun Nov 05 17:15:40 2006

Reading timezone info from: data/Timezone/
Using zonename = data/Timezone/America/Los_Angeles
Updating time
  Current Unix calendar time = 1162743340  warp = 0
  Current GMT = 11/5/2006 16:15:40
  Current Unix calendar time = 1162743340  warp = 0
  Current GMT = 11/5/2006 16:15:40
  Current Julian Date = 2.45405e+006
  First time, doing precise gst
  gst => 187.245
  COURSE: GMT = 10/5/106 16:15:40
  March 21 noon (GMT) = 1142938800
  Time since 3/21/106 GMT = 229.219
  days = 229  hours = 16.2611  lon = 0  lst = 19.5278
  COURSE: GMT = 10/5/106 16:15:40
  March 21 noon (GMT) = 1142938800
  Time since 3/21/106 GMT = 229.219
  days = 229  hours = 16.2611  lon = -0  lst = 19.5278
  Current lon=0.00 Sidereal Time = 19.2447
  gst => 187.245
  Current LOCAL Sidereal Time = 19.2447 (19.2447) (diff = -0.283064)
General Initialization
======= ==============
FG_ROOT = "data"

Initializing basic built-in commands:
Initializing scenery subsystem
=== and then the OS abort ===

back top

Stack Trace at moment of abort

back top

> FlightGear.exe!std::_Deque_const_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,1>::operator*() Line 102 + 0x11 bytes C++
FlightGear.exe!std::deque<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::_Insert<std::_Deque_const_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,1> >(std::_Deque_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,1> _Where=<end>, std::_Deque_const_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,1> _First={...}, std::_Deque_const_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,1> _Last=<end>, std::bidirectional_iterator_tag __formal={...}) Line 1008 + 0xb bytes C++
FlightGear.exe!std::deque<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::insert<std::_Deque_const_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,1> >(std::_Deque_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,1> _Where=<end>, std::_Deque_const_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,1> _First={...}, std::_Deque_const_iterator<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > >,1> _Last=<end>) Line 929 C++
FlightGear.exe!std::deque<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >::deque<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > >(const std::deque<std::basic_string<char,std::char_traits<char>,std::allocator<char> >,std::allocator<std::basic_string<char,std::char_traits<char>,std::allocator<char> > > > & _Right=[22805080](...,...)) Line 562 + 0x7a bytes C++
FlightGear.exe!sgLoad3DModel(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & fg_root="data", const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & path="Aircraft/c172p/Models/c172p.xml", SGPropertyNode * prop_root=0x021890c8, double sim_time_sec=0.00000000000000000, osg::Node * (SGPropertyNode *)* load_panel=0x00d798c0, SGModelData * data=0x00000000, const SGPath & externalTexturePath={...}) Line 532 + 0x11 bytes C++
FlightGear.exe!fgLoad3DModelPanel(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & fg_root="data", const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & path="Aircraft/c172p/Models/c172p.xml", SGPropertyNode * prop_root=0x021890c8, double sim_time_sec=0.00000000000000000, const SGPath & livery={...}) Line 43 + 0x25 bytes C++
FlightGear.exe!FGAircraftModel::init() Line 77 + 0x5a bytes C++
FlightGear.exe!fgIdleFunction() Line 757 + 0x26 bytes C++
FlightGear.exe!GLUTidle() Line 122 + 0x11 bytes C++
FlightGear.exe!glutMainLoop() Line 1510 + 0x8 bytes C
FlightGear.exe!fgOSMainLoop() Line 155 C++
FlightGear.exe!fgMainInit(int argc=2, char * * argv=0x021836b0) Line 1041 C++
FlightGear.exe!main(int argc=2, char * * argv=0x021836b0) Line 204 + 0xd bytes C++
FlightGear.exe!__tmainCRTStartup() Line 318 + 0x19 bytes C
FlightGear.exe!mainCRTStartup() Line 187 C
[Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]

back top

top - index - next page

Valid HTML 4.01 Transitional