Template:CppBind Ideas: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (RBAR EFIS pointer for Canvas animation system)
m (use instant cquotes)
Line 33: Line 33:
* the flight recorder system (replay buffers) {{Not done}}
* the flight recorder system (replay buffers) {{Not done}}
* [[State machines]] e.g. to help clean up the ND code [https://gitorious.org/fg/fgdata/commit/f8c56dcc52ffd3d6dfca1d39dc4a72b6b3478368]
* [[State machines]] e.g. to help clean up the ND code [https://gitorious.org/fg/fgdata/commit/f8c56dcc52ffd3d6dfca1d39dc4a72b6b3478368]
* the autopilot/property-rule system [http://forum.flightgear.org/viewtopic.php?p=149376#p149376] [http://forum.flightgear.org/viewtopic.php?f=66&t=21217&hilit=cppbind#p193357] [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38172.html] (there are certain [[How the Nasal GC works|Nasal GC issues]], so that we ask people not to implement FDM-coupled Nasal code like autopilots)
* the autopilot/property-rule system [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38172.html] (there are certain [[How the Nasal GC works|Nasal GC issues]], so that we ask people not to implement FDM-coupled Nasal code like autopilots)
{{FGCquote
  |I have recently committed some code to allow runtime loading of property rules and have a Nasal binding for that in mind.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=149376#p149376
    |title=<nowiki>Re: 2 Questions: vacuum & electrical</nowiki>
    |author=<nowiki>Torsten</nowiki>
    |date=<nowiki>Thu Feb 02</nowiki>
  }}
}}
{{FGCquote
  |The more I think about it, the more I am leaning towards unifying the different system modeling blocks in the C++ core under a generic interface that is exposed (or linked in some way) to Nasal. Think the PID controller, the different filters, flip-flops, etc. They are not substantially different to the basic bricks I am writing...<br/>
<br/>
The basic idea would be to detach those blocks from their specific application (autopilot, for example) and refactor them into an independent library with bindings in Nasal and a similar interface to what I have been showing so far. The end result would be quite simulinkish in flavour. It is already starting to smell a bit to that actually... :D<br/>
<br/>
An architecture like that would eventually enable three possible approaches to system modeling: low level C++, static xml driving C++ underneath and fully scripted Nasal.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=193357#p193357
    |title=<nowiki>Re: A general approach to systems modeling in Nasal</nowiki>
    |author=<nowiki>galvedro</nowiki>
    |date=<nowiki>Tue Nov 05</nowiki>
  }}
}}
{{FGCquote
  |Regarding things like the PID controller code, its developer/maintainer (Torsten) was actually planning on making this stuff accessible from Nasal, [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38170.html just to prevent scripters from implementing APs in Nasal (due to garbage collection issues)] - so that should be a no-brainer actually, and such work should be appreciated
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=193359#p193359
    |title=<nowiki>Re: A general approach to systems modeling in Nasal</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Tue Nov 05</nowiki>
  }}
}}
 
 
** also, this would be the best way to decrease the amount of Canvas-related Nasal code, i.e. by using property-rules for animation purposes, as per Torsten's RBAR EFIS [http://forum.flightgear.org/viewtopic.php?f=71&t=23807] and [[User:TheTom#Simulation_.2F_systems|TheTom's system-modeling plans]]
** also, this would be the best way to decrease the amount of Canvas-related Nasal code, i.e. by using property-rules for animation purposes, as per Torsten's RBAR EFIS [http://forum.flightgear.org/viewtopic.php?f=71&t=23807] and [[User:TheTom#Simulation_.2F_systems|TheTom's system-modeling plans]]
* exposing the sound manager, so that scripts can directly play audio files [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18550.html]
* exposing the sound manager, so that scripts can directly play audio files [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18550.html]

Revision as of 17:59, 29 November 2014

FlightGear's built-in Nasal scripting language comes with a set of standard libraries, and can be extended using FlightGear specific APIs.

Exposing simulator internals to scripting space is a fairly common and useful thing, because it enables base package developers to access these internals without having to build FlightGear from source, so the barrier to entry is significantly lower and we've seen an increasing number of novel features purely implemented in scripting space, due to powerful APIs being available to aircraft developers and other base package developers.

Until FlightGear 2.8, the Nasal scripting engine only provided a C API to expose such hooks/bindings to scripting space or to expose scripting space data structures back to C/C++.

Unlike the core Nasal engine itself (which is C), FlightGear however is mostly written and being developed in C++. For quite a while, that meant that the Nasal APIs were a bit low-level, and sometimes also awkward to use when making functions, data structures or objects accessible between C++ and Nasal.

Thanks to development on Tom's Canvas system, there's now a new bindings framework to be found in $SG_SRC/simgear/nasal/cppbind. This is fully object oriented and supports modern C++ features by operating through classes and methods with full STL support, abstracting most common operations away.


