20,741
edits
Unifying the 2D rendering backend via canvas: Difference between revisions
Jump to navigation
Jump to search
m
Unifying the 2D rendering backend via canvas (view source)
Revision as of 10:43, 21 June 2020
, 21 June 2020→Planning: add paragraph about porting HUD.cxx (replacement/removal)
m (→Planning: add paragraph about porting HUD.cxx (replacement/removal)) |
|||
| Line 61: | Line 61: | ||
<references/> | <references/> | ||
== HUD == | |||
if we are to move beyond the legacy C++ code, we need a layer (in Nasal or C++) that parses the existing HUID XML, and looks/works close-to-identical to the current version. | |||
There is no conceptual limitation in the Canvas that prevents us doing everything the built-in HUD does.<ref>https://sourceforge.net/p/flightgear/mailman/message/36401872/</ref> | |||
For the HUD, I wonder if the Canvas-HUD could gain a Nasal glue layer, to replicate the C++ HUD? This would then allow the C++ HUD code to be removed entirely, which would be a GoodThing(TM) since it does archaic OpenGL rendering. If Nasal is more your thing than C++, that might be another way to help hasten the death of PLIB <ref>https://sourceforge.net/p/flightgear/mailman/message/36289586/</ref> | |||
We could for example just add some more parseXXX functions (like parsesvg) which parse a dialog/hud/whathever file and create a canvas from it. So we would just have to modify eg. the show-dialog command to create a canvas and call the parser.<ref>https://sourceforge.net/p/flightgear/mailman/message/29589689/</ref> | |||
replace the HUD (HUD.cxx and related code) with a Canvas implementation. This is a confusing scheme, since we have ‘old’ and ‘new’ C++ HUDs (but I recall I unified their rendering some years ago), and some aircraft already using ‘custom Canvas HUDs’, i.e totally independent of the ‘built-in’ HUD. | |||
To be clear, this is the HUD you get by pressing ‘h’ key in the sim. It’s configured by an XML file: FG_DATA/Huds/default.xml - and you can see in that directory, other configs are possible - the ‘new C++ HUD’ layer allows arbitrary placement of HUD elements defined by these XML. | |||
*Some* aircraft, but I don’t know how many, use the C++ HUD system, but replace the default HUD with their own - see the F16 example file also in FG_DATA/Huds for example. | |||
The aim would be to replace the C++ code with a Nasal HUD layer, likely in FG_DATA/Canvas/Hud - with one Canvas HUD item per each of the current C++ HUD items (ladder, tape, dial etc). Each one should be fairly easy to build with some path, text and group commands. | |||
Then we need to write an XML loader in Nasal, possibly one line of C++ to trigger loading, and we can remove the C++ HUD code in favour of the Canvas implementation. | |||
Of course, probably it’s not so simple but this is the concept! | |||
Oh, and there is some complexity I guess about how the Canvas-for-the-HUD is positioned, since right now the HUD moves when the view is rotated. I guess / hope the existing Canvas HUDs can show how to handle that correctly.<ref>https://sourceforge.net/p/flightgear/mailman/message/36399261/</ref> | |||
If the new impl defines each HUD component with the same features as the C++ implementation, it should work as a drop-in replacement for the old system. (Honestly it may be the case that some features supported in C++ are not used by any aircraft out there, but as ever with FG, we have no way to capture the set of in-use features). | |||
If you look at say HUD_tape.cxx - which is one of the more complex ones - it’s some fairly ‘simple’ (but verbose) code to draw either a horizontal or vertical tape. Mostly it comes down to many draw_line calls which ultimately do the OpenGL - you can replace the draw_line calls in a Nasal version with appending a moveTo,lineTo onto a Canvas path. | |||
And the constructor for HUD::Tape::Tape shows you the XML config properties for the tape which are supported.<ref>https://sourceforge.net/p/flightgear/mailman/message/36401850/</ref> | |||
Of course, developing some Canvas HUDs for particular aircraft is a great way to get comfortable with writing Canvas code in general, and HUD display concepts. I just want to explain, that making fifty different Canvas HUDs for our aircraft, still won’t ever let us drop the legacy C++ code - we need a generic (XML driven) HUD for that.<ref>https://sourceforge.net/p/flightgear/mailman/message/36406449/</ref> | |||
About making the specific HUD, I’d suggest to follow the Shuttle approach (procedurally generated geometry) more than the F-14 or F-15 - for a generic HUD using SVG elements will not work, the Shuttle HUD is already 100% defined via Nasal and hence closer to what you need.<ref>https://sourceforge.net/p/flightgear/mailman/message/36407420/</ref> | |||
Canvas-HUD-that-replaces-the-C++-one would appear the same way Canvas tooltips / popups do. (or Canvas dialogs, or…)<ref>https://sourceforge.net/p/flightgear/mailman/message/36401971/</ref> | |||
== Planning == | == Planning == | ||