FG OSG MSVC9 - details

external: index back to fgfs-045.htm
internal: details | notes | end

Build Details

This process took me a good working day to complete, and here are the times, and notes made. The effort was actually spread over about 5 days, as other things interrupted, but as can be seen it took about 8 hours.

Time line of a FG build in Vista, using MSVC9 - spread out over 5 days - 20080910 - 20080915
  Update SVN/CVS sources. Had not done it in a while, so it took some time … also OpenAL had changed its location - see Note 3 below. 12:24 12:53 00:29
  Researching OpenAL, and choosing what to do … 12:40 14:36 01:56
1 Download vc9sln01.zip, and extract setupfg.bat, to a BASE WORK folder, and in this case adjust it to remove OpenAL 12:50 13:11 00:21
2 Update all sources again since it has been a few days … and sure enough there were a few more changes … 15:31 15:40 00:09
3 Copy sources, including FG data, to new folder 22, using setupfg.bat … noted a problem with lpng1225, which should probably be undated anyway … 15:40 15:57 00:17
  From my prerequisites page - http://geoffair.net/fg/prereq.htm - note lpng is now 1.2.31, so update to this … and see there is also a 1.2.32rc01 … 15:57 16:05 00:08
  Get lpng1231.zip, and put in <sources>\lpn1231 folder, and adjust setupfg.bat for next time. And copy source to 22/lpng1231 … 16:05 16:12 00:07
4 Unzip all vc9sln01.zip to my new folder 22 … but manually copy libpng.vcproj to its new location visualc71, and adjust the fgfs.sln to match … and at the same time remove all OpenAL ... 16:12 16:31 00:19
5 Unzip vc9cfg01.zip, ignoring the OpenAL item 16:33 16:36 00:03
6 There is a vc9chg01.zip, but it only contains OpenAL items, so skip this … 16:31 16:33 00:02
7 Load MSVC9, and open fgfs/fgfs.sln ... 16:33 16:37 00:04
8 Build just the libpng, and zlib projects - Release, and Debug - quick, and no problems ;=)) 16:37 16:39 00:02
9 Run CMake on the OpenSceneGraph folder, selecting MSVC9. Initially I could not find the PNG_... Options even with [x] Show Advance Values checked. (see Note 1 below) 16:40 16:48 00:08
  But after running [ Configure ] the first time, the PNG items appeared ;=)) After setting the pointers to lpng1231, another [ Configure ] and had no 'red' items, so proceeded to [ Ok ] … 16:48 16:52 00:04
10 Load 2nd MSVC9, and open OpenSceneGraph.sln, and build Debug first ... 16:53 17:31 00:38
  Then OpenSceneGraph Release … I later CLEANED the whole 69 project solution and ONLY built 'Release' - about 30 mins 17:31 18:03 00:32
11 Reload MSVC9 with fgfs.sln, and remember to adjust SG/FG includes to C:\Program Files\OpenAL 1.1 SDK\include … but this points out I may still require ALUT? But where is it? Ha, maybe it is 'freealut' ? But start Debug compile 18:04 18:12 00:08
  But ends with lots of ERRORS, some 'strange' - C2471: cannot update program database, and C1083 cannot open program database … switch to Release … 18:18 18:38 00:20
  One of course is cannot locate <AL/al.h> … well that is understandable, since the OpenAL SDK no longer puts al.h in an AL folder … create a new switch USE_OPENAL_SDK, and use just <al.h> under this switch …      
  BUT THIS DOES NOT GET OVER THE MISSING alut.h??? But make some easy corrections and compile again … 18:38 18:40 00:02
  But without an alut.h, ALUT_API_MAJOR_VERSION is not defined, and the code falls back to what is comments as 'pre 1.0 alut version' …
I download ALUT, freealut-1.1.0-src.zip from the creativelabs site … and add it to the sources in freealut-1.1.0-src folder … In my new 22 create a copy in alut folder … it has an include/AL/alut.h …
18:41    
  And it has both .sln and .dsw files … I add the alut.vcproj to the fgfs solution …