After working through the Nasal/CppBind article, some of the more useful things to play with in the beginning, would be exposing additional SG/FG classes to Nasal space, such as for example:

  • SGPath Done Done (by TheTom)
  • SGCondition Done Done (by TheTom) [1]
  • SGPropertyChangeListener Pending Pending (suggested by Zakalawe & TheTom) [2]
Cquote1.png This and using maketimer instead of settimer should reduce the number of leaked resources a lot, because you would not be able to accidentally leak listeners/timers anymore.
— Thomas Geymayer (2014-11-22). [Flightgear-devel] RFC: Nasal ghosts and garbage collection.
(powered by Instant-Cquotes)
Cquote2.png
  • for better diagnostics, and better end-user bug reports, we could consider exposing a cross-platform process and system utilities module via Nasal/CppBind, such as e.g. SIGAR (Windows, MacOS & BSD/Unix) Not done Not done
  • Airways/Airspace boundaries don't seem to be exposed via NasalPositioned currently? [3][4]
  • FGProtocol, to implement I/O protocols via Nasal (and help solve ticket #396 and support AJAX, REST, JSON or WebSockets) 30}% completed [5] [6] [7] (stubs available at [8])
  • the loglist/SG_LOG() logging buffer machinery [9]
  • expose VoiceSynthesizer/FLITE TTS[10] to Nasal to get rid of ATC chatter [11] Not done Not done
  • the SGSubsystem interface to register scripted SGSubsystems
  • flight path history [12] Done Done (by TheTom)
  • the flight recorder system (replay buffers) Not done Not done
  • State machines e.g. to help clean up the ND code [13]
  • the autopilot/property-rule system [14] (there are certain Nasal GC issues, so that we ask people not to implement FDM-coupled Nasal code like autopilots)
Cquote1.png I have recently committed some code to allow runtime loading of property rules and have a Nasal binding for that in mind.
— Torsten (Thu Feb 02). Re: 2 Questions: vacuum & electrical.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The more I think about it, the more I am leaning towards unifying the different system modeling blocks in the C++ core under a generic interface that is exposed (or linked in some way) to Nasal. Think the PID controller, the different filters, flip-flops, etc. They are not substantially different to the basic bricks I am writing...


The basic idea would be to detach those blocks from their specific application (autopilot, for example) and refactor them into an independent library with bindings in Nasal and a similar interface to what I have been showing so far. The end result would be quite simulinkish in flavour. It is already starting to smell a bit to that actually... :D

An architecture like that would eventually enable three possible approaches to system modeling: low level C++, static xml driving C++ underneath and fully scripted Nasal.


— galvedro (Tue Nov 05). Re: A general approach to systems modeling in Nasal.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Regarding things like the PID controller code, its developer/maintainer (Torsten) was actually planning on making this stuff accessible from Nasal, just to prevent scripters from implementing APs in Nasal (due to garbage collection issues) - so that should be a no-brainer actually, and such work should be appreciated
Cquote2.png


    • also, this would be the best way to decrease the amount of Canvas-related Nasal code, i.e. by using property-rules for animation purposes, as per Torsten's RBAR EFIS [15] and TheTom's system-modeling plans
  • exposing the sound manager, so that scripts can directly play audio files [16]
  • exposing the random buildings system [17] Pending Pending [18] [19]
  • There's also a pending feature request (ticket #619) to implement USB-HID support [20].
  • ESRI shapelib? [21]
Cquote1.png When we have vector road data at runtime, we can do the following:
  • render it in moving-map displays - either real ones (Garmin G1000 / G430) or the map dialog
  • use it to drive building outline creation as Thomas was suggesting
  • animate traffic on the roads, as point lights at night or even meshes in daytime
    (the important one...)
  • generate tile overlay textures dynamically (and based on view distance) to show the roads on the terrain surface. (And the detail of this texture can include road markings / borders based on distance from the viewer / view angle / etc)

— James Turner (2014-11-21). Re: [Flightgear-devel] Future city terrain strategy.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Specifically, there are some C++ data structures that still need to be exposed to Nasal via cppbind so that we can implement features available in the Map dialog and the hard-coded ND

Canvas_GUI#PUI_Widgets


— Hooray (Tue Jun 24). Phasing out MapWidget post 3.2.
(powered by Instant-Cquotes)
Cquote2.png
Note  Before working on anything related, please do get in touch with other contributors to ensure that this list is still up-to-date.

For more technical Nasal questions (C API, internals etc), you'll probably want to refer to Philosopher, TheTom, Zakalawe or Hooray on the forum - TheTom and Zakalawe can also provide help on using cppbind, having both used it extensively during the last months.