Board index FlightGear Development Canvas

How to display Airport Chart?

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: How to display Airport Chart?

Postby Hooray » Mon Nov 04, 2013 11:09 am

@Philosopher: I previously mentioned that we should generalize the draw* callbacks and accept callbacks for predicates etc - however, looking at the structure of the code, it would seem better to introduce a "Drawable" class instead, which has an update() method, and which will run removeAllChildren() on its rendering group. The update method should probably return the canvas group to the caller, so that external callers can customize the group's appearance as necessary (aka the MVC controller).

I would then turn existing draw* callbacks into instances of Drawable, just for different symbols: fix, vor, ndb, dme etc
The Drawable constructor would then accept an optional argument that specifies whether the default draw routine will be called, or a custom callback - or if a SVG file is to be used.
That should allow us to support different types of NDs and charts.

Most of the current getprop() stuff in the routines show that there's no separation of concerns in place currently, so this should be better done by registering callbacks that are invoked prior, during or after drawing, where each callback would be passed a handle to the drawing group to operate on it. Which should make it possible to support everything that's currently done, while gaining much more flexibility.

These are just a few steps, and they're trivial - but they would already help move 90% of the code up to line 200 to the Nasal/canvas/map folder, where things can then be easily reused for other purposes, not just different aircraft.

The EFIS/MFD class is a different beast, in that it already contains more sophisticated logic, such as for route/traffic drawing - which would need a real MVC implementation prior to being moved to the shared Nasal folder, because it contains way too much EFIS-specific code, which would "break" any other uses (think Map dialog).
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: How to display Airport Chart?

Postby zakalawe » Mon Nov 04, 2013 3:33 pm

Regarding spatial queries, on the nav-cache side, delta queries would be complex to support. What the C++ NavDisplay does is keep a persistent list which is updated infrequently - only when a setting changes (range, view options config), or when the aircraft moves > 1nm. In C++, computing the delta of two arrays is fast, and that's what I would suggest to avoid the 'remove all children' logic, which is obviously unfriendly to the Canvas. What I'm not sure about, is if Nasal currently has a nice API to compute the difference (added / removed items) between two arrays, but if it's missing I am sure it can be added.

BTW, I have lost track - is anyone working on replacing the map dialog based upon this code? Because that seems like the most important use case to demonstrate that MVC pattern can support, aside from the NavDisplays.
zakalawe
 
Posts: 1152
Joined: Sat Jul 19, 2008 4:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: How to display Airport Chart?

Postby Hooray » Mon Nov 04, 2013 8:05 pm

I don't think we have any real Nasal API for getting a delta of two vectors - but I think, we'll want to avoid Nasal-space overhead here (aka a foreach loop), and simply add a corresponding C/C++ extension function, that directly operates on pointers/NasalPositionedGhosts, and then just return the corresponding subset.

On the canvas side, it would obviously be useful to address elements/groups by ID rather than index, because we could then selectively remove entries that are no longer valid. But maybe Tom has a better idea ?

Regarding the map display, I am not working on it currently - my priority would be generalizing the ND.nas code such that it can be mostly moved to Nasal/canvas, with very little code remaining in the aircraft folder - from then on, we can look at porting the map dialog, and supporting other dialogs or ND-styles.

Basically, I would like to see all draw* callbacks moved to *.draw files first - and then refactor the ND.nas code such that all the ND/EFIS-specific conditionals are moved to either predicate-callbacks in ND.nas, or preferably methods implementing a generic Drawable class.

Just to to illustrate the point, here's a crude start that demonstrates how we can move the draw_fix implementation to the shared Nasal folder:
Code: Select all
From 57e50f503e11adbd57d9eeca40cd6d2fd45af8cc Mon Sep 17 00:00:00 2001
From: Hooray <hooray@hush.com>
Date: Mon, 4 Nov 2013 15:53:14 +0100
Subject: [PATCH] preparations for generalizing ND.nas

---
 .../747-400/Models/Cockpit/Instruments/ND/ND.nas   |   22 +------------------
 Nasal/canvas/map.nas                               |    2 +-
 Nasal/canvas/map/fix.draw                          |   21 +++++++++++++++++++
 3 files changed, 24 insertions(+), 21 deletions(-)
 create mode 100644 Nasal/canvas/map/fix.draw