This points out that (a) it needs access to alc.h, in OpenAL 1.1 SDK/include, but it already points to 'OpenAL 1.1 with EFX SDK'! Did I download, and install the 'wrong' SDK?
But reading the creativelabs openal it seems the OpenAL11CoreSDK I downloaded includes 'X-RAM Extension, the Effect Extension (EFX), etc, so maybe I should just correct it to my 'OpenAL 1.1 SDK/include' folder …
After a few other minor fixes, am rewarded with an alut.dll, which I copy to C:\Windows\System32 - that is INSTALL it - of course this must be done as 'administrator' in Vista … and there is an alut.lib ready for links …
And to get to alut.h, must add an include path to SG/FG to ..\alut\include … and later a path to the alut.lib … and this is why I prefer to copy to a work 'alut', than use the 'freealut-1.1-src' folder in the zip … 19:20 00:39
Back to compiling … 19:20 19:30 00:10
Time to remove the 'missing' files from the solution … of course there may be other to add later to replace these files …
transmissionlist.cxx, transmission.cxx, trafficcontrol.cxx, tower.cxx, tileentry.cxx, sgVec3Slider.cxx, newcache.cxx, mouse.cxx, MagicCarpet.cxx, gui_local.cxx, ground.cxx (which is good because there is a Ground.cpp also), commlist.cxx, BalloonSim.cpp, Balloon.cxx, atis.cxx, ATCVoice.cxx, ATCUtils.cxx, ATCProjection.cxx, ATCmgr.cxx, ATCDialog.cxx, ATC.cxx, approach.cxx, AIPlane.cxx, AIMgr.cxx, AIlLocalTraffic.cxx, AIGAVERTraffic.cxx, AIEntity.cxx, trackball.c - WOW, it seems I should have run my fgam2dsp.pl first ;=)
19:30 19:52 00:22
AND I GOT MY FIRST LINK - Ok, there are some 90 missing externals, but it is just time to track these down, and add the files …
First one FGNavRecord::get_cart … found in FG/src/navaids/navrecord.cxx
FGTowerController::announcePosition, in FG/src/ATC/trafficcontrol.cxx
Ha, it seems a whole bunch deleted have just moved house to ATCDCL, so add al the *.c* files in here …
Things like _modelloader, TileCache, etc, turn out to be missing from SG … so are added to SG library …
Working on these missing external, virutally one-by-one, is a steady process. I use my own grep like tool to locate it in the appropriate source ...
GOT A CLEAN LINK
19:52 20:30 00:38
When everything is in place, and all corrections done, an actual simple build of the Release of fgfs.sln (15 projects) takes only about 15 minutes, and that is IGNORING the some 234 warnings issued! Below, Note 4, is an analysis of the warnings issued.
12 In the MSVC Command prompt, run upd.bat, since it uses nmake - As usual with this step, it FAILED the first time … OSG sets new 'version' numbers from time to time, and the upd.bat needs to be corrected to use these numbers … Note 5 16:20 16:34 00:14
There should be a way to 'automate' these OSG version changes … maybe through a Perl script …
13 Unzip rfgbats09.zip with folders ... these will be put in bin/bats - this presently includes a OpenAL install batch … 16:34 16:36 00:02
14 As mentioned above have now switch to using the OpenAL 1.1. SDK … and did a manual copy of alut.dll into C:\Windows\System32 to join its OpenAl32.dll and wrap_oal.dll mates ;=)) (see Note 2 below)
15 cd bin\bats, and try rfgufo, or any of the other batch file available …

AND I WAS FLYING

Toured over the Golden Gate, and found an Aircraft carrier tooting along, another ship head for the port, and other craft … and back in SF bay, I note other boat activity, all added since April ... next I expect to see 'traffic' going of the GG bridge ;=))
Frame rate was consistently in the high 80's, with a top of over 134 frame per second …

