Plan-zakalawe: Difference between revisions
Jump to navigation
Jump to search
(→Areas) |
|||
Line 6: | Line 6: | ||
General areas I'm working on, or planning to work on | General areas I'm working on, or planning to work on | ||
=== 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 === | === FGPositioned === |
Revision as of 17:59, 31 December 2011
Task List
Short term plans
Areas
General areas I'm working on, or planning to work on
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!