Board index FlightGear Development Canvas

NavDisplay & MapStructure discussion (previously via PM)

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Tue Mar 25, 2014 11:32 pm

A while ago, I suggested to introduce an optional options hash, where things like the radio (dme/nav) source could be specified for each instance.
I think the canvas-radar branch should have the corresponding for this.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hyde » Thu Mar 27, 2014 7:57 pm

Hooray wrote in Tue Mar 25, 2014 11:32 pm:I think the canvas-radar branch should have the corresponding for this.

I cloned canvas-hackers-fgdata and checked out canvas-radar but none of aircraft can not be run on this stream.
Or this is just for providing the source change? Then where should I refer for that options hash?
Thanks for your help.
Hyde
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri Mar 28, 2014 10:34 am

According to this, it seems committed

https://gitorious.org/fg/canvas-hackers ... y.mfd#L931

However, I'll have to check my local branches to see if anything is missing. But back when we talked about it, I implemented it immediately.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Thu Apr 10, 2014 9:11 pm

salvete,

I just pushed an update in addition to a merge with master, see the commit: https://gitorious.org/fg/canvas-hackers ... 1801cdf846

After some cleanup and re-merging, I think we'll be ready to merge back into master? So far I have tested with the 747-400, and things appear to be mostly working. I got a few improvements that haven't happened yet, but most of them have, including porting most of the layers. (The new APS layer is such a hack... simply because single symbols aren't supported yet :), so that needs to change.) I don't think there's any other reasons for keeping a separate branch any longer, just a little cleanup... obviously we don't want a non-functional map dialog making it's way back ;). So I'll handle that if you all say it's a good idea.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Thu Apr 10, 2014 9:39 pm

currently going through the changes in your commit - agreed regarding the non-functional map/mapstructure-debugger dialogs - those are not supposed to be committed to fgdata - they were just intended as examples/sandboxes. Not sure what is missing to actually port the existing Map dialog entirely - as you probably have seen, Michat is currently finalizing the IFR symbol set, all using a single SVG - those would need to be read once during startup to populate the SymbolCache probably.

If you are planning on porting the Map dialog and using our layers there, I'd suggest not to remove the hardcoded dialog yet - it's probably better to gather some community feedback first, and let Zakalawe comment/review things. Also, Gijs was working on support for additional projections IIRC

I need to check the wiki to see which layers were still missing, and which ones are particularly low-hanging fruits vs. those that are more complex, but will have impact on performance.


positioned searches are always around the aircraft, when they should be around the Map area.

there should be some proxy/stub somewhere to generalize the stuff you did in aircraftpos.controller - using the method we're using in the ND code for supporting AI traffic.

# FIXME: all of these positioned queries ignore the map's position


to some extent that's an API restriction WRT the positioned APIs, e.g. last I checked findAirportsWithinRange() wasn't quite on par with other APIs supporting an optional starting position

Regarding those changes in navdisplay.mfd, I would also suggest to get rid of all hash entries where disabled:1 is set
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Thu Apr 10, 2014 10:09 pm

I think weather/storms, airports, and routes are the only layers left, and we've proved they aren't too difficult to do. And I did get the disabled ones removed, with the exception of the aircraft symbol one. Certainly the next thing to do is to port the map, and I probably wouldn't remove the old one for a while. Performance is pretty good so far, and it's really only the TFC that needs to keep updating every frame - the others are usually good for minutes at a time.

I do need to check if we simply aren't using an available API functionality to change the start position of those searches, and if so, it's a really simple change because the map already exposes its position. Traffic does its own search, so it already works properly :).
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hyde » Thu Apr 10, 2014 10:16 pm

I have nasal error
Nasal runtime error: Cannot stat file: /home/hyde/work/FlightGear/canvas-hackers-fgdata/Nasal/canvas/map/APS.lcontroller
at /home/hyde/work/FlightGear/canvas-hackers-fgdata/Nasal/io.nas, line 4
called from: /home/hyde/work/FlightGear/canvas-hackers-fgdata/Nasal/canvas/MapStructure.nas, line 604
called from: /home/hyde/work/FlightGear/canvas-hackers-fgdata/Nasal/canvas/MapStructure.nas, line 677
called from: /home/hyde/work/FlightGear/canvas-hackers-fgdata/Nasal/canvas/MapStructure.nas, line 684
called from: /home/hyde/work/FlightGear/canvas-hackers-fgdata/Nasal/canvas/MapStructure.nas, line 595
called from: /home/hyde/work/FlightGear/canvas-hackers-fgdata/Nasal/globals.nas, line 110

