Unifying the 2D rendering backend via canvas: Difference between revisions

Jump to navigation Jump to search

Unifying the 2D rendering backend via canvas (view source)

Revision as of 11:24, 15 July 2013

2,539 bytes removed ,  15 July 2013
m
→‎Background: remove obsolete stuff
m (→‎Background: remove obsolete stuff)
Line 18: Line 18:


<references/>
<references/>
== Background ==
'''Hooray''': We need to come up with some simple interface, so that the created texture can be used in another system.
Specifically, thinking in terms of other od_gauge instruments at the moment:
Currently, the problem is that there's the unfortunate trend that more and more advanced aircraft (such as the 787 or the A320neoo) don't use the hard coded C++ instruments (wxradar, tcas or NavDisplay) but instead replicate the instrument in scripting space, because there's more flexibility to customize things.
This is because there's currently no simple method to make these two approaches coexist in some sane fashion.
In other words, if the Canvas subsystem (or od_gauge itself) had a simple interface to reuse other od_gauge textures, od_gauge instruments could be "chained" together - which would basically make it possible to instantiate a conventional hard coded system (such as the NavDisplay) while still using a scripted Canvas, which could be overlaid over the NavDisplay.
For example, the A320neo project could then reuse James C++ code and instantiate a conventional hard-coded NavDisplay, while still implementing custom features using your Canvas subsystem - the final texture output would then combine the results from each chained od_gauge system.
: '''TheTom''': I've also been thinking about this. As all od_gauge instruments just render to a texture it would be easy to draw this texture somewhere onto the canvas. But I don't think that would be very flexible as it only allows you to draw on top of the existing image. What I think would be better is to port the hard coded instruments to use the canvas for drawing and therefore enable everyone to modify every little bit of it from eg. Nasal space. On instancing an instrument you would just point it to a node in the property tree and the instrument then puts it's primitives there as child nodes. By this it would be possible to directly point it to a canvas group or also point it to some not canvas node and copy the parts needed manually to a canvas. I don't know how much work it would be to port the existing instruments, but I think this would be the cleanest and by for most flexible approach.
:: '''Hooray''': Yes, that would be the cleanest and most flexible solution. I think James already mentioned that he's planning to reuse your canvas code in other hard-coded instruments (see the merge request discussion).Instead of issuing raw OpenGL/OSG drawing commands in the subsystem, all of them would need to use your canvas instead.


== Planning ==
== Planning ==
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/61572"

Navigation menu