AS I KEEP SAYING, WHAT A FANTASTIC FLIGHT SIMULATOR THIS IS ;=))

The console showed a few 'warning', seemingly from nasal - something about 'unauthorized access', but only a few, and it flew, and flew and flew … see console warnings ...
TOTAL 07:38

Of course, if you KEEP the sources up-to-date, and continually apply fixes to the solution files, a full re-build should only be a few hours ;=))

top


Notes:

Note 1: OSG Plug-ins for ZLIB and PNG
Make sure you CHECK [x] Show Advanced Values, and correctly point -
(i) ZLIB_INCLUDE_DIR to the zlib-1.2.3 folder, and ZLIB_LIBRARY to zlib-1.2.3/zlib.lib, and
(ii) PNG_PNG_INCLUDE_DIR to the lpng1231 folders, and PNG_LIBRARY to lpng1231/libpng.lib
or else some VERY IMPORTANT add-ons will NOT be built. back to CMake ...

top


Note 2: Installing ALUT.DLL
I tried using upd.bat to complete this step - that is to copy alut.dll to C:\Windows\system32, but it failed, since I was not running as 'administrator' - so this step has been left as manual, but is ESSENTIAL ...
If you want to try the openal DLLs I used, then -
date:14/09/2008 link:OpenAL32.zip size:258,000  MD5:514b5521e330bb41230c5480ab3c6d6b
contains OpenAL32.dll, wrap_oal.dll, and alut.dll from my system32 folder - but it is highly recommended you use those from the Creative site, and build alut.dll yourself. You still need the headers and library files anyway! - back to alut

top


Note 3: More on OpenAL and ALUT
From : http://connect.creativelabs.com/openal/default.aspx - and searching around, advises use:
svn://connect.creativelabs.com/OpenAL … but what to do with that???
It seemed difficult to find the SVN source - They do offer a Windows Installer, and an OpenAL SDK … maybe I should switch to these!
The oalinst.zip downloaded contains oalinst.exe, which contains OpenAL32.dll and wrap_oal.dll, the binary runtimes, but to develop also need the 'libraries' and API headers, which I assume will be in the OpenAL11CoreSDK.[zip/exe] … BAH! Choices!!!
Since in Vista there is more 'protection' of the 'Windows' folder, so even if I do compile them myself, they still have to be 'installed' somewhere … I decide to go with this SDK solution, and forgo building it myself for now …
As suspected running oalinst.exe just copied OpenAL32.dll and wrap_oal.dll to my C:\Windows\System32 … more or less what my batch files system was doing …
Then running the OpenAL11CoreSDK.exe, I had some initial problems 'seeing' the InstallShield Wizard window, until I threatened to reboot !!! It offered to install it in the usual C:\Program Files\OpenAL 1.1 SDK, which I accepted …
Wow it was SLOW - I thought it had stalled … it eventually came back with a question - Do I want the help files integrated with Visual Studio NET?
More choices … I accept the default, hoping …
The next question was do I want to launch the redist installer … I choose NO for this …
It reported OpenAL 1.1 Core PC SDK [ver 3.03] installed … and finished …
Now in the 'OpenAL 1.1 SDK' folder I find libs\Win32\OpenAL32.lib, so that part is there … and in 'include' some headers … so maybe this is OK ???
But what about ALUT ??? Will find out later I suppose … and I did - I download ALUT, freealut-1.1.0-src.zip from the creativelabs site, and added this source build to my fgfs solution ...

It is ALSO possible to download the OpenAL source software, but for this you need to install GIT -
 http://code.google.com/p/msysgit/downloads/list … I chose Git-1.5.6.1-preview20080701.exe …
