And when it is loaded as a GUI widget, these could be exposed as GUI hooks, i.e. When a canvas system is being loaded as an instrument, these "generic" properties would be mapped to instrument-specific properties. So, what could be done is adding a new Nasal class to make these relationships explicit: input properties and output properties. For cockpit instruments, these would be mapped to hot spots, i.e. In FlightGear, this would usually mean that there are input and output properties. In any case, there would be a fixed set of "inputs" and "outputs", i.e. The idea is to create a generic system that can be easily parametrized and customized as required, so that it can be used by people to create all sorts of mapping/charting displays in FlighGear, either as conventional MFD gauges, or as GUI dialogs (for example ATC radar screens).Ī display like the current navdisplay could be rendered as an instrument, but also as a GUI widget. The Map widget will be special in that it will be a shared component that can be used for both, GUI dialogs, as well as MFD-style avionics. The only additional code is to deal with special things that can't easily be described by a simply symbol, especially the flight-plan/route path. The current hard coded NavDisplay is really an ARINC 661 display - it takes a list of symbols, a list of items and combines then using a projection to create a final display. The Canvas system's mapping mode loosely follows the ideas from ARINC 661. We need to keep in mind that once the hard coded Map dialog is getting ported, there will be lots of overlapping functionality with similar "displays", like the NavDisplay, agradar, wxradar - all of these are basically about mapping a geo-position to 2D screen space (horizontal currently). I would however be careful not to put too much special stuff into the generic canvas module. Like you say, the API requirements for canvas and the mfd module will become clearer once existing dialogs and gauges are getting ported. It would make sense to introduce another wrapper here, something like "mfd.nas" which transparently handles the low level details and which uses canvas.nas as its workhorse. at a distance of 300 miles the error is about 2.8 miles, which is ~0.9%)." Pending (see Canvas Maps) I think the error in comparison to the real sphere can be neglected while using typical distances (eg. TheTom: "vertical projection seems not too complicated as its basically just calculating segment lenghts on a sphere, or maybe just direct distance calculations.Hooray: " It would be great to have 2-3 "real" applications, so that the canvas/map API becomes more powerful.".Maybe we can do some ATC programs which look like the real ones. TheTom: " ATC-FS is definitely an interesting application which can benefit from the Canvas very much.2 Shared Requirements (MFDs and GUI maps).Howto:Extending Canvas to support MathGL.Howto:Extending Canvas to support rendering 3D models.Howto:Use a Camera View in an Instrument.Unifying the 2D rendering backend via canvas.Howto:Project 3D to 2D coordinates on desktop canvas. ![]() Howto:Using raster images and nested canvases.Howto:Canvas applications as Nasal submodules.Howto:Creating fullscreen Canvas applications.Howto:Parsing 2D Instruments using the Canvas.Howto:Add a 2D canvas instrument to your aircraft.Howto:Dynamic Liveries via Canvas (new). ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |