20,741
edits
| Line 276: | Line 276: | ||
{{FGCquote|1= I'm guessing it would be somewhat similar to ARINC661, and the actual arrangement of these widgets could be marked up in an XML file. The framework could render to a texture (for display in a 3D virtual cockpit), a memory buffer (for direct blitting onto the screen) or to a separate device context altogether (for an external display). Network support on this would be a really interesting feature -- allowing outboard 'dumb' cockpit displays to be run off a diskless thin client.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/20009948/ | title = <nowiki>Re: [Flightgear-devel] Cockpit displays (rendering, modelling)</nowiki> | author = <nowiki>R. van Steenbergen</nowiki> | date = Aug 3rd, 2008 }}}} | {{FGCquote|1= I'm guessing it would be somewhat similar to ARINC661, and the actual arrangement of these widgets could be marked up in an XML file. The framework could render to a texture (for display in a 3D virtual cockpit), a memory buffer (for direct blitting onto the screen) or to a separate device context altogether (for an external display). Network support on this would be a really interesting feature -- allowing outboard 'dumb' cockpit displays to be run off a diskless thin client.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/20009948/ | title = <nowiki>Re: [Flightgear-devel] Cockpit displays (rendering, modelling)</nowiki> | author = <nowiki>R. van Steenbergen</nowiki> | date = Aug 3rd, 2008 }}}} | ||
{{FGCquote|1= The layout might be similar to a VM, with high-level instructions to represent points, lines, rectangles, text, etc. The advantage of this is that it will set a predefined interface for displaying geometry but not define the low-level implementation. |2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/20013055/ | title = <nowiki>Re: [Flightgear-devel] Cockpit displays (rendering, modelling)</nowiki> | author = <nowiki>R. van Steenbergen</nowiki> | date = Aug 4th, 2008 }}}} | |||
{{FGCquote|1= If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than sending per-frame pixel surfaces over shared memory or sockets / pipes.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/20014214/ | title = <nowiki>Re: [Flightgear-devel] Cockpit displays (rendering, modelling)</nowiki> | author = <nowiki>James Turner</nowiki> | date = Aug 4th, 2008 }}}} | {{FGCquote|1= If we're rendering each display as an OSG sub-camera, extracting that logic and wrapping it in a stand-alone OSG viewer should be simplicity itself - and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than sending per-frame pixel surfaces over shared memory or sockets / pipes.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/20014214/ | title = <nowiki>Re: [Flightgear-devel] Cockpit displays (rendering, modelling)</nowiki> | author = <nowiki>James Turner</nowiki> | date = Aug 4th, 2008 }}}} | ||