It installed in C:\Program Files\Git … I chose to NOT alter my PATH, but was able to run git.exe in 'bin' through a batch file …
From http://kcat.strangesoft.net/openal.htm the GIT respository was through -
prompt> git clone git://repo.or.cz/openal-soft.git openal-soft
and I think I got the source … maybe ??? I also downloaded the openal-soft-1.5.304.tar.bz2 … But for now will go with the SDK … and later learned, after changing into the open-soft directory -
prompt/open-soft> git pull origin
would do a source update. It has the problem in that it emits ANSI color escape sequences, but my standard console does NOT support these sequences, so the output includes these escape sequences ...  back to Update ...

top


Note 4: Warnings seen during build
Analyzing the warnings yields (approx) -

Count Warning Type
81 C4244 like '=' conversion 'time_t' to 'DWORD' possible loss of data
47 C4800 'unsigned int; : forcing bool (which is a char in WIN32)
44 C4101 unreferenced local variable
27 C4018 sign/unsigned mismatch
26 C4013 like 'uiuc_init_aeromodel' undefined; assume extern …
23 C4996 name is depreciated … use ISO conformant …
11 C4305 truncated from 'double' to 'float'
3 C4355 'this' used in base initialize list
2 C4715 not all control paths return value
1 C4554 '&' : check operator precedence; use parentheses to clarify
1 C4390 empty controlled statement; is this the intent?
Return to details ...

top


Note 5: UPD.BAT - Important Information:
The UPD.BAT attempts to check if everything has been built, and may exit with errors it finds. Obviously if it is not an error, then manually adjust UPD.BAT. It does a LOT of things, so is QUITE complicated.
One of the 'normal' errors are the OSG version numbers. OSG regularly updates three different 'version' numbers, and if UPD.BAT finds an error, it attempts to SHOW the new OSG version numbers.
It does a directory listing of the files it expected to find, and shows you their current version numbers.
If you have Perl installed, then it will run a perl script to also try to find the new numbers.
With this information you should be able to manually patch UPD.BAT near the top, with the new version numbers.
Further, by default it only 'installs' the Release version to the 'bin' folder. With an optional 'D' parameter, it will also install the Debug configuration. This debug section is less tested, so it it better you install the Release alone first, and if this is successful, then try the 'D' also if needed ...
Essentially ALL it is doing is copying MOST of the OSG DLL, both base and plug-in, as well as the FlightGear.exe, to the 'bin' folder for running ... back to build ...

top


Maybe it has something to do with the 'nasal' error shown in the console window -

  Model Author:  Unknown
  Creation Date: 2002-01-01
  Version:       $Id: c172p.xml,v 1.20 2008/09/01 15:14:33 torsten Exp $
  Description:   Cessna C-172
WARNING: JS: Failed to read joystick name from registry
FGMultiplayMgr - No receiver port, Multiplayermode disabled
loadxml: reading '../data/gui/dialogs/NTPS_target_task.xml' denied
 (unauthorized access)
Nasal runtime error: Dialog class: XML dialog must have <name>
  at ../data/Nasal/gui.nas, line 232
  called from: ../data/Nasal/gui.nas, line 217
  called from: ../data/Nasal/globals.nas, line 76
Nasal runtime error: container index not scalar
  at ../data/Nasal/gui.nas, line 219
  called from: ../data/Nasal/lead_target.nas, line 412
Initializing Nasal Electrical System
power up

The JS warning is understandable, since as far as I know, the name of the joystick is not written to the registry in Vista ... I have subsequently found some WIN32 code which will yield the 'name' of the joystick, and may try to get PLIB to accept it, if I get a chance ... see Joyinfo
But why the loadxml: say 'denied (unauthorized access)' is a mystery ... the file is there, and has normal attribute ... something goes wrong with the very convoluted way the file is checked - setting up a string in the properties, and using a tied function ??? ... I subsequently tried running in the Vista 'Administrator' mode command prompt, but  these 'nasal' errors still appeared on the default c172 - they do not appear for the UFO ... back to time table ...

top


EOP - fgfs-045b.htm

checked by tidy  Valid HTML 4.01 Transitional