20,741
edits
Howto:Optimizing FlightGear for mobile devices: Difference between revisions
Jump to navigation
Jump to search
m
Howto:Optimizing FlightGear for mobile devices (view source)
Revision as of 17:08, 7 August 2012
, 7 August 2012→Optimizing at the Source Code Level
| Line 186: | Line 186: | ||
To test the non-default code path, just start up with something like --prop:/startup/target=android | To test the non-default code path, just start up with something like --prop:/startup/target=android | ||
This is really just intended to get us started. Ideally, subsystem-specific switches would be added, so that all subsystems can be individually disabled or customized, analogous to how other subsystems like the AI traffic system can already be disabled purely from the command line. | This is really just intended to get us started. Ideally, subsystem-specific switches would be added, so that all subsystems can be individually disabled or customized, analogous to how other subsystems like the AI traffic system can already be disabled purely from the command line using a --prop:/foo/feature=true/false switch. | ||
Some possible candidates include: | Some possible candidates include: | ||
| Line 199: | Line 199: | ||
To check what else is initialized, see the "globals" files in $FG_SRC/Main: | To check what else is initialized, see the "globals" files in $FG_SRC/Main: | ||
* https://gitorious.org/fg/flightgear/blobs/next/src/Main/globals.cxx | * https://gitorious.org/fg/flightgear/blobs/next/src/Main/globals.cxx | ||
* https://gitorious.org/fg/flightgear/blobs/next/src/Main/globals. | * https://gitorious.org/fg/flightgear/blobs/next/src/Main/globals.hxx | ||
While disabling these systems can be fairly easily accomplished using ifdefs, care must be taken that FlightGear still builds properly and that no other systems are trying to access disabled subsystems at runtime, so this will involve repeated edit/build/debugging sessions using gdb. But that doesn't need to be done on the target device, it could just as well be completed on a conventional PC. | While disabling these systems can be fairly easily accomplished using ifdefs, care must be taken that FlightGear still builds properly and that no other systems are trying to access disabled subsystems at runtime, so this will involve repeated edit/build/debugging sessions using gdb. But that doesn't need to be done on the target device, it could just as well be completed on a conventional PC. | ||
It would probably make sense to introduce a custom template for optional subsystems, so that these can be easily made optional: | |||
<syntaxhighlight lang="cpp"> | |||
template <class T> | |||
class SGOptional : public SGPropertyChangeListener { | |||
public: | |||
protected: | |||
private: | |||
T _type; | |||
}; | |||
</syntaxhighlight> | |||
Just by overloading a bunch of operators, most of the existing source code would not need to be changed. | |||
So that globals.hxx could be directly changed accordingly. | |||
For example, instead of having this:: | |||
<syntaxhighlight lang="cpp"> | |||
// Global autopilot "route" | |||
FGRouteMgr *route_mgr; | |||
// ATC manager | |||
FGATISMgr *ATIS_mgr; | |||
// Navigational Aids | |||
FGNavList *navlist; | |||
FGNavList *loclist; | |||
FGNavList *gslist; | |||
FGNavList *dmelist; | |||
FGNavList *tacanlist; | |||
FGNavList *carrierlist; | |||
FGTACANList *channellist; | |||
</syntaxhighlight> | |||
One could use the new SGOptional<T> template: | |||
<syntaxhighlight lang="cpp"> | |||
// Global autopilot "route" | |||
SGOptional<FGRouteMgr*> route_mgr; | |||
// ATC manager | |||
SGOptional<FGATISMgr*> ATIS_mgr; | |||
// Navigational Aids | |||
SGOptional<FGNavList*> navlist; | |||
SGOptional<FGNavList*> loclist; | |||
SGOptional<FGNavList*> gslist; | |||
SGOptional<FGNavList*> dmelist; | |||
SGOptional<FGNavList*> tacanlist; | |||
SGOptional<FGNavList*> carrierlist; | |||
SGOptional<FGTACANList*> channellist; | |||
</syntaxhighlight> | |||
This would make it possible to neatly encapsulate optional subsystems, which could also be linked to a property listener - so that features could be switched on/off at runtime. | |||
It's also worth mentioning that base package files (XML, Nasal etc) may be trying to use disabled subsystems. | It's also worth mentioning that base package files (XML, Nasal etc) may be trying to use disabled subsystems. | ||