Plan-zakalawe: Difference between revisions
Jump to navigation
Jump to search
(→Areas) |
|||
Line 24: | Line 24: | ||
** Make layout support native to widgets? | ** Make layout support native to widgets? | ||
* Convert '2D' panel node to manage its own picking (removing the currently ugly hack for 2.5D panels) | <del>* Convert '2D' panel node to manage its own picking (removing the currently ugly hack for 2.5D panels)</del> | ||
* Make the pure 2D panel am FGPanelNode attached to the GUI camera | <del>* Make the pure 2D panel am FGPanelNode attached to the GUI camera</del> | ||
* Convert 2D panel text to use osgText | * Convert 2D panel text to use osgText | ||
Revision as of 13:38, 7 January 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
- 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)
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
- 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
NAV Display
- Improve API based on feedback from aircraft authors!