Talk:A standard CDU framework for FlightGear

Can we have the standard CDU framework discussion here?

Anyway, about the layers, I was thinking - display animations (OSGText), 3D model, central functioning - MENU, FUNCTIONS/PAGES). About the menu and function/pages, we could use a common menu and have the best/most functional functions/pages from each of the CDUs combined.

- Omega

Scratching my head about what "my" CDU actually did do...

Well, hello (again, I should say)

Some initial information: I am not longer "working" with FlightGear. My project has moved on and "we" don't need a FlightGear CDU anymore, hence I won't be able to spend "work time" on it...

That aside, here are some things I think to remember from "my" CDU:

• It isn't "mine". I started of on Gjis CDU, took his 3D graphics and started to work my way in from his initial XML based approach so all the kudos to him as I learned from his. That said, I am going to drop the "" and call my CDU the one you can get from gitorious https://gitorious.org/~hcc23.
• Beware of NASAL and performance: I encourage you to checkout my CDU and run it (if it still is compatible)... The frame rate really really drops :( I remember having some IRC discussions about that and think to remember the problem being the NASAL garbage collector...
• I tried to generate a rather reusable piece of software.
  • The 3D model is seprate
  • The key binding is separate
  • The backend to generate (Honywell-)CDU style pages is independent from the code that defines the content of those pages
  • There is some documentation on how to actually generate content for the pages.

Overall I think having a CDU would make FlightGear an even better/cooler sim. Chopping the problem up also seems to be a great idea.

Unfortunately I won't have the same availability as when I coded the stuff that now sits in my gitorious account and most likely I won't be able to fully understand my code either. And to make matters worse, I most likely won't check this page very often (although I will keep trying to keep up at least a couple of days/weeks...) So send me a private message via the forum as that reaches me and I can then respond. (Or google any of my email addresses and ping me directly...)

Thanks for making FlightGear the really cool sim it is :)

Hcc23 18:05, 2 February 2012 (EST)

XML

Looking at the suggested XML markup, I'd really suggest to stick to the PropertyList format instead, despite its verbosity, there are so many advantages for XML files encoded in the PropertyList format.--Hooray 08:26, 3 February 2012 (EST)

Embedded Nasal code

The proposal says "Pages can retrieve property values #{property-tree} and call nasal functions ${NasalRef.nasalClass.function()}". The question is if, and how, that would ideally work for functions passing parameters between XML<->Nasal? The example is just using an empty argument list. Is this only going to be dealt with using "global" properties instead of Nasal arguments?--Hooray 03:09, 4 February 2012 (EST)

Embedding Nasal code

Looking at the suggested markup, it would definitely be possible to implement this without any changes to the C++ source code, i.e. by using Nasal itself: Nasal does have support for parsing XML (also non-PropertyList XML) and there are a bunch of helpers provided in $FG_ROOT/Nasal/io.nas. So it would in fact be possible to come up with our own XML schema, parse it in Nasal space and even support embedded Nasal. Nasal can dynamically compile(), bind() and call() code. If that's really the way we want to proceed, there's no need for C++ work.--Hooray 03:17, 4 February 2012 (EST)

Supporting CSS-type styles in XML

Looking at the markup, that should also be possible to support from Nasal without C++ changes. One would need to introduce a Nasal wrapper that dynamically maps the "CSS" markup to OSGText animations.--Hooray 03:21, 4 February 2012 (EST)

Performance considerations

Hcc23 pointed out that his CDU implementation affected frame rate negatively, presumably due to some garbage collection related Nasal issues. While there are some GC related issues in the Nasal engine, I don't think that's necessarily the case here: I didn't do any debugging or profiling yet, but looking at the code in question, there isn't necessarily very much allocation and deallocation taking place (besides string concatenation), especially when compared to other complex Nasal systems such as the bombable addon or the local weather system. However, due to the lack of a 2D drawing API, we are working around some serious FG limitations and abusing the XML instruments system quite heavily meanwhile. For example, looking at Omega95's VSD instrument, there are some things pretty obvious: this is less than 10 kbytes of fairly simple Nasal code, compared to > 150 kbytes of XML animation code. The XML-configurable instrumentation system was probably never intended for such uses. 150 kbytes of XML animation code quite certainly means that there's a fair amount of processing involved, including some serious property tree I/O, too. So, I wouldn't be too quick pointing at the Nasal GC here. Invocation of the GC can be somewhat reduced by caching and reusing variables, i.e. by not always allocating new variables during each loop iteration, but rather reusing previously allocated variables, such as by using Nasal hashes ("objects") for this. So, before Nasal is completely disregarded here, it might be worth doing some profiling (SGTimeStamp) to see how much time is actually spent processing all those XML animations (in complex instruments). --Hooray 04:02, 4 February 2012 (EST)

In my mind the lack of a 2D drawing API and heavy use of XML animation code is also relevant when trying to implement "non-standard" HUDs, which easily could be considered displays as well. Johan G 07:30, 4 February 2012 (EST)

Do we currently have any HUDs that are truly complex? I was really just referring to the performance considerations mentioned earlier, because I am not convinced that all lag can be attributed to Nasal and its GC. Obviously, getting a 2D drawing API would be great at some point, for a number of reasons - but that's a long standing feature request, and core devs know and agree on that: FlightGear Glass Cockpits (5 years old now). In the meantime, it would be important to check where exactly the lag is created in the first place.--Hooray 08:41, 4 February 2012 (EST)

Access to a 2D drawing API is becoming essential to where my thinking is evolving, as can be seen in my rantings on the page. As for Nasal performance hits, I agree that it may not necessarily be the performance hog some make it out to be. I have written a lot of Nasal code the A380 and I believe I get frame rates that are better than some other aircraft with less Nasal. I think anyone who spends enough time in Nasal has a good idea of how to work within the performance bounds of how it is called. --Scotth1 09:11, 4 February 2012 (EST)