User:Callahanp/Flightgear and Simgear Code/From Command Line to Holding Short: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
This page covers initialization in flightgear, from the command line through the Splash Page to the first frame of the aircraft in position. | |||
I | I started by stepping through bootstrap and other modules until flightgear is up and running. | ||
I'm | I'm made some notes, organized by source code file and function. The result is the information below. | ||
====From Command Line to Holding Short==== | ====From Command Line to Holding Short==== | ||
{{See also|Talk:Initializing_Nasal_early#Existing_Initialization_Scheme}} | {{See also|Talk:Initializing_Nasal_early#Existing_Initialization_Scheme}} | ||
When you start flight gear, several activities take place | When you start flight gear, several activities take place | ||
Line 24: | Line 22: | ||
* 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. | * 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. | |||
{| class="wikitable" | |||
|- | |||
! Startup Stage !! Module !! Routine Signature !! Brief Description | |||
|- | |||
| 1. || Main/bootstrap.cxx || int main(int argc, int char **argv ) | |||
| | |||
main contains the initial entry point and final exit. 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. | |||
the main function ias the first of four stages of initialization in Flightgear. The first stage ends when main calls fgMainInit(argc, argv) | |||
|- | |||
| 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 initializations itself. In fact it is still around for the full duration of the flightgear session. After marshalling initializations, including those for subsystems, it calls the fgMainLoop. fgMain lowhere is responsible for the third stage of initialization. While its doing initializations it displays the splash screen and messages. Once that's done, it continues sd a driver for everything that happens afterwards. It's amazingly brief, Just four C++ statements on 12 lines of code. | |||
During Initialization Stage 3, fgOSMainLoop calls a routine to do initializations through a pointer, *idleFunc. During Stage 3, *idleFunc points to fgIdleFunction. | |||
Initializations are done by repeatedly calling fgIdleFunction through the *idleFunc pointer. | |||
|- | |||
| 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 work is handled by subsystems loaded in earlier stages. The subsystems continue to run after all that's done, and we find ourselves in position at the airport and ready to fly. | |||
|} | |||
After initialization all of the subsystems needed to fly will be invoked as needed by fgMainLoop, run repeatedly in the actual loop in fgOSMainLoop. | |||
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? | |||
|- | |||
| | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
! Module | ! Module | ||
! colspan="3" | Description & Steps | ! colspan="3" || Description & Steps | ||
|- | |- | ||
| src/Main/bootstrap Main | | src/Main/bootstrap Main |
Revision as of 02:40, 18 February 2018
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.
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 contains the initial entry point and final exit. 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. the main function ias the first of four stages of initialization in Flightgear. The first stage ends when main calls fgMainInit(argc, argv) |
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 initializations itself. In fact it is still around for the full duration of the flightgear session. After marshalling initializations, including those for subsystems, it calls the fgMainLoop. fgMain lowhere is responsible for the third stage of initialization. While its doing initializations it displays the splash screen and messages. Once that's done, it continues sd a driver for everything that happens afterwards. It's amazingly brief, Just four C++ statements on 12 lines of code. During Initialization Stage 3, fgOSMainLoop calls a routine to do initializations through a pointer, *idleFunc. During Stage 3, *idleFunc points to fgIdleFunction. Initializations are done by repeatedly calling fgIdleFunction through the *idleFunc pointer. |
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 work is handled by subsystems loaded in earlier stages. The subsystems continue to run after all that's done, and we find ourselves in position at the airport and ready to fly. |
After initialization all of the subsystems needed to fly will be invoked as needed by fgMainLoop, run repeatedly in the actual loop in fgOSMainLoop. 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?
|- |
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. |