User:Callahanp/Flightgear and Simgear Code/From Command Line to Holding Short
0
This page covers initialization in flightgear, from the command line through the Splash Page to the first frame of the aircraft in position.
I started by stepping through bootstrap and other modules until flightgear is up and running. I'm made some notes, organized by source code file and function. The result is the information below.
It is also important to know that this is an area that as of March 2018 is under active discussion on the mailing list. See Edward d'Auvergne's e-mail on testing
a
From Command Line to Holding Short
When you start flight gear, several activities take place
* logging is set up * command line arguments are checked, read and saved * a global object is created to hold state and references to managing functions of several types * a tree of properties is built on the global object * various static objects are created and initialized * scenery data is downloaded using terrasync * airport and aircraft data is scanned and made available * scenery data is read and made available * an interpreter is started * connections to multiplayer servers are made * a scene is established as a "view" with scenery, Airport data and the Aircraft * an event loop is started to finish the initialization, display a splash screen. The event loop then shows the first frame and then adjust the view as time goes on, based on changes in controls, weather, aircraft position, speed, attitude and time.
That's a lot, but the orchestration of all this activity takes place in just a few code files and functions in those files.
- Overview will trace functions that provide significant functionality to the Simulator until the aircraft is shown holding short or parked somewhere. only the module's source file-path and a brief explanation or list of the functions used in the "path".
Overview
Just to get oriented a little, I'm going to list the top-level routines in the path to holding short. Initialization happens in four stages, Some stages have very little in them, others have multiple phases and many subsystems to initialize.
Startup Stage | Module | Routine Signature | Brief Description |
---|---|---|---|
1. | Main/bootstrap.cxx | int main(int argc, int char **argv ) |
main() is the first of four stages of initialization in Flightgear. The first stage ends when main() calls fgMainInit(argc, argv) main contains the initial entry point and final exit point for the Flightgear application. It initializes things that have to be done early on and decides if we're starting the full application or just a viewer, then calls fgviewerMain(argc, argv) or fgMainInit(argc, argv). We'll skip the viewer and focus on fgMainInit. |
2. | Main/main.cxx | int fgMainInit( int argc, char **argv ) |
fgMainInit continues with about 20 individual initializations. fgMainInit is only the second stage of initialization. It ends with an open but blank window, and a call to fgOSMainLoop(); |
3. | Viewer/fg_os_osgviewer.cxx | int fgOSMainLoop() |
fgOSMainLoop doesn't do initialization itself. fgOSMainLoop is the main loop for the full duration of the flightgear session. It's amazingly brief, Just four C++ statements on 12 lines of code. The loop has just two tasks: Think of them as "set up what has to be displayed" and "display it". During initialization, the setup task is initialization. The second task displays the splash screen, messages produced by the initialization and something that moves to indicate that the program is still working. Then, after initialization, the setup part of the loop does the calculation work needed for the next frame of the simulation. The display task then uses that data to show the simulation on the screen. fgIdleFunction does the initialization work. fgMainLoop() handles the events and calculations for the ongoing simulation. These are called through a pointer named *idlefunc. The display part of the loop is the same for both of these "setup" functions. fgIdleFunction is the third stage of initialization. During this stage, fgOSMainLoop calls fgIdleFunction repeatedly through *idleFunc. Each call to fgIdleFunction does a different part of the initialization. In between, the splash screen is being updated, showing which part of the initialization is in progress, and a moving progress bar to show that "something" is happening. When the third stage is complete, *idleFunc is set to point to fgOSMainLoop. |
3. | Main/main.cxx | static void fgIdleFunction ( void ) |
fgIdleFunction handles all the third stage initializations in a number of phases. It's main work is the initialization of subsystems. It's called many times, and each phase may do one or many initializations. There are quite a few and it takes a while. When fgIdleFunction reaches its last initialization state, it calls registerMainLoop() to change *idleFunction to point to fgMainLoop. Once fgIdleFunction has completed its work it is not run again unless you do a reset, but the routine that called it, fgOSMainLoop continues to run. |
4. | main/main.cxx | fgMainLoop | fgMainLoop does not contain a loop, its running under the loop in fgOSMainLoop and will continue to run in that loop until you reset or exit flightgear. fgMainLoop handles the fourth and final stage of initialization, waiting on the loading of scenery, the airport and the aircraft data. All the final initialization work is handled by subsystems loaded in stage three. Until all subsystems are fully initialized, the splash screen continues to be displayed. Once they're all ready, the subsystems continue to run, and we find ourselves in position at an airport and ready to fly. |
After initialization all of the subsystems needed to fly will continue to be invoked as needed by fgMainLoop, which is run repeatedly in the actual loop in fgOSMainLoop.
At first glance, one might think that the naming of things in this part of Flightgear is a bit off. The names might have made sense at one point in the early development of Flightgear, but things have changed and some functionality moved, but the names were not changed. So we end up with things like fgMainLoop that does not contain a loop. Does it matter? Probably not. There's other work to do that's more important. My guess is that we just need to know how this loop works and most of the time our attention will be much further down the call stack, inside one of those sub-systems.
Question:
What in the code finally recognizes that we're ready to display the scene in stage 4?
Are the final initializations done by subsystems done in any particular order?
Is what's above this point enough to know about startup and initialization?
FGcommands.cxx and fg_scene_commands.cxx contains a number of static functions not called from c++. are these only called from Nasal? Is that why they are missing from the .hxx?
Do we need to show some examples of property nodes?
Would a list of functions contained in each of the modules in src/Main be of any use? For example: fgCommands.cxx
- static inline SGPropertyNode * get_prop (const SGPropertyNode * arg, SGPropertyNode * root)
- static inline SGPropertyNode * get_prop2 (const SGPropertyNode * arg, SGPropertyNode * root)
- static void split_value (double full_value, const char * mask, double * unmodifiable, double * modifiable)
etc
would the same list with a note on its purpose and usage be of help? fgCommands.cxx |
function signature | Description |
---|---|
static inline SGPropertyNode *
get_prop (const SGPropertyNode * arg, SGPropertyNode * root) |
. gets property[0] |
static inline SGPropertyNode *
get_prop2 (const SGPropertyNode * arg, SGPropertyNode * root) |
gets property[1] |
static void
split_value ( double full_value, const char * mask, double * unmodifiable, double * modifiable) |
Get a double value and split it as required. |
static void
limit_value (double * value, const SGPropertyNode * arg) |
The material below are detailed notes from an initial look at the main loop. They're just lists of what gets done where. Would a new developer just read the actual functions and make their own notes? |- | Clamp or wrap a value as specified.
Module | colspan="3" | Description & Steps | |
---|---|---|---|
src/Main/bootstrap Main | Bootstrap provides the top level of the stack for executing either fgviewerMain or fgMainInit.
|
|
|
src/Main/Main | fgMainInit( int argc, char **argv )
|
|
|
viewer/fg_os_osgviewer.cxx | fgOSMainLoop()
|
here's the loop:
| |
Main/main.cxx | fgIdleFunc
|
|
Note fgResetIdleState() sets the state to 2000 and re-registers fgIdleFunction as the idle handler. |
Main/main.cxx | We seem to have arrived. We're at the hold short point. |
Minor functions on the Path to Holding Short
sglog().setLogLevels( SG_ALL, SG_INFO )sglog().setStartupLoggingEnabled(true); || /simgear/debug/logstream.cxx || Pretty obvious what this does. || What does sglog() actually return?
Module | Description | Steps |
---|---|---|
src/Main/globals | Provides a global object to contain references to objects and data needed in initializing, running and terminating flightgear |
|
<boost/foreach.h> | Example | |
<algorithm> | Example | Example |
std::string version(FLIGHTGEAR_VERSION) | ||
sg_srandom_time(); | ||
src/Main/Main.cxxfgInitConfig | ||
src/Main/Main.cxx Launcher | ||
src/Add-ons/AddonManager.cxx | addons::AddonManager::createInstance() | |
initFlightGearEmbeddedResources | see file build/flightgear/src/EmbeddedResources/FlightGear-resources.cxx,automatically generated by fgrcc | |
viewer/fg_os_osgviewer.cxx fgosinit(int* argc, char** argv) | ||
Main/fg_os_common.cxx | fgRegisterIdleHandler( & fgIdleFunction | |
detectSIMD() | bootstrap.cxx | returns true if the cpu supports sse2. |
gethostname(_hostname, 256) | unistd.h glibc | returns the hostname of your computer |
signal(SIGPIPE, SIG_IGN) | signal.h | directs SIGPIPE to the SIG_IGN signal handler - Portability: use sigaction() instead |
signal(SIGSEGV, segfault_handler) | signal.h | Flightgear formats the message with a backtrace and exits with std:abort() |
segfault_handler (int signo) | bootstrap.cxx | |
initFPE(flightgear::Options::checkForArg(argc, argv, "enable-fpe")) | main/options.cxx bootstrap.cxx |
checks the command line arguments for the enable-fpe option. Calls InitFPE with the result. see bootstrap.cxx for more details |
signal(SIGFPE, handleFPE) | signal.h bootstrap.cxx |
We handle Floating Point Exceptions |
setlocale(LC_ALL, "") setlocale(LC_NUMERIC, "C") setlocale(LC_COLLATE, "C") |
||
return fgUninstall() | fg_init.cxx | Command line options are checked to determine if uninstall should be called. |
sglog() | /simgear/debug/logstream.cxx | This initializes the log. see logstream.cxx for details |
std::set_terminate(fg_terminate); | <exception> bootstrap.cxx |
sets the standard template library terminate routine |
atexit(fgExitCleanup) | stdlib.h bootstrap.cxx |
registers the given function to be called at normal process termination, either via exit(3) or via return from the program's main(). Functions so registered are called in the reverse order of their registration; no arguments are passed |
fgviewerMain(argc, argv) | flightgear/Viewer/fgviewer.cxx | see viewer topics for details. This is called in bootstrap.cxx if the command line arguments include --viewer |
fgMainInit(argc, argv) | Main/main.cxx | Starts to initialize flightgear. This is called in bootstrap.cxx if command line arguments do not contain --viewer |
catch block | various | termination for most or all errors. Read the end of bootstrap.cxx for more information |
flightgear::shutdownQtApp() | bootstrap Qt |
Done separately from atexit. see bootstrap.cxx for more information |
crInstall(&info) crUninstall() |
CrashRpt.h | #if defined(HAVE_CRASHRPT). This only happens on windows. |