Board index FlightGear Development Canvas

FGCanvas Experiments & Updates

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: FGCanvas Experiments & Updates

Postby Hooray » Sat Jul 12, 2014 6:42 am

@TheTom: thanks for applying those bug fixes, and for cleaning up the patches. The code freeze is going to be over next week, so I have pushed the changes I've been discussing the last few days and created a merge request so that you can take a look:

https://gitorious.org/fg/flightgear/merge_requests/1586
These are a few patches to prepare support for initializing Nasal earlier, and for providing support for

alternate/subset startup modes, e.g. a FGCanvas mode or a headless mode. We can now also display the Aircraft Center right after starting.

Mainly, these patches will: - move FGNasalSys out of the global SubsystemMgr into the FGGlobals class, along with getters - update fgMainLoop() to explicitly call the Nasal::update() method there - fix up all globals->get_subsystem("nasal") lookups to use globals->get_nasal() instead - move initialization of subsystem-specific APIs into each subsystem's bind() method - the interpreter is now instantiated at the beginning of the init routine - currently, it's right after fgcommands are added, as those are likely to be needed anyway - reset/re-init handling is augmented to directly access the instance or allocate a new one

For testing purposes, there some CLI flags added, these will probably disappear once $FG_ROOT/Nasal is fixed up:

--enable-scripted-init - passes control to a configurable boot script in $FG_ROOT/Boot --mode=filename - allows the boot file to be specified, defaults to default.boot

--enable-early-nasal-init - initializes Nasal earlier, to see which scripts still need to be fixed

We're hoping to re-implement bootstrapping in Nasal space using Philosopher's code, which would then be moved into $FG_ROOT/Boot/default.boot - once that works, we'll still have to fix up $FG_ROOT/Nasal to make subsystem dependencies more explicit there.

Once that is the case, the two --enable-... options can go, and we can easily implement additional startup modes by adding other *.boot files

Hopefully, this will also allow us to more easily do regression testing in an automated fashion-for example by adding a new "unit-test" startup mode that will run certain APIs to do a self-check.

Likewise, we could also use this to do headless benchmarking/profiling and debugging, possibly even right on the build server (minus all the visuals obviously).

Future changes will be mainly about:

- moving fgCreateSubsystems() into scripting space - extending the subsystemFactory accordingly - extending fgIdleFunction() to allow some of it to be scripted (e.g. splash screens)

Additional info at: http://wiki.flightgear.org/Initializing_Nasal_early
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: FGCanvas Experiments & Updates

Postby Hooray » Sun Jul 13, 2014 8:24 am

I've updated the merge request and started exposing fg_init.cxx/main.cxx init logic to Nasal space - we can basically re-implement 70% of fgIdleFunction() in Nasal space now:

https://gitorious.org/fg/flightgear/com ... de8eb06f6d
- change fgIdleFunc() -> fgCreateSubsystems() interaction such that a property is used for the isReset logic
- move initialization of event_mgr into fgIdleFunc() because Nasal timers depend on events
- main.cxx/fg_init.cxx extract init logic into standalone helper functions and expose them to Nasal
- fg_init.cxx split up fgCreateSubsystems() and use a separate function for "early" subsystems
- preparations for creating & initializing a subset of subsystems earlier than the others
- add a few new "signals" after intializing subsystems, so that Nasal listeners can pick those up for dependencies
- expose idle-state as a propertyObject so that Nasal listeners can be registered
- re-order idle-state increments to the bottom of each block, because using listeners will otherwise invalidate things

NOTE: This patch will now assume that there's ALWAYS at least a default boot script in $FG_ROOT/Boot/default.boot
The script can be empty though - an empty file will do.

But to make things more interesting, add this to the file:
Code: Select all
        var p = "/sim/startup/current-idle-state";
        var update = func(n) {
                print(p," changed:", var n =getprop(p));
        }
   
        _setlistener(p, update);
   

When booting/resetting, You should get notifications for each change in idle-state, such as:

Scripted initialization, now passing control to:Path ".../fgroot/Boot/default.boot"
/sim/startup/current-idle-state changed:3
Nasal interpreter initialized
/sim/startup/current-idle-state changed:4
/sim/startup/current-idle-state changed:5
/sim/startup/current-idle-state changed:7
/sim/startup/current-idle-state changed:8
/sim/startup/current-idle-state changed:9
/sim/startup/current-idle-state changed:10
/sim/startup/current-idle-state changed:900
/sim/startup/current-idle-state changed:1000

