In page links: preamble changes update fix patch patch2 libpng cmake flying adjustments folders downloads end
I have prepared a page showing all the prerequisites required, with the latest links at that time (Apr 5, 2008)
As to be expected, quite a lot had changed in the about 6 months since my last FlightGear build, back in August, 2007, but my simple build system worked well. Sure, I had to delete a few source files, and ADD quite a number, including some more OSG libraries, but in no time at all ;=)) I had the Release version of FlightGear built in WIN32 using MSVC8.
Previously, with my build 'system', I had to run Microsoft Visual Studio 2005 Express Edition
(MSVC8) two times, but testing showed I was missing some OSG plugins, due to the recent changes
to using PNG graphic files. This meant libpng had to be added to the prerequisites, and
thus MSVC8 had to be run THREE(3) times. First -
1. using my special combined fgfs.sln, to
build the static libraries, libpng.lib and zlib.lib,
2. on OpenSceneGraph.sln, after running
CMake 2.4 in the OpenSceneGraph folder, then
3. back to fgfs.sln, to finalize the
complete link of FlightGear ....
I did it over a few days, thus can only estimate it took about 4-5 hours, AFTER I had ALL the sources in place ... plus some more to do this web page, and prepare the download zips given below ...
After I got it ALL compiled and linked, did a quick compare of the VCPROJ files, and found :-
Appears 3 DELETED items ... FlightGear - src\Scenery\FGTileLoader.cxx SimGear - simgear\math\polar3d.cxx SimGear - simgear\math\sg_geodesy.cxx Appears 18 ADDED items ... FlightGear - src\AIModel\AIFlightPlanCreatePushBack.cxx FlightGear - src\AIModel\AIWingman.cxx FlightGear - src\Main\fg_os_common.cxx FlightGear - src\Main\FGManipulator.cxx FlightGear - src\Instrumentation\groundradar.cxx FlightGear - src\Environment\precipitation_mgr.cxx FlightGear - src\Scenery\SceneryPager.cxx FlightGear - src\Main\ViewPartitionNode.cxx SimGear - simgear\scene\tgdb\GroundLightManager.cxx SimGear - simgear\scene\model\ModelRegistry.cxx SimGear - simgear\scene\model\particles.cxx SimGear - simgear\misc\PathOptions.cxx SimGear - simgear\environment\precipitation.cxx SimGear - simgear\math\SGGeod.cxx SimGear - simgear\structure\SGSmplstat.cxx SimGear - simgear\scene\tgdb\ShaderGeometry.cxx SimGear - simgear\scene\util\StateAttributeFactory.cxx SimGear - simgear\scene\tgdb\TreeBin.cxx
This is perfectly normal with a ever growing product like FlightGear ... And some more of the OSG libraries were used :-
FlightGear - Release|Win32=osgGA.lib FlightGear - Release|Win32=osgUtil.lib FlightGear - Release|Win32=osgParticle.lib FlightGear - Debug|Win32=osgGAd.lib FlightGear - Debug|Win32=osgUtild.lib FlightGear - Debug|Win32=osgParticled.lib
Now to make sure it runs ... Had to do quite a number of 'fixes' to my upd.bat batch and makefiles that copy the DLLs to the bin folder, from where I run FG ... OSG has changed lots of names, and locations of DLL items ...
The first run is a disappointing CRASH ... the image of the runway had appeared and the sound had started, so this was well through the initialization of FG ... I did some usual things like using the UFO, disabling AI ... and the UFO came up, but only last about 30 seconds before a CRASH ... I did try log level debug, and captured the massive output, but this gives so much information ...
DRAT, must now work on finalizing the DEBUG version so I can run the whole thing under the MSVC8 WIN32 debugger, and see if I can discover the reason for the crash ... there seemed no indications from the recent User or Development boards that I monitor ...
I note from the log output, that even though I added the command --disable-ai-models, which sets /sim/ai/enabled, in the property tree to false, there are still a LOT of entries which seem related to AI models, and in fact the last lines of the log are :-
AI Manager: AI model return list size 41 Submodel: Impact 0 hit! 0 parent_subID 0 ... many more of these ... Submodel: Impact 0 hit! 0 parent_subID 0 Processing registration N4213 with callsign N4213 Route from KHWD to KRNO. Set leg to : 1 No pushback route found for gate 9 at KHWD Reading model "../data/AI/Aircraft/b1900d/Models/b1900d.ac"
Is this something to do with the problem?
Well yes and no. The problems was simple. The b1900d.ac uses a PNG texture, "NZAlivery.png". It crashed when trying to read a PNG file. The code is, in ModelRegistry.cxx -
ReaderWriter::ReadResult res; res = registry->readImageImplementation(absFileName, opt); if (res.loadedFromCache()) SG_LOG(SG_IO, SG_INFO, "Returning cached image \"" << res.getImage()->getFileName() << "\""); else SG_LOG(SG_IO, SG_INFO, "Reading image \"" << res.getImage()->getFileName() << "\"");
Note, NO CHECK of the ReaderWriter::ReadResult res.status() is made, which is, at that time set to ERROR_IN_READING_FILE ... with a big warning message, that is QUITE CLEAR!!!.
res._message = "Warning: Could not find plugin to read objects from file "C:\FG\19\data\AI\Aircraft\b1900d\Models\NZAlivery.png"." ...
Simple - it seems my update of my upd.bat batch and related make file, does NOT include the PNG reader ... in fact I can NOT even immediately find something like osgdb-png[d].dll ... Is there one?
While there have already been MANY so called 'First-chance exceptions', shown in the MSVC8 output, like -
First-chance exception at 0x7c812a5b in FlightGearD.exe: Microsoft C++ exception: sg_range_exception at memory location 0x0012d86c..
The CRASH is on one that can NOT be handled ...
First-chance exception at 0x017cb28a in FlightGearD.exe: 0xC0000005: Access violation reading location 0x00000050. Unhandled exception at 0x017cb28a in FlightGearD.exe: 0xC0000005: Access violation reading location 0x00000050.
While this does NOT fix the problem, it certainly increases the information available to the console output, when such a thing happens - patch to simgear/simgear/scene/model/ModelRegistry.cxx, about line 258, in diff -u format -
--- C:\FGCVS\SimGear\simgear\scene\model\ModelRegistry.cxx Wed Jan 16 23:33:54 2008 +++ C:\FG\19\SimGear\simgear\scene\model\ModelRegistry.cxx Mon Mar 10 15:30:53 2008 @@ -258,6 +258,12 @@ Registry* registry = Registry::instance(); ReaderWriter::ReadResult res; res = registry->readImageImplementation(absFileName, opt); + if (res.status() == ReaderWriter::ReadResult::ERROR_IN_READING_FILE) { + SG_LOG(SG_IO, SG_ALERT, "Failed reading image file \"" + << fileName << "\""); + SG_LOG(SG_IO, SG_ALERT, res.message() ); + return ReaderWriter::ReadResult::FILE_NOT_FOUND; + } if (res.loadedFromCache()) SG_LOG(SG_IO, SG_INFO, "Returning cached image \"" << res.getImage()->getFileName() << "\"");
What to do in such a situation is always optional, but as some lines above did, I chose to return FILE_NOT_FOUND, but this still causes an abort. Maybe instead of returning, it should just exit(-1)? But at least, with this patch in place the output makes it very clear what is wrong. The last few lines of the log are now -
Failed reading image file "C:\FG\19\data\AI\Aircraft\b1900d\Models\CMAlivery.png" Warning: Could not find plugin to read objects from file "C:\FG\19\data\AI\Aircraft\b1900d\Models\CMAlivery.png".
Of course, even with this patch, FG still aborts, thus the real fix is as follows -
Additionally, while running FG under the MSVC8 debugger, I found a debug assertion - index out of range! This small patch got me through that problem - patch in diff -u format -
--- C:\FGCVS\FlightGear\source\src\Autopilot\xmlauto.cxx Tue Feb 26 12:06:47 2008 +++ C:\FG\19\FlightGear\src\Autopilot\xmlauto.cxx Mon Mar 10 17:57:30 2008 @@ -767,9 +767,14 @@ else if (filterType == doubleExponential) { double alpha = 1 / ((Tf/dt) + 1); - output.push_front(alpha * alpha * input[0] + + if (output.size() > 1) { + output.push_front(alpha * alpha * input[0] + 2 * (1 - alpha) * output[0] - (1 - alpha) * (1 - alpha) * output[1]); + } else { + output.push_front(alpha * alpha * input[0] + + 2 * (1 - alpha) * output[0] ); + } } else if (filterType == movingAverage) {
Not sure what this does to the code, but it certainly removes the debug assertion! It would be correct if output[1] is ZERO ;=))
Now to find the PNG reader ... I had read on the development board that many graphic files were now as PNG ... From the OpenSceneGraph ( http://www.openscenegraph.org/index.php ) site, I can read that there are some dependencies, like ftp://swrinde.nde.swri.edu/pub/png/src/lpng128.zip - This link FAILED, but I found a http://www.libpng.org/pub/png/, so searched around there ...
I find the latest release is libpng 1.2.25, February 18, 2008 - http://libpng.sourceforge.net/ - which leads to - http://sourceforge.net/project/showfiles.php?group_id=5624 - from here I download -
08/03/2008 13:54 624,321 lpng1225.zip
and note that I had previously downloaded, but never compiled -
31/01/2007 15:08 636,417 lpng1215.zip
And I also note, in the OpenSceneGraph source THERE IS a PNG plugin component -
Directory of C:\FG\19\OpenSceneGraph\src\osgPlugins\png 26/02/2008 12:05 12,596 ReaderWriterPNG.cpp
but this does NOT appear to have been built??? The CMakeLists.txt file in this directory has a line -
INCLUDE_DIRECTORIES( ${PNG_INCLUDE_DIR} ${ZLIB_INCLUDE_DIR} )
Obviously, I did not supply these two 'includes' to CMake ... And of course, inside the cpp file there are the lines -
#include <zlib.h> #include <png.h>
hmmm, how to do this?
1. I unzip the lpng1225.zip into my base source folder, in this case, C:/FGCVS/lpng1225, so I will also have this source for future cases, like I have for zlib-1.2.3 ...
2. I copy this lpng1225 folder to my work directory, in this case C:\FG\19 ... and must remember to add this to my setupfg.bat batch file.
Now, how to build it? In the source there is a MSVC6 DSW/DSP files, that makes library PNG, and a test application. However, there is also a MSVC7.1 SLN/VCPROJ set that not only makes the PNG library and test, but INCLUDES a zlib make. So I choose to go with this ... BUT it requires me to copy/move the ZLIB source to ../zlib, which I could do, and offers a plethora of configurations -
So, no I do NOT want to go this direction ... I already have zlib, and I do NOT want a DLL, nor ASM code - I just want a static library - so I trash all this ... another reason for COPYING the original folder. I can do the trashing by just fully deleting the folder, and doing a fresh XCOPY ... and start with the MSVC6 DSW/DSP set and conver them using MSVC8 ...
But even in here I find zlib, but since the path to zlib.dsp was not validt, it did NOT find this - giving an 'awkward' error message that zlib.dsp was 'corrupted', when it actually means - does not exist on the path given ... I delete this 'unavailable' project. It still offers the same big set of configuration options, so I decide to trim this down, through the 'Configuration Manager', to just LIB Debug and Release ...
I also check the RUNTIME is consistent with ALL THE OTHER projects, in this case /MD and /MDd (Multithreaded DLL) ... I also took the opportunity to correct the path to the zlib.h header to ..\..\..\zlib-1.2.3, and the path to the zlib[d].lib to ..\..\..\zlib-1.2.3\projects\visualc6\Win32_LIB_Debug\zlibd.lib and ..\..\..\zlib-1.2.3\projects\visualc6\Win32_LIB_Release\zlib.lib respectively for the pngtest program ... although I later copy these static libraries to the zlib-1.2.3 root, to make things easier for CMake adjustments.
I was rewarded with two(2) new libraries -
Directory of C:\FG\19\lpng1225\projects\visualc6\Win32_LIB_Debug 08/03/2008 14:57 746,486 libpngd.lib Directory of C:\FG\19\lpng1225\projects\visualc6\Win32_LIB_Release 08/03/2008 15:05 325,770 libpng.lib
These, I also copy the the lpng1225 folder root ... ready to build ReaderWriterPNG.cpp ...
In CMake (2.4), I found and added a ZLIB_INCLUDE_DIR and ZLIB_LIBRARY, but had to
ENABLE the -
[x] Show Advanced Values
to see the PNG_PNG_INCLUDE_DIR and PNG_LIBRARY paths. As mentioned above, also to
make things easier, I copied the zlib[d].lib into the zlib-1.2.3 root, and likewise the
libpng[d].lib to its root ... since CMake does NOT seem to offer how to give a Release and
Debug path separately, or at least I have not found it ...
On running [ OK ] again in CMake, was rewarded with -
Directory of C:\FG\19\OpenSceneGraph\src\osgPlugins\png 08/03/2008 15:21 12,317 INSTALL.vcproj 08/03/2008 15:21 15,552 osgdb_png.vcproj
So now to build OSG again to get my additional DLL (and library) ...
Oops, small mistake ... I tried to use a RELATIVE path in CMake, but this seemed wrong. In such a literal tools, perhaps you have to use the FULL PATHS, but maybe I am mistaken - anyway I have now put in full paths ... And it seems it is intelligently using the Release and Debug version MAYBE?
After running MSVC8 again on the OpenSceneGraph solution file generated by CMake, then I was rewarded with FOUR(4) new plugins ...
08/03/2008 15:34 163,840 osgdb_png.dll 08/03/2008 15:35 258,048 osgdb_pngd.dll 08/03/2008 15:25 31,744 osgdb_zip.dll 08/03/2008 15:36 155,648 osgdb_zipd.dll
These must now be added to my update makefiles, updpinr.mak and updpind.mak .. they became items 41 and 42 ... run upd.bat batch, and we should be FLYING ... change directory to bin/bats and run rfgufo.bat ... this batch file contains a bunch of commands, like -
--fg-root=..\data --fog-disable --timeofday=noon --fdm=ufo --aircraft=ufo --altitude=1000 --prop:/sim/rendering/fps-display=true --lon=-122.33276046 --lat=37.60364931 --heading=297
This should put the UFO 1000 feet in the air, south of KSFO, beyond the runway marker, ready to 'land' ...
AND
I AM FLYING - FLYING
FLYING ;=))
What a FABULOUS (free) flight simulator this is!
DRAT! Now my build has got a little more COMPLICATED, since OSG now requires library PNG and library ZLIB to build, these MUST be built FIRST, then CMake/MSVC8 OSG, then eventually my 'combined' build file. That is -
1. OSG prerequisites, library PNG and ZLIB
2. OSG itself - Libraries and Plugins DLLs
3. All the other prerequisites, then FlightGear.
BUT, rather than splitting this, I have added the library PNG build into the main FGFS.SLN ... thus now -
1. this FGFS.SLN needs to be loaded first, and built ... the final link will FAIL due to the missing OSG libraries, but it will build the libpng and zlib static libraries, ready for OSG;
2. Run CMake on OSG, ensuring pointers established to the PNG and ZLIB built as part of the above, and then build OSG, which will now link with PNG and ZLIB, then ...
3. Run the main FGFS.SLN again ... this time the final link should succeed ...
View of SOURCE, that is either updated using CVS or SVN, or from a tar ball or zip, and WORK folders, needed for my TWO SOLUTION SYSTEM (TSS) ...
SOURCE folders | WORK folders |
---|---|
Specifically note the SOURCE folders where FlightGear has both 'source' and 'data', and freeglut is repeated. To use the batch files supplied with my 'system', and the fgfs/FGFS.SLN, these must be matched exactly. Any deviation requires sometimes major adjustments later.
Date | Download | Description | Size | MD5 Digest |
---|---|---|---|---|
10/03/2008 | vc8sln08.zip | Single MSVC8 solution, excl OSG | 74,173 | 0c827883bacaa586e8166560744443d3 |
10/03/2008 | fgvc8rt08.zip | Runtime EXE and DLL - MSVC8 | 5,287,141 | de5be72dccac0bf7ab694f15878345cd |
The vc8sln08.zip contains a README.fgfs.htm, which is also available online here. In addition to the SOURCES, this is all that is required if you are going to build it yourself.
The fgvc8rt08.zip contains all the files necessary to run FlightGear. If not previously done, OpenAL, in the bin\OpenAL folder, must be installed. There is an upd.bat batch file in that folder to aid with this. It also includes bin\bats with a set of batch files to run flightgear. You may have to adjust the setroot.bat if your FG data is NOT located in ..\data ...
Happy sim-flying ;=))
Geoff McLane.
Friday, March 07-10, 2008.
PS: Although I have not tried it yet, all the above should work with MSVC9 (Microsoft Visual C++ 2008 Express Edition) currently offered through http://www.microsoft.com/express/ ...
EOF - fgfs-042-FG_OSG_MSVC8_March_2008.doc