diff --git a/Aircraft/747-400/Models/Cockpit/Instruments/ND/ND.nas b/Aircraft/747-400/Models/Cockpit/Instruments/ND/ND.nas
index 0306fe6..baacb1f 100644
--- a/Aircraft/747-400/Models/Cockpit/Instruments/ND/ND.nas
+++ b/Aircraft/747-400/Models/Cockpit/Instruments/ND/ND.nas
@@ -57,24 +57,6 @@ var altArc = {};
 
 var i = 0;
 
-var draw_fix = func (lat, lon, name) {
-   var fix_grp = fix_group.createChild("group","fix");
-   var icon_fix = fix_grp .createChild("path", "fix-" ~ i)
-      .moveTo(-15,15)
-      .lineTo(0,-15)
-      .lineTo(15,15)
-      .close()
-      .setStrokeLineWidth(3)
-      .setColor(0,0.6,0.85);
-   var text_fix = fix_grp.createChild("text", "fix-" ~ i)
-      .setDrawMode( canvas.Text.TEXT )
-      .setText(name)
-      .setFont("LiberationFonts/LiberationSans-Regular.ttf")
-      .setFontSize(28)
-      .setTranslation(5,25);
-   fix_grp.setGeoPosition(lat, lon)
-      .set("z-index",3);
-}
 var draw_vor = func (lat, lon, name, freq, range) {
    var vor_grp = vor_group.createChild("group","vor");
    var icon_vor = vor_grp.createChild("path", "vor-" ~ i)
@@ -392,7 +374,7 @@ var EFIS = {
       if(rangeNm <= 40 and getprop("instrumentation/efis/inputs/wpt") and getprop("/instrumentation/efis/mfd/display-mode") == "MAP"){
          var results = positioned.findWithinRange(rangeNm*2,"fix");
          foreach(result; results) {
-            draw_fix(result.lat,result.lon,result.id);
+            canvas.draw_fix(fix_group, i, result.lat,result.lon,result.id);
          }
       }
    },
@@ -711,4 +693,4 @@ setlistener("sim/signals/fdm-initialized", func() {
 var showNd = func() {
    var dlg = canvas.Window.new([400, 400], "dialog");
    dlg.setCanvas(nd_display);
-}
\ No newline at end of file
+}
diff --git a/Nasal/canvas/map.nas b/Nasal/canvas/map.nas
index 7515410..7424758 100644
--- a/Nasal/canvas/map.nas
+++ b/Nasal/canvas/map.nas
@@ -579,7 +579,7 @@ var load_modules = func(vec) foreach(var file; vec) io.load_nasal(MVC_FOLDER~fil
 
 # TODO: read in the file names dynamically: *.draw, *.model, *.layer
 
-var DRAWABLES = ["navaid.draw",  "parking.draw",  "runways.draw",  "taxiways.draw",  "tower.draw"];
+var DRAWABLES = ["navaid.draw",  "parking.draw",  "runways.draw",  "taxiways.draw",  "tower.draw", "fix.draw"];
 load_modules(DRAWABLES);
 
 var MODELS = ["airports.model", "navaids.model",];
diff --git a/Nasal/canvas/map/fix.draw b/Nasal/canvas/map/fix.draw
new file mode 100644
index 0000000..05d683b
--- /dev/null
+++ b/Nasal/canvas/map/fix.draw
@@ -0,0 +1,21 @@
+##
+#
+#
+var draw_fix = func (group, i, lat, lon, name) {
+   var fix_grp = group.createChild("group","fix");
+   var icon_fix = fix_grp .createChild("path", "fix-" ~ i)
+      .moveTo(-15,15)
+      .lineTo(0,-15)
+      .lineTo(15,15)
+      .close()
+      .setStrokeLineWidth(3)
+      .setColor(0,0.6,0.85);
+   var text_fix = fix_grp.createChild("text", "fix-" ~ i)
+      .setDrawMode( canvas.Text.TEXT )
+      .setText(name)
+      .setFont("LiberationFonts/LiberationSans-Regular.ttf")
+      .setFontSize(28)
+      .setTranslation(5,25);
+   fix_grp.setGeoPosition(lat, lon)
+      .set("z-index",3);
+}
--
1.7.2.5




This obviously just the draw routine, and will need further work - but if the existing code could be modified accordingly, it should be a breeze porting other displays and dialogs.

The whole MVC approach should then serve us pretty well to support different use-cases, including multiple instruments, styles and different dialog widgets for charting purposes.

If I remember correctly, Gijs also mentioned that his current code is still just working in "singleton mode", as in not supporting multiple NDs.
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: How to display Airport Chart?

Postby Philosopher » Wed Nov 06, 2013 1:40 pm

I've created a simple MVC layer for symbol instances (aka a object with a lat/lon position) and a window/viewer. Basically, I've watered it down so a .draw file only has to provide a Canvas type (group, path, etc.) and an update routine (which will redraw if necessary, or just change color, etc.), and optionally some other things. I have an abstract view object (not finished) that handles the conversion of lat/lon into pixels for each object, so each Symbol only has to keep track of its lat/lon and calling the necessary position update method. I'll upload it to Git sometime in the week :D.

Hooray: what's the purpose of the .layer and .model files? In my design, the symbol creator provides a model that can be a positioned ghost or a geo.Coord, which fully supplies the coordinates for the object, and the .draw file can overwrite that if needed (i.e. to support current aircraft pos or such) by providing a "var get_pos = func return [lat,lon]".
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: How to display Airport Chart?

Postby Hooray » Wed Nov 06, 2013 2:11 pm

I don't mind throwing away any (or all) of the original code - it's mostly boilerplate/stubs anyways - however, when I put it together I didn't want to rewrite the code that Stuart had witten, so turning everything into draw* callbacks was straightforward - putting things into distinct *.draw files helped maintain a clean separation of drawing (the view), vs. what to draw (model), and when to update things (control).

Like I mentioned previously, the model/controller aspect clearly needs some work to satisfy different needs, including different instruments/MFDs, different MFD styles, but also different GUI uses (i.e. map widgets in dialogs).

So if you can come up with a design that satisfies the existing use-case, while also addressing our needs for supporting different aircraft, instruments, styles and GUI dialogs, then, your design is clearly superior, and we should throw away the old code.

To clarify the "layer" concept, these are basically just canvas groups that can be individually toggled (enabled/disabled to hide/show things) - which is obviously more efficient than always updating/redrawing things, as can be seen when viewing the KNUQ taxiways, or when disabling/enabling waypoints in the 744 ND, which is not particularly efficient at the moment - not just because of the removeAllChildren() approach, but also because of redrawing everything.

Basically, the original idea was that 90-90% of the underlying code can be shared, regardless if a chart is to be used as a map layer in the ND or in a GUI dialog - but obviously we would need a way to specify custom models and controllers for different needs, i.e. showing the route on the ND would need to respond to different (cockpit) events compared to showing the same route in the route manager dialog. Likewise, the map dialog could share 90% of the ND.nas code, as long as the models and controllers can be customized/overidden.

Supporting styling is one thing that I basically missed in the first iteration - but obviously we need a way to allow end-users to customize their ND, by either providing a custom draw callback, by specifying a SVG files, or by implement a "Drawable" interface.

And looking at Gijs 744 code, we also need a way to "inject" custom logic to style/mark elements, depending in controller-specific conditions, such as the range selected in the cockpit, or in the GUI dialog - or the next waypoint.

Please feel free to commit your changes, so that we can have a look - and then decide how to proceed from there.

BTW: Thanks for taking a look and helping !
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: How to display Airport Chart?

Postby Philosopher » Wed Nov 06, 2013 2:39 pm

Yeah, that sort of styling is possible, as long as the "model" has sufficient information and the "drawer" can act on that information. What I see currently in Gijs code would be, in my framework:
Code: Select all
var redraw = func() {
    me.element.removeAllChildren(); # creation of this is handled by wrappers
    var icon_vor = me.element.createChild("path", "vor-" ~ i)
        .moveTo(-15,0)
        .lineTo(-7.5,12.5)
        .lineTo(7.5,12.5)
        .lineTo(15,0)
        .lineTo(7.5,-12.5)
        .lineTo(-7.5,-12.5)
        .close()
        .setStrokeLineWidth(3)
        .setColor(0,0.6,0.85);
    var freq = me.model.frequency/100;
    if (freq == getprop("instrumentation/nav[0]/frequencies/selected-mhz"))
        me.draw_active(index:1);
    elsif (freq == getprop("instrumentation/nav[1]/frequencies/selected-mhz"))
        me.draw_active(index:1);
}
var draw_active = func(index) {
    var radius = (range/rangeNm)*345;
    var range_vor = me.element.createChild("path", "range-vor-" ~ i)
        .moveTo(-radius,0)
        .arcSmallCW(radius,radius,0,2*radius,0)
        .arcSmallCW(radius,radius,0,-2*radius,0)
        .setStrokeLineWidth(3)
        .setStrokeDashArray([5, 15, 5, 15, 5])
        .setColor(0,1,0);
    var course = getprop("instrumentation/nav["~index~"]/radials/selected-deg");
    me.element.createChild("path", "radial-vor-" ~ i)
        .moveTo(0,-radius)
        .vert(2*radius)
        .setStrokeLineWidth(3)
        .setStrokeDashArray([15, 5, 15, 5, 15])
        .setColor(0,1,0)
        .setRotation(course*D2R);
    caller(1)[0].icon_vor.setColor(0,1,0);
}

Simply by polling a property (or even a Nasal variable), each object can check if it special or not. Plus, the caller/creator can essentially override anything it wants, e.g. replace a update() method or something for more flexibility.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: How to display Airport Chart?

Postby Hooray » Wed Nov 06, 2013 3:06 pm

okay, so this would then be a free-standing function using an instance variable that is resolved by the surrounding object calling it, right ?
Sorry for probably asking the obvious, but my Nasal meta-programming skills are not all that sophisticated :D

I do like how you're example separates things into different functions, but I believe that we really MUST avoid any use-case specific logic/conditionals in those draw callbacks, and instead accept callbacks for such conditions - or preferably, even use a Drawable class where hooks can be registered to process custom conditions.

Just to clarify: stuff like getprop("instrumentation/nav[0]/frequencies/selected-mhz") doesn't belong into the visualization part of the code (i.e. the draw/view stuff) - simply because that's the sort of stuff that would "break" once we're using a different use-case, e.g. the map dialog - which is such conditions would need to be either specified in some form of condition hash, as part of the draw* signature, or via a dedicated Drawable class that's able to evaluate such conditions.

To be honest, that was the whole point of moving stuff to different *.layer and *.model files - so that these *.draw files can be shared, without requiring any modifications - your current example would still require using differrent *.draw files for each purpose.

However, like previously mentioned, the whole removeAllChildren() method is unfriendly to the canvas, and should eventually be replaced with something more efficient.
Which is why I would prefer to encapsulate it in some form of helper method, which can later on be re-implemented by touching only a single place.
At the moment, these update() methods are all structured in the same fashion, i.e. calling removeAllChildren() first, and then proceeding with the redrawing stuff - I would prefer to introduce a helper method here, something like having a refresh() method that would hide the removeAllChildren() internals, which could later on by re-implemented by calling a dedicated Nasal extension function to determine the delta between two vectors (like Zakalawe mentioned) - basically something like:

Code: Select all
var vec1 = [1,2,3];
var vec2 = [0,1,2,4,5];
# return a 2-element vector with removed/added elements
var delta = vec_diff(vec1, vec2)

var removed = delta[0]; # removed now contains all elements that are no longer in the 2nd vector
var added = delta[1]; # contains all elements that are new, i.e. not in the first vector


Which would allow us to look up removed elements/groups, and only remove those from the canvas subtree, while just adding new ones as required.

This could be added as a simple extension function, or to optimize things even further, as dedicated NasalPositioned methods, or possibly even as Nasal Ghosts that operate on Canvas pointers directly.

EDIT: I have started moving draw* callbacks out of the ND.nas file into $FG_ROOT/Nasal/canvas/map/*.draw files - these are currently loaded into the canvas namespace (easy to fix) - the idea is just to reduce the amount of code in ND.nas, so that we can more easily generalize things from then on - I'll be pushing that to some fgdata branch, so that you can have a look - I didn't touch the vor/vor_active routine, so that there should be no conflict when you add your changes. ND.nas is now down to 350 LoC here - I think we can reduce it down to 200 easily. The EFIS/MFD class will need some MVC helpers though. For now, I just want to make sure that useful code can be easily reused without being coupled to the ND use-case. So there are going to be some ugly hacks to get rid of all the conditional stuff currently sprinkled all over the place.
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: How to display Airport Chart?

Postby Philosopher » Wed Nov 06, 2013 7:22 pm

Okay, I think I'm beginning to get what you're saying. *.draw still needs to provide the drawing routines, but *.model should provide the predicates for drawing them... I'll have to think about a controller; would that just be commands that say "please update since this changed"? I'm leaning towards calling update() every frame anyways...

To provide background info, that snippet above represents a "class" (using the namespace it's run in, versus an explicit hash...). The pseudo-class inherits from a DotDraw class, which in turn inherits from and provides some abstraction over the Symbol class, which, as I mentioend previously, provides for a encapsulation for "objects with positions". The idea is that the objects w/ positions keep track of themselves, and so redraw themselves in a smart manner (for example, moving only requires a retranslation; adding/removing a VOR radial image only requires manipulating a single Canvas element; and color changes based on active/inactive are only a single method call). Their parent "View" object can position & cull them based upon their lat/lon – that is, we only remove a single Canvas element representing an object. This way we don't even need to get a difference of vectors, we just ask whether (a) we need to re-query (aka throw the old set away); or, for each element: (b) remove it (too far out of the visual range); or (c) move it/do nothing. Is this a workable idea?
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: How to display Airport Chart?

Postby Hooray » Thu Nov 07, 2013 3:10 am

Philosopher wrote in Wed Nov 06, 2013 7:22 pm:Okay, I think I'm beginning to get what you're saying. *.draw still needs to provide the drawing routines, but *.model should provide the predicates for drawing them... I'll have to think about a controller; would that just be commands that say "please update since this changed"? I'm leaning towards calling update() every frame anyways...


Originally, the idea was that we want to avoid the ongoing degree of copy/paste programming that could be seen in the airport selection dialog - next, the 744 ND duplicates lots of code used in the airport dialog, but also in the underlying framework - all without using inheritance or delegates/predicates to customize things. So over time, we would end up with tons of custom code that is highly specific to each aircraft/display and GUI dialog.

From a low-level point of view, it shouldn't matter to the draw routines if they're called by an aircraft instrument or by a GUI dialog. However, once they contain use-case specific logic, such as getprop() calls and other conditionals, things do get messy pretty quickly. Thus, what I have been doing is simply copying things to separate *.draw files for different scenarios, i.e. I now ended up with airport.draw and airports-nd.draw for example - that isn't all that elegant, but at least it solves the problem of having to implement full models and controllers for each scenario (well for now), because all the embedded logic can stay, and only needs to be refactored later on.

Thus, the idea is basically this:

*.draw files contain the low-level logic to draw arbitrary symbols (runway, waypoint, taxiways, airports, traffic) - without knowing anything about the frontend/user - so that such details needs to be separately encapsulated. The *.model files merely determine what is to be drawn, data-wise, as in NasalPositioned queries and their results - all stored in a single Nasal vector. The layer files turn everything into a dedicated canvas group that can be separately toggled/redrawn/updated - the currently missing bits are controllers that tie everything together, so that each frontend (instrument, MFD, GUI dialog, widget) can separately specify and customize behavior by registering their own callbacks.

Most of this is already working here (with very minor regressions so far that Gijs won't be too happy about ...), but otherwise I managed to turn Gijs code into layers/models that can be directly used by the old framework, i.e. I can now add a handful of new ND layers (fixes, vor, MP or AI traffic, route etc) to the airport selection dialog (or any other dialog actually), and things do show up properly.

What's still missing is the controller part, and styling for different aircraft/GUI purposes - also, Gijs' ND routines are currently used directly, without any LOD applied - but I think that can be easily solved by using the canvas's scale() method.

For now, I'll just upload/push my changes, fully realizing that I introduced a few regressions - but the point is that those are relatively easy to solve, and that the map dialog can now even be re-implemented just by editing an XML file (unless there are layers that we're still missing?). Likewise, a route widget can now be added to the route manager dialog, all using Gijs' backend code, which is now shared.

I had to add quite a few hacks to support things without major refactoring, but at least there's fair degree of code sharing possible now.

EDIT: Here's the whole mess: https://gitorious.org/fg/hoorays-fgdata ... canvas/map :D

@Gijs: Probably it would be a good idea if you could quickly test things and report back all regressions that you noticed, some stuff is probably more obvious to you than anybody else - otherwise, I'll try to get rid of the known issues over the next few days/weeks.
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: How to display Airport Chart?

Postby Hooray » Thu Nov 07, 2013 2:10 pm

Okay, after some more bug fixing and refactoring, I have pushed the latest state to gitorious.
Using these changes, we can reuse about 90% of Gijs' original ND code to easily create other maps/charts, not just for MFDs, but also for GUI dialogs (see below).
There are still some open issues, but overall this should reduce the amount of specialized Nasal code quite signifcantly:

Image
(The screen shot shows independent canvases, using identical backend code - it's still not optimized and obviously still missing LOD/styling - but that's trivial to add...)
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: How to display Airport Chart?

Postby Gijs » Thu Nov 07, 2013 2:40 pm

Looks the same as before, so I don't think you've introduced any big regressions. ;-) I'm quite occupied the upcoming days, so I'll let you fix your issues and then comment. Once you have the basic framework done, it should be trivial for me to extend it with the remaining functions that I didn't model yet and fine tune the existing features.

Note that the real thing doesn't have an advanced decluttering system. It's less sophisticated than I thought at first. Cluttered texts are quite common. Eg. see http://m7.i.pbase.com/g1/23/582523/2/11 ... Tm9KRm.jpg
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9363
Joined: Tue Jul 03, 2007 2:55 pm
Location: Amsterdam/Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: How to display Airport Chart?

Postby Philosopher » Thu Nov 07, 2013 2:42 pm

Okay, working on checking it out currently. Glad to see you have a working Canvas-FG session! :mrgreen:
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: How to display Airport Chart?

Postby Hooray » Thu Nov 07, 2013 2:48 pm

Ya, for a while, I didn't have access to a machine suitable to run FG/Canvas - but I do right now, which is why it didn't take very long to make these changes. But there are some still some issues and ugly workarounds (and Nasal is a real pain to refactor ...duck typing sucks!).

And yes, please do check it out - feedback appreciated. Most of the points I made earlier should become a little clearer now.
Once the 744 ND is stable again, we can look at re-implementing the map dialog, and maybe adding a route widget to the route manager for starters.

Obviously, supporting Hyde's B777 would be another great thing, but perfectly do-able with very little custom ccode - we just need to make sure that we implement proper controllers for different aircraft/GUI purposes.

re: decluttering, I think TheTom and Zakalawe talked previously about adding some C++ code to make this work better, not primarily for MFDs, but for GUI dialogs like the Map dialog.
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

Re: How to display Airport Chart?

Postby Philosopher » Thu Nov 07, 2013 3:00 pm

Hooray wrote in Thu Nov 07, 2013 2:48 pm:(and Nasal is a real pain to refactor ...duck typing sucks!).

Ya, and it's clear I need a code-reformatter to make it legible!

Edit: Is FG supposed to take up 1.2GB of "Real Mem" over here? That basically means I can't have Firefox open too :(.
Last edited by Philosopher on Thu Nov 07, 2013 3:10 pm, edited 1 time in total.
Thanks,
Philosopher
(inactive but lurking occasionally...)
Philosopher
 
Posts: 1590
Joined: Sun Aug 12, 2012 6:29 pm
Location: Stuck in my head...
Callsign: AFTI
Version: Git
OS: Mac OS X 10.7.5

Re: How to display Airport Chart?

Postby Hooray » Thu Nov 07, 2013 3:10 pm

sorry, not been using an editor with Nasal support - but there isn't all that much new code actually - most of it is just shuffled around.
But please go ahead if your editor manages to reformat things properly :D
Anyways, I'm sure that ___I___ am not going to win the Nasal obfuscated code contest :D

But yeah, map.nas DOES need more than just reformatting - I think most of it can go away once PUI is phased out, because we can then directly use canvas dialogs instead.

Regarding your edit: are you saying that it's taking up more memory than before ? If so, that's certainly my fault then, and I'll need to investigate ... if fgdata/master takes signficantly less RAM, then I screwed up somewhere and there's much more data written to the tree than required...

EDIT: Just checked (fgdata/master HEAD): seeing >= 1.5gb RAM in use at KSFO, 744
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: 11326
Joined: Tue Mar 25, 2008 8:40 am

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests