FGRun with MSVC7 2005/01/28

FG-MSVC6 - FG-MSVC7 - UFO - ATLAS ( At 1 - At 2 - At 3 ) - OTHERS - Favourites - Home

Others 1. fgrun [sourceforge.net/projects/fgrun] - If you are not 'good' with zillions of command line parameters, then this little doozy does what the name implies. It 'configures' and executes FlightGear, after you have 'selected' the options in a GUI interface ... looking at the 'command line' it produce, really helps understand the mass of options ... most of which I place in my 'set' of 'system.fgfsrc', in the FG_ROOT (--fg-root=path) folder ...

Building fgrun, with MSVC7

Prerequisites - 6

1. fltk [http://www.fltk.org/] - The Fast Light Toolkit - FLTK 1.1.x is the current stable release branch. FLTK 2.0 is currently in development and available via CVS ... here, I use FLTK 1.1.6, as a static WIN32 COFF Intel archive (library) ...

2. GLUT [www.opengl.org/resources/libraries/glut.html] - The OpenGL Utility Toolkit - Since this applies to ALL sources that use GL, this is the only 'installed' DLL library ... that is, glut32.dll is copied to c:/WINDOWS/system32 folder, glut.h to '"VC++ path"/include/GL' folder, glut32.lib to '"VC++ path"/lib' folder. I have not found the need to 'copy' glut.dll anywhere ... this 'permanently', and 'globally', 'installs' GLUT in your system, and you will begin 'forgetting' it is there ;=))

3. OpenAL (AL) [http://www.openal.org/] - Cross-Platform 3D Audio - I use a CVS download, and update ...load OpenAL.sln ... change 'Runtime Libraries:', of each project, each configuration, to 'Multi-threaded Debug', 'Multi-threaded', resp. ... had 'problem' with post build event first time through ... simply repeat the build, again, and again ... running OpenAlDemo produces some 'interesting' noise, from my speakers ;=))

4. SimGear - [http://simgear.org/] - Simulator Construction Tools - CVS update ... Here is a 'brief' readme.msvc.txt

5. zlib - [http://www.gzip.org/zlib/] - A Massively Spiffy Yet Delicately Unobtrusive Compression Library
(Also Free, Not to Mention Unencumbered by Patents)
- have not tried the current release 1.2.1 - using the 1.1.4 downloaded with SimGear ... but the later version should work ... I must find time to try it ...

6. PLIB - [http://plib.sourceforge.net/] - STEVE'S PORTABLE GAME LIBRARY. - I use CVS, but note the latest stable version of PLIB is 1.8.4 ...

 

1. fltk

I first tried fltk-2.0.x, doing a cvs download, and updating 'regularly', but have not been able to get it compiled and linked, with MSVC7 ... nearly got there, but some 'idiot', seemingly small thing, caused the build to 'fail' ... will keep trying ...

I think I saw a 'reference' to fltk-1.1.4, but I downloaded fltk-1.1.6, dated 30/11/2004 03:06 AM 3,073,432 fltk-1.1.6-source.zip file ... it was a 'little' tough to get compiled, and linked, without trauma ... ;=)) I defined, for the fltk project, (static WIN32 library), 'FGFS', and 'modified' the following pre-compiler 'switch' block ... in FL_Win32.cxx, which is 'included' in FL_x.cxx ...

//#if !defined(__GNUC__)
#if ( !defined(__GNUC__) && !defined(FGFS) )
# define USE_TRACK_MOUSE
#endif // !__GNUC__
... sort of, if GNUC can 'live' without 'TrackMouseEvent', then so can I ... ;=))

I also changed, at least the 'fltk', and 'fltkgl' projects to build for Debug, 'Multi-threaded Debug (/MTd)', from the 'default' I found of 'Multi-threaded Debug DLL (/MDd) ... this avoids 'Dll Hell', and zillions of 'complaints' from the linker, when linking fgrun with fltkd.lib ... You can choose 'any' 'Runtime Library', but you must be 'carefully' consistent with all 'parts' ...

MSVC7 solution, 'fltk' build, uses the 'change-name-copy-to-single-folder' technology ... this works well, if 'someone' has done all the correct, relative, setup work ... this has been done here, with the Debug configuration having a 'd' appended to its name ... the two 'fltk' static WIN32 libraries needed for fgrun are fltkd.lib and fltkgld.lib, so you really only need to build these two ... or all projects, if you have the need to explore further .... 'fltk' build copies the libraries to the relative fltk-1.1.6\lib folder ...

My final 'Preprocessor Defintions' was -
WIN32,_DEBUG,_WINDOWS,WIN32_LEAN_AND_MEAN,VC_EXTRA_LEAN,WIN32_EXTRA_LEAN,FGFS
note the ',FGFS' at the end ...

 

Building fgrun.exe

Warning: This is a MSVC7, WIN32, non-cygwin, port. It does not use pthread.h ;=(( It does not need the runtime cygwin DLL ... it does involve code changes ... its behaviour is not exactly that of the 'official' release ...

When I loaded fgrun.sln, I got the 'version' dialogue, to which I always click 'Yes' ... really, what else are you going to do? ... I am using Microsoft Visual C/C++ .NET 2003 ... so not too sure what the 'version' was ...

The source solution used a DLL approach, so there were a few things to 'amend', to use static WIN32 COFF libraries (archives) ... and had 'modified' the SimGear build, by 'creating' a simgear_d.lib ... whereas, my SimGear build uses the MSVC defaults of SimGear.lib, for both the Debug and Release configurations, but they are placed in their respective Debug and Release folders ... so can be 'separately' included ... see above for the 'Multi-threaded Debug (/MTd)' configuration ...

I also 'created' a new compiler switch - USE_PTHREAD_H ... one could use !'__CYGWIN__' ... to de-compile the pthreads stuff ... why a 'launcher' application would need to 'spawn' or 'fork' a 'thread', I am not sure ... Personally, I like the 'fgsd' approach on this ... to have a colourful, and interesting progress bar, while databases are loaded ... up front ...

So, in wizard.h, I put the 'th' in a block like -
#ifdef USE_PTHREAD_H
pthread_t th;
#endif // #ifdef USE_PTHREAD_H

and -
#ifdef USE_PTHREAD_H
#include <pthread.h>
#endif // #ifdef USE_PTHREAD_H

and, in wizard_funcs.cxx -
#ifdef USE_PTHREAD_H
int err = pthread_create( &th, 0, &Wizard::startFlightGear_cb, (void *)this );
#endif // #ifdef USE_PTHREAD_H

But I need this 'removed', to be able to run fgrun without 'installing' the cygwin DLL, or any other DLL not already needed for FlightGear, for that matter ... ;=))

Since I had compiled, linked, and run fgrun previously, it picked up those 'previous' preferences, on the first run ... a fg-root place where the 'newer' X-plane format apt.dat.gz does not reside ... I had to 'modify' the code in -
void AirportBrowser::load_runways( const string& path, Fl_Callback* cb, void* v ) {
has the code, after -
gzf_ = gzopen( path.c_str(), "rb" );

-
 if (gzf_ == 0) { throw "gzopen error"; }
-

At that time, there appears no 'try' active, so I got a
'First Chance' exception with a zero gzf_, in the -
while ((c = gzgetc(gzf_)) != -1 && c != '\n')

+
if (gzf_ == 0) {
cout << "gzopen error: Can not open " <<
path << "...!\nCheck fg-root command parameter ...,\n" <<
"go back to page 1, and fix the fg-roots..." << endl;
return; // out of here, with no airport file ... no big deal, yet ...
}
+

and was greatly pleased, to see my 'previous' selection ... last time I used fgrun ... the 'ufo' aircraft ... spinning quietly in the preview window ... tis great stuff ... thank you ...

Zoot, when I back up, to 'correct' for the new fg-root value, the 'edit' box text is being 'monitored' ... but to monitor it, it seems the service 'selects' the text ... to get a 'copy' probably ... but does not 'deselect' it, as it was ... ok, that happens when 'coincidently' what I have partially entered, is in fact a valid FG root folder ... an 'annoying' feature, but can be got 'around' with care ...

Although, I had to 'wait' while the airports were loaded, this is normal ... I changed a few options, and clicked [ Run ] ... the 'running' dialog came up ... but after that all-was-frozen ... I had to do a 'kill process' to get out ... FG started running ... is that what 'threads' does - does the 'exit? ... must look ... ;=))

Yep. Needed a few more 'switch' blocks -

run_win32.cxx
#ifdef USE_PTHREAD_H
WaitForSingleObject( pi.hProcess, INFINITE );
...
CloseHandle( pi.hThread );
#endif // #ifdef USE_PTHREAD_H

wizard_funcs.cxx
#ifdef USE_PTHREAD_H
int err = pthread_create( &th, 0, &Wizard::startFlightGear_cb, (void *)this );
exec_launch_window();
#else // !#ifdef USE_PTHREAD_H
startFlightGear_cb(); // kick FG into gear
#endif // #ifdef USE_PTHREAD_H y/n

That should be it ... it works well ... passing a 'giant' command line to the FG executable ... FG flew ... what a great launcher ...

I am developing, very slowly, a new parachutist FDM ... freefall stuff ... and wonder how fgrun can accept a new 'option' ... ok, the fdm 'choice' list is hard coded -
Fl_Menu_Item Advanced::menu_fdm[] = {
{"ada", 0, 0, 0, 0, 0, 0, 12, 56},
... balloon, external, jsb, larcsim, magic, network, null, ufo, yasim ...
{0,0,0,0,0,0,0,0,0} };
so, to add a 'new' FDM, fgrun must also be coded, and re-compiled ... is there any other way? I do note, that the 'command line' to run FG includes 'everything-everytime' ... certainly do not like this 'brutal' approach ... but do understand the difficulty of maintaining such a long list of options ... should fgrun read options.htm? ...

fgrun, runs well, and certainly takes lots of the 'pain' out of setting 'options' ... rather than only as a 'launcher' of FG, why not as a 'configuration wizard' ... it could just write, say 'different' system.fgfsrc files, and keep track of them, under 'different' user given names, like 'UFO at Sydney 25', '747 over Dubbo', etc ... thus I would use it as a 'convenient' GUI interface, very helpful, if it is kept up-to-date ... it could still have an 'execute' button, with FG run, with a minimum of command line parameters ... 

Its most powerful feature is that it gives a 3d animated 'preview' of the aircraft ... if only it could 'cause' a running FG application to 'switch' aircraft (panel) and/or fdm, on the fly, so to speak ... ;=)) Can only 'wish' ...

At this time, Jan 2005, this source is under going rapid change ... when it settles down ... gets a users base, to gets some user 'preference' feedback ... it can be a great GUI front end for FlightGear

Warning: This is a MSVC7, WIN32, non-cygwin, port. It does not use pthread.h ;=(( It does not need the runtime cygwin DLL ... it does involve code changes ... its behaviour is not exactly that of the 'official' release ...

 

index