There's a new _boot namespace exposed that contains a handful of init routines so that initialization can
be easily re-implemented and customized using a few lines of Nasal in each boot script.

For the time being, FGNasalSys::postinit() will default to running the hard-coded bootstrapping
scheme - but boot scripts can override this via:
setprop("/sim/startup/disable-hardcoded-nasal-bootstrapping",1);

This option will disappear once scripted bootstrapping works properly.

The next set of patches is going to make fgCreateSubsystems() better configurable.

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: FGCanvas Experiments & Updates

Postby Hooray » Wed Jul 16, 2014 2:58 pm

@TheTom: my next set of patches is likely going to be about putting related subsystems into corresponding SGSubsystemGroups.
And it would make sense to coordinate how we want to do this:

Currently, we have a single "global" SGSubsystemMgr in FGGlobals. The main issue here is that dependencies are not well understood/encapsulated. And things aren't exactly future-proof this way - we have a lot of subsystems that have implicit dependencies WRT to ::init and reset/re-init. In fact, init order is highly sensitive to re-ordering issues, especially when re-initializing.

I am hoping to improve this by using separate groups for related SGSubsystems, such as having AUDIO, that would contain fgcom, voice, sound - like I mentioned elsewhere.

But we also have a few subsystems that would better live in their own manager - such as the "persistent" systems, that are not subject to being fully reset (=re-allocated) but just re-initialized, i.e. terrasync, events, time & lighting.

For the time being, SGSubsystemMgr doesn't support the notion of "persistent" members, which is why fgStartNewReset() explicitly excludes a handful of subsystems from being removed.
So this is also a hack...

This raises a few interesting questions: We could basically have a number of different SGSubsystemMgr instances here (a workaround, not very elegant, but easy to get working quickly, and easy to understand & maintain).

On the other hand, the existing notion of "GroupType" is close enough to formalize relationships - it just wasn't ever implemented/used that way, only for ::init & ::update behavior - but not for having a single SGSubsystemMgr that would assign subsystems to "Run-Levels", and make them active - based on having some ::setRunLevel(SGSubsystemMgr::INIT | SGSubsystemMgr::FDM | SGSubsystemMgr::GUI) method.
Likewise, reset() behavior could be set up via an enum flag, too. To ensure that subsystems are reset in a pre-configured order.

I would find this preferable, but it's obviously more work - and will also involve touching SimGear, or sub-classing SGSubsystem* in FG ...

But if we could clean this up, I could also move the Nasal instance/interpreter back into another SGSubsystemMgr instance, and simply manage it separately from the other subsystems there.
So it would be a little cleaner.

The other issue is that we generally want EACH SGSubsystem to set a signal once it has completed ::init() or ::postinit() - ideally, using a single propertyObject<bool> member at the SGSubsystem-level, which would default to the subsystem's name - I think we only need to edit SGSubsystemGroup::init() to pull this off, without having to touch any of the FG subsystems and methods there.

I am hoping to also use this to group aircraft-related subsystems into a single group like "aircraft-main", which would be a container for fdm, ap, rm, history, replay, controls - the idea being, that this would also allow us to reuse the same container for AI aircraft in the future, where all underlying subsystems would be nicely grouped.

This would mean that the performance monitor would only show a handful of "groups" in the beginning - but that's just Nasal (monitor.nas) that needs to be extended to add a combo box for different groups. We'll then want to add one performance monitor instance per SGSubsystemMgr/-Group instance right in the ctor or ::init method.

Inevitably, exposing this to Nasal via fgcommands would be kinda awkward and verbose, using cppbind to expose the 3 SGSubsystem* classes as interfaces should be much easier and less awkward, and it would allow us to use Nasal to add subsystems to custom groups.

So, how do we want to proceed here ?

Note, none of these are feature requests per se, I can work out the details - just want to make sure that we agree on technical terms first, which should also make the review more straightforward hopefully.
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

Previous

Return to Canvas

Who is online

Users browsing this forum: No registered users and 2 guests