I'm trying to change 777's indicators to canvas system now.
Could someone lecture me how to display Airport Chart - Aircraft/Instruments/Textures/od_groundradar.rgb - on EFB?
Or is there any other equivalent method?
zakalawe wrote:I'll be looking at adapting the MapWidget now, which will probably involve symbol / icon support in the Canvas map, since that's a recurring feature of all these displays.
zakalawe wrote:I did some experimental work on converting the map dialog last night - I need to have some discussions with Tom about symbol instancing, since the vector symbols I'm doing for waypoints, VORs and so on should ideally be shared. I'll let Tom speak about his ideas for that.
Hooray, I have the impression you're also working on the mapwidget / map dialog - but it's all unfinished code? I'd like to avoid repeating effort, so if you're already working on it I can instead give you some help? So far I didn't see how to handle the route-path in the Canvas map, since it requires a path with both ends mapped by geo-coord.
From your screenshot, I'd say some symbol LOD is needed too - the taixways and tower symbols are already meaningless at that zoom-level.
zakalawe wrote:I would be absolutely delighted by a 100% Nasal driven replacement for the 2D panel and HUD systems - as you say, no C++ is needed!
What I've mentioned before is that I think there's some elements, especially in the HUD, that might benefit from native (C++) canvas elements to avoid creating hundreds of property nodes to describe them to the Canvas - especially for tick marks on ladders. But of course that's an optimisation, and the first step is to try pure Nasal.
And those items are things I could work on, but I would be delighted for someone else to work on them - indeed I've suggested it as a first project to several people on IRC, but I don't know if any of them contacted Tom as I suggested. My only concern would be that they talk to me so we can ensure the replacement system is 100% compatible with the existing HUD / panel loading code (which is C++) - that part should be trivial and doesn't matter until we have at least a proof of concept.
The dialog will eventually use the same map. Anyhow, the ND is more than just a map, but for the map part I make use of the map API.
The ND is in a messy proof-of-concept state at the moment and needs some more cleaning before anyone should dare to look at it. It's a collection of ideas, trials etc. to see what works and what doesn't. I'm currently in the quarterly exam period, so time is scarce, but I hope to have something more or less usable after FSweekend.
I've been in contact with James about this, so don't worry, it won't conflict with his plans.
it's much faster to work on a concrete implementation than trying to create a perfect, generalised, agnostic, does-everything design.
Users browsing this forum: No registered users and 6 guests