zakalawe wrote:I’ve spent some of my time since FSWeekend figuring out how I might drive some ‘real’ CDU hardware from the in-aircraft CDU options, and went for a slightly ambitious approach: I’ve written an analogue of ‘FGPanel’ for the canvas. Analogue is actually not quite correct - unlike FGpanel this connects at the view level (canvas properties), it doesn’t run the canvas ‘model’ locally, since that would be very tough (Nasal + whole property tree needed). This distinction was unimportant for the canvas up until now, but it’s going to become important I expect.
zakalawe wrote:Hooray wrote:Instead, it would probably make sense to make some more subsystems optional so that they can be disabled on demand, then the same fgfs binary could be used for starting up in an "instrument only" mode that only renders 2D instruments with properties being read from a master instance.
That's more or less exactly what it will be - and yes, it will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone.
James Turner wrote:Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since
the canvas simply renders to a single osg-Camera. Unlike fgpanel this will
require OSG instead of raw GL of course, but that's the price we pay for
unifying the rendering backend.
Users browsing this forum: No registered users and 3 guests