Plan-zakalawe: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (add category: core dev projects (to make it easier for people to find ongoing projects))
m (http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39018.html)
Line 62: Line 62:




[[Category:Developer Plans]]
[[Category:Core development projects]]
[[Category:Core development projects]]

Revision as of 12:53, 22 December 2012

Task List

Short term plans

Areas

General areas I'm working on, or planning to work on


Core properties and subsystems

  • Create a property benchmark (reading / writing / tied properties / listeners)
  • Create a prototype multi-threaded property implementation (see Property threading)
    • Track per-thread property state
    • Synchronise property tree structure changes (adding / removing nodes)
    • Define synchronisation points between threads to update property data

GUI / renderer

  • Migrate PLIB GUI into our source tree, and convert to a set of custom OSG drawables
    • Convert event handling code to use OSG event adapters natively
    • Ensure all state changes occur via update callbacks, and hence mark the GUIs as static
    • Replace puValue with an SGProperty? i.e allow widgets to be directly bound to a property node
    • Convert all text display to use osgText drawables
    • Make layout support native to widgets?
  • Convert '2D' panel node to manage its own picking (removing the currently ugly hack for 2.5D panels)
  • Make the pure 2D panel am FGPanelNode attached to the GUI camera
  • Convert 2D panel text to use osgText
  • Clean up renderer scene (especially the GUI camera children) once all its children are nodes which manage their own picking

FGPositioned

  • Re-investigate caching data in a binary format to accelerate startup time (avoid reading nav.dat, apt.dat on launch, and scenery airport data repeatedley)
    • Need to cache stat() values for scenery airport data, but SimGear contains code for this now, and this will make the map dialog and GPS function better, since the first access of airport runways won't be as slow.
    • Decide persistence scheme for spatial data, probably an 'index string', three bits per octree layer. For a 64-bit value this would give 21 octree levels, which is ample for the purposes of loading.
    • Hook the min / max type ranges on filters to avoid excessive loads
    • Don't worry about un-loading in the first instance, since the actual memory usage is not a concern (given that the current sim loads all items permanently!)

GPS / FMS / Route-planning

  • Extend the GPS code to support more flight-plan functions and en-route information
    • Climb/descent computations, based on some aircraft performance data
    • Compute distances along the route path, including as offsets from any waypoint (this will allow aircraft authors to compute sane top-of-climb / top-of-descent locations, for example)
  • Allow performance data to be specific per-aircraft
    • Initially, basic information such as cruise speed, best climb rates, and so on
    • Weight/balance tables
    • Vspeeds computations
    • Minimum runway length would allow lots of filtering to be smarter, replacing various hard-coded guesses in the NavDisplay and GPS

NAV Display

  • Improve API based on feedback from aircraft authors!
  • Tested support for custom symbols specified via properties

Miscellaneous

  • command to load a property-tree XML from a web-service (TCP host + port). Initially to be sued to dynamically retrieve a server list from a server
  • HUD configuration improvements