Howto:Optimizing FlightGear for mobile devices: Difference between revisions

Jump to navigation Jump to search

Howto:Optimizing FlightGear for mobile devices (view source)

Revision as of 10:29, 16 August 2012

2,876 bytes removed ,  16 August 2012
→‎Optimizing at the Source Code Level
Line 209: Line 209:
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:
To see how this can be done using a class template and listeners, please have a look at [[FlightGear Run Levels]]
<syntaxhighlight lang="cpp">
template <class T>
class SGOptional : public SGPropertyChangeListener {
public:
SGOptional(const char* p) : _toggle_switch(p) {
  fgAddChangeListener(p, this);
  valueChanged(); // pick up initial property value (i.e. --prop args)
}
 
void valueChanged() {
// enable/disable system, call notification callbacks, set properties and allocate/free memory
}
 
void startup_dependencies() {
// set properties to startup dependencies (if not initialized already)
}
 
// TODO: add one method to manage the refcount for dependencies (allocation/deallocation)
 
protected:
private:
SGPropertyNode_ptr _toggle_switch;
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.
 
The initialization code in fg_init.cxx would then need to be adapted to delegate subsystem initialization to corresponding SGOptional<T> specialization, which would make this dependant on a property switch:
 
<syntaxhighlight lang="cpp">
    ////////////////////////////////////////////////////////////////////
    // Initialize the sound subsystem.
    ////////////////////////////////////////////////////////////////////
    // Sound manager uses an own subsystem group "SOUND" which is the last
    // to be updated in every loop.
    // Sound manager is updated last so it can use the CPU while the GPU
    // is processing the scenery (doubled the frame-rate for me) -EMH-
    globals->add_subsystem("sound", new SGOptional<SGSoundMgr>("/enable/sound"), SGSubsystemMgr::SOUND);
</syntaxhighlight>
 
It's also worth mentioning that base package files (XML, Nasal etc) may be trying to use disabled subsystems, so this needs further care.


Potential pitfalls are also discussed at [[FGCanvas#Open Issues]].
Potential pitfalls are also discussed at [[FGCanvas#Open Issues]].
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/53022"

Navigation menu