external: index
internal: update | preamble | folders | building | details | downloads | images | notes | next | end
2008-11-28: Update, including 'boost' dependency, see next page fgfs-047.htm, but much of this page is still relevant, and should be read, or at least scanned first!.
2008-11-11: Sort of an update. All of the following page is about building with MSVC9 (Microsoft Visual Studio C++ 2008 Express Edition), but I wanted to try build with earlier versions of MSVC, namely versions 6, 7.1, and 8, so have a new page, fgfs-046.htm (in development), for that ...
But in doing this I also incorporated some of the changes into my 'build set', so a new download set has been added. This also includes the new vc6dsw02.zip, which contains the DSW/DSP files to build flightgear with any version subsequent to MSVC6 ... sadly MSVC6 (circa 1998) itself fails - just too OLD ... Using this new DSW/DSP zip, I got a clean build, and was up and flying within about 2 hours!
2008-10-05: Update done, with a few minor folder changes, and to my batch files. The main folder change was to use the later 'lpng1232' source, from a downloaded ZIP file, and stopped chasing this version number in the work folders, and called the folder just 'lpng'. And I fixed one or two minor aberrations in my UPD.BAT batch file, and some others were 'improved' ... see new folders of this date, and newer downloads ...
For the first time I got some 'strange' errors during the OpenSceneGraph build using MSVC9, after creating the solution files with CMake 2.4 ... it seems to generate a target that does not exist, and ended with an error. It all cleared up when I ran CMake a 2nd time, generated the solution files gain, and reloaded MSVC9 and built (F7) ... then I got some 66 builds succeeded ;=)) I only built the Release version ... and was not present in later CMake 2.6 runs ...
As I suggest, my first FlightGear full build (Release) was without applying the vc9chg04.zip file, but found I still needed some fixes, so eventually unzipped it as well ... it is important you try to do without these 'fixes', just to see if the latest source already has a fix. The 'main' change is the location of 'al.h' ... it is expected to be in an AL folder, <AL/al.h>, but now that I am using the OpenAL SDK, that AL folder no longer exists ...
Even with all the small changes, I was flying within half-a-day, but of course that does NOT included all the source downloads, and updates ... Have FUN ;=))
2008-09-15: My last build was back in April, so this was overdue ;=(( Naturally I used my own TWO SOLUTION SYSTEM (TSS) ;=)) This original effort was spread over about 5 days, as other things interrupted, but the total time was about 1 full working day, excluding the original 'checkout' of the sources, but did include 'updating' the sources.
On building FlightGear, as Stefan recently put it - It's very simple: download, build, analyze errors, build missing 3rd party lib, repeat - and, for sure, this I agree is the basic strategy ... Here I have tried to build a fully automated system with batch files, and MSVC9 solution files, but it goes OUT-OF-DATE so quickly in an active environments like OSG and FG/SG ...
My batch files, and TSS depend entirely upon you creating the SAME directory structure as I have. Changing one means patching the main SETUPFG.BAT batch file, extracted form vc9sln02.zip, and usually lots of other things as well. And changes have a sort of ripple effect, and can be difficult to fully resolve downstream in the build ...
I have the disk space, and always COPY from what I call the SOURCE directory, and create a new WORK directory. If you include the FG data, after the build this work folder can occupy in excess of some 4.2GB, some 46,000 plus files, so make sure you have the space ... of course the FG data alone represents about 1.5GB, some 34,000 files, and that is ONLY the default 'base' download, but you do NOT have to really copy this, but then you must at least patch my flightgear run batch files, in bin/bats before flying ...
| 2008-10-05 | 2008-09-15 | ||
|---|---|---|---|
| SOURCE | WORK | SOURCE | WORK |
|
|
|
|
|
In simple terms, my SETUPFG.BAT batch file expects the directories as shown in the SOURCE column, in my case in a directory C:\FGCVS, and will CREATE the directories shown in the WORK, and copy the appropriate sources to the work, using the XCOPY command ... in my case I used a ROOT of work of C:\FG, and chose my new work to be 22, thus ran SETUPFG as -
C:\FG> setupfg 22
After SETUPFG has successfully run, change into the WORK and fully unzip vc9sln02.zip, with directories, overwriting any existing files, and you are ready for the build.
My prerequisites page may help you locate some of these sources, but some links may fall out-of-date - just use a Yahoo! search ...
The build process remains exactly as per my previous April, 2008 build, except for the treatment of OpenAL and alut, and can be summarized as :-
A: Download and install OpenAL SDK. Run oalinst.exe to INSTALL OpenAL32.DLL, and wrap_oal.dll, into $(SYSTEMROOT)\System32 folder. This, like the alut.dll copy mentioned in 14. below, requires administrator privileges.
B: In brief, the build steps are :-
*** AND YOU SHOULD BE FLYING ***
This was actually using MSVC8, in a modestly fast machine - XP SP3, in Dell Dimension DXP061, CPU: Intel Core 2 6400 @ 2.13GHz; 1GB RAM, 256MB ATI Radeon X1300PRO, but in general, it applies to _ALL_ version of MSVC later than version 6.
|
pre1 |
Update all the SOURCE, using CVS or SVN, as appropriate ... a few sources are via a 'tarball' or zip only. |
0:11 |
|
1. |
Download vc9sln04.zip and extract SETUPFG.BAT into root of WORK folder. In my case C:\FG |
0:02 |
|
2. |
Adjust SETUPFG.BAT to the ROOT of the SOURCE folder. The default is C:\FGCVS and requires no adjustment if this is used. |
0:00 |
|
3. |
Run SETUPFG.BAT, giving the WORK folder to be created, copy sources to a NEW work folder. (including 'data'). In my case >setupfg 26 |
0:21 |
|
4. |
Unzip the full vc9sln04.zip into the new WORK folder, using folder name, and overwriting existing files. In my case C:\FG\26 |
<:01 |
|
5. |
Unzip vc9cfg04.zip, preserving paths ... |
<:01 |
|
6. |
Unzip vc9chg04.zip, if any, preserving paths. As advised, this should be periodically checked to ensure _ALL_ changes are still required. |
<:01 |
|
7. |
Unzip vc6dsw02.zip and load fgfs/fgfs.dsw (or fgfs/fgfs.sln) in MSVC and allow conversion. I use fgfs/fgfs.dsw and allow conversion and [No] to load existing VC compatible project files. The DELSLNLIST.BAT can be used to 'rename' all the current VCPROJ files, then this 2nd dialog is avoided. |
<:02 |
|
8. |
Build just the libpng and zlib projects. I use Build -> Batch ... selecting both libpng, zlib, and alut, then [Build] |
<:03 |
|
9. |
Run CMake (2.6) on the OpenSceneGraph folder, selecting MSVC. Check [x] Show Advanced; set ZLIB include to C:\FG\26\zlib-1.2.3, and ZLIB library to C:\FG\26\zlib-1.2.3\zlib.lib; [Configure] again; set PNG include to C:\FG\26\lpng, and PNG library to C:\FG\26\lpng\libpng.lib; [Configure] again, the [OK] to build solution set. |
<:05 |
|
10. |
Load MSVC, and open C:\FG\26\OpenSceneGraph.sln, and build Release. Some 72 projects ... |
0:32 |
|
11. |
Reload MSVC fgfs.sln, and build the Release |
0:11 |
|
12. |
Unzip rfgbatsnn.zip, with folders ... these will be put in C:\FG\26\bin\bats |
<:01 |
|
13. |
In the MSVC command prompt, since it uses nmake, run UPD.BAT. |
<:01 |
|
14. |
Copy release alut.dll to $(SYSTEMROOT)\System32 folder, to join where the OpenAL32.dll, and wrap_oal.dll reside, if not done previously. |
<:01 |
|
15. |
cd bin\bats, and try the rfgufo, rfg, or any of the other batch files available |
<:01 |
|
*** AND YOU SHOULD BE FLYING *** ;=)) |
||
|
TOTAL TIME TO FLIGHT : (approx.) |
1:30 |
|
This above table was only the 'Release' configuration. Building the Debug configuration took
another hour or so ... then, if I wanted I could do, in a MSVC command prompt :-
C:\FG\26\upd d
to copy all the DEBUG DLLs to the bin folder, ready to RUN the Debug version ...
This first process first took me a good working day to complete - it had been a good 5 months so there were many changes. 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, to build, research errors, fix errors, and continue building - repeat ...
If you do NOT want to read all this detail, then skip it ...
As can be seen above, after getting all the sources fixed, and the new DSW/DSP files, it actually took about 1.5 hours to do the Release build in another machine. And about 1 hour more for the Debug build.
| 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. | 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 … | 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 ;=)) | |||
| 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 ;=)) This detailed account has also been repeated on the fgfs-045b.htm page ...
This first, vc9sln04.zip contains my TSS solution
files, and other thing, and fgvc9rt04.zip contains the binary executable FlightGear.exe,
and all the DLL needed to run it, including OpenAL32.DLL, wrap_oal.dll, and alut.dll, in
OpenAL-04.zip. 03 and 02 are earlier versions ...
Take care downloading and running executables from the web ...
| Date | Zip | Size | MD5 |
|---|---|---|---|
| Version 2008-11-11 | |||
| 11/11/2008 | vc9sln04.zip | 204,977 | 1f39ef59239429f0f4565b0cdac2dcb4 |
| 11/11/2008 | fgvc9rt04.zip | 5,623,491 | 8e1b4987ea59e3fb87ea62019f352eeb |
| Earlier Versions | |||
| 05/10/2008 | vc9sln03.zip | 133,205 | ebb95f780bf8541fc71b6ef2e4be92cc |
| 05/10/2008 | fgvc9rt03.zip | 5,315,369 | 42fe24624657ab4e612d22e6854af975 |
| 17/09/2008 | vc9sln02.zip | 131,343 | 897de5480d5edb1c8be7fe1a69c5338a |
| 17/09/2008 | fgvc9rt02.zip | 5,225,994 | 541ef5870036f938ca70f6c5eeed2557 |
PS: This page was updated 12 November, 2008, 5 October, 2008, and 17 September, with corrected solution files, and new binaries. Ensure you use these latest updated zip files, especially if you by chance downloaded the 15 Sep files, which failed to build the Debug configuration. I have learned I should NOT try to manually fiddle with MSVC9 solution files ;=))
This is NOT recommended, but quite a few have asked for it. This is a COMPLETE zip of ALL the sources used to build the above. Remember this is only the SOURCE folders, EXCLUDING FlightGear\data. The base data must be downloaded from the FG site. And then vc9sln04.zip must still be downloaded, and the extracted SETUPFG.BAT used to create the WORK folder, and then the vc9chg04.zip and vc9cfg04.zip applied to it, etc, etc, as above ... before the build ...
It is LARGE - 15MB - It is STALE - fixed as of this date. You should download and use the LATEST sources, which is EASY, per my prerequisites page ... this is ONLY for LAZY, STALE people ;=))
| Date | Zip | Size | MD5 |
|---|---|---|---|
| 11/11/2008 | full source 02 zip | 16,702,979 | 99ad559d874f4938de969deeec5728c2 |
| 05/10/2008 | full source 01 zip | 16,635,824 | e5b984aedec41d45517d28f3dc72f10c |
In fact, I am sure using this will still be a problem for some. Remember, it is STALE sources, and can NOT be later updated with CVS/SVN, etc. I will always HELP if you do the proper source downloads, but certainly do not bother to write to me about any problems using this STALE source!
| Downtown SF with the bridge in the background using UFO. | The carrier, with other vessels, outside SF, using UFO. | |
|
|
I had a strange problem with the panel of the default Cessna and Concorde, but F18 looked ok
...
Do not know what is the difference, nor the problem ...
In the Cessna, this is the 3D panel, and toggling the 2D panel is also blank!
But after a data folder update, source folder update, and complete rebuild, it came out right
;=))
This is better, but the radio stack and the Concorde stayed all blank???
But later, in another machine, the radio stack appeared ;=)), with a nice setting sun, and
relatively new yellow signs
These signs appear to be in on the taxiway!
Close up to one of the parked aircraft
And this is an odd view, from about 100,000 feet up in the UFO looking straight down, all clouds cleared, in the 'base' scenery package, exactly over KSFO - it shows the 'square' extent of the tiles loaded ... the light blue 'border' is where there is NO scenery tile have been rendered, even though they may have been loaded :-
This could be considered a sort of a 'feature' of the tile loader, since all scenery outside this square has not been displayed, probably due to the 'distance' - and actually this block 'disappears' completely if you rise above about 104,000 feet.
Of course, for some parts of the area there is no scenery since this is just the scenery blocks of the 'base' package of :-
C:\FG\26\data\Scenery\Terrain\w130n30\w122n37 and w123n37
You have to go to -
http://www.flightgear.org/Downloads/scenery-1.0.0.html
This is the graphical interface for version 1.0.0, but may be there will be 1.0.1 or better by
the time you do the download ... it is in 10x10 degree chunks. These 'chunks' ranges from about
1K up to 170MB, depending on the content, so make sure you have the space and time for the
downloads ...
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 ...
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 ...
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
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 ...
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 ... | ||
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 ...
Extra:
I purchased and use WinZip, and its command line interface for most 'zip' type files, but this
version 9 I have does not handle certain files. For example, for a command line tool to unpack
*.bz2 files, among others, I downloaded the 7-Zip command line tool. I downloaded the
7za460.zip, using Vista native zip extraction to get 7za.exe, which I place in a directory
in the PATH environment variable ... I have a special simple place for all these command
line tools call C:\MDOS, which I added to my PATH ...
As my update of 11/11/2008 states, I have now generalized this build process by reverting to using MSVC6 DSW/DSP files, so it can support _ALL_ versions of MSVC later than MSVC6 - OSG, SG, and possibly FG, can no longer be fully compiled with MSVC6 - but these DSW/DSP files can be 'converted' by MSVC7.1 (2003), MSVC8 (2005), MSVC9 (2008), and hopefully even later versions, to their own formats ... vc6dsw02.zip is now included in the above vc9sln04.zip ...
I still have to work harder on my fgam2dsp.pl, and sln2dsw.pl perl scripts, and they take real time to fully debug given what they are trying to do is sort of undocumented ... this will allow me to keep the DSW/DSP set more up-to-date ... but we will have to see how the time pans out ...
EOP - fgfs-045.htm