Something missed?
Hyde
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Thu Apr 10, 2014 10:17 pm

ita vero, will fix :oops:
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Thu Apr 10, 2014 10:21 pm

APS is missing from the original commit
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Thu Apr 10, 2014 10:23 pm

Okay, now it's pushed.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri Apr 11, 2014 4:21 pm

Philosopher wrote in Thu Apr 10, 2014 10:09 pm:I think weather/storms, airports, and routes are the only layers left

airports should be APT and available, I ported that a few months ago.
However, the "airport-selection" dialog does use another airports.draw file - so that would need to be checked and either integrated or implemented as a separate layer, but it's just the draw routine that differs here.
wxr/storms is something that Gijs has been working on, so I wouldn't interfere with him - it should be fine to use the TFC layer as a template here, just the draw/symbol implementation will be different, but otherwise, it will also traverse a sub tree of the property tree (AW/LW) and turn things into geo.Coord objects with an associated symbol.

waypoints/routes are indeed not yet implemented if I am not mistaken, but would be useful to have for the Map dialog, and could be also useful for the route manager dialog, too.


and we've proved they aren't too difficult to do. And I did get the disabled ones removed, with the exception of the aircraft symbol one. Certainly the next thing to do is to port the map, and I probably wouldn't remove the old one for a while. Performance is pretty good so far, and it's really only the TFC that needs to keep updating every frame - the others are usually good for minutes at a time.


We should probably add some check to see if we're using caching, at least in the more complex layers that would definitely benefit from it. Especially non-static/"volatile" layers, as you put it.

I do need to check if we simply aren't using an available API functionality to change the start position of those searches, and if so, it's a really simple change because the map already exposes its position. Traffic does its own search, so it already works properly :).

yeah, it's simple, but I checked findAirportsWithinRange() a few months ago when Zakalawe said that starting positions should be supported already, and frankly, there was no C++ code at all doing this, in contrast to many other positioned APIs...
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Fri Apr 11, 2014 4:59 pm

Okay, it looks like all the positioned searches do support position as first argument, so I added that now.

I think I meant the "runway-nd" layer instead of airports :P. You're correct that APT is there and being used. The runway layer doesn't look too hard to port either, just displays departure/arrival runways from positioned objects. I think you also did WPT, but it isn't used and I think we also need a actual route layer with lines for that. Adding more caching should be doable - reducing the number of SVGs we need to parse would be nice. I think VOR and FIX is the only one using the cache right now, but APT, DME, NDB, TFC, WPT would be easy to port (what's the weird animation thing in DME for? ;)).
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hooray » Fri Apr 11, 2014 5:11 pm

runway-nd is there because its draw() routine differed from the other draw routine for runways IIRC

WPT is there because when I started porting Gijs code I was getting a bit lost, because it was doing so much at once - that's why I was hoping to split it up, i.e. one for legs, one for waypoints.
Maybe not the smartest idea - but "divide & conquer" you know :-)
The route layer should be there and named "RTE", I just didn't finish the splitting part completely....

The animation thingy, I think that was there to check what's required to support an Animation class - it was just proof of concept, I think someone back then asked how to animate symbols - so that's how that was put together.

Once we have started porting the map dialog, I would also like to explore porting Stuart's airport selection dialog to use MapStructure, simply because that is then the only place remaining where those map.nas helpers are used, so that we can get rid of those - which should help discourage people from still using that approach
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Hyde » Sun Apr 13, 2014 3:33 pm

I've checked and confirmed it works. No flicker at all.
Why don't you put the changes to main stream?
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: NavDisplay & MapStructure discussion (previously via PM)

Postby Philosopher » Tue Apr 29, 2014 3:52 am

okay, got off my lazy back and pushed it as I found it (minus dialogs and those edits)... hope it doesn't break anything.

I didn't quite get in my extra edits I wanted, but that's for another time. Summer's almost here though....
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests