FlightGear wiki

Es/FlightGear Newsletter February 2014: Difference between revisions

Page Discussion

Es/FlightGear Newsletter February 2014 (view source)

Revision as of 10:29, 14 March 2016

88 bytes removed ,  14 March 2016
Switch to {{fgdata-old url}}, {{gitorious merge request}}, {{gitorious url}}, {{gitorious source}} to fix the broken Gitorious links.
m (Correct cat)
(Switch to {{fgdata-old url}}, {{gitorious merge request}}, {{gitorious url}}, {{gitorious source}} to fix the broken Gitorious links.)
Line 30: Line 30:


Please let us know if you see any issues with either change. And while at it, Stuart also fixed one of the longest-standing scenery glitches in FlightGear history[http://forum.flightgear.org/viewtopic.php?f=47&t=22168&p=202063#p202060].
Please let us know if you see any issues with either change. And while at it, Stuart also fixed one of the longest-standing scenery glitches in FlightGear history[http://forum.flightgear.org/viewtopic.php?f=47&t=22168&p=202063#p202060].
Stuart and Thorsten also fixed the black halo that could previously be seen around point lights [https://gitorious.org/fg/fgdata/commit/eaaf816b772649d5b0826a1d0bdd166dbc5b968f].
Stuart and Thorsten also fixed the black halo that could previously be seen around point lights [{{fgdata-old|commit=eaaf816b772649d5b0826a1d0bdd166dbc5b968f}}].


A suitable ALS version of the runway lights is now well under way which fogs runway lighting consistently with the rest of the scene. Having the lights inside the shader has additional benefits - it allows to make them more responsive to the environment, in particular the lights are rendered harder and with a sparkle effect, the distance out to which they are visible changes with the level of ambient lights, and in fog lights acquire a halo due to Mie forward scattering.
A suitable ALS version of the runway lights is now well under way which fogs runway lighting consistently with the rest of the scene. Having the lights inside the shader has additional benefits - it allows to make them more responsive to the environment, in particular the lights are rendered harder and with a sparkle effect, the distance out to which they are visible changes with the level of ambient lights, and in fog lights acquire a halo due to Mie forward scattering.
Line 87: Line 87:
getprop("canvas/by-index/texture[1]/name");
getprop("canvas/by-index/texture[1]/name");
</syntaxhighlight>
</syntaxhighlight>
: (see [https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4 merge request #54] and [https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353 actual commit])
: (see {{gitorious merge request|mr=54|text=merge request #54}} and {{flightgear commit|34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353|text=actual commit}})


== Canvas: two years later ==
== Canvas: two years later ==
[[File:Anniversary4.png|left|600px]]
[[File:Anniversary4.png|left|600px]]


According to [https://www.gitorious.org/fg/flightgear/merge_requests/26 Gitorious merge request #26], it's been two years now that [[Canvas]] (our property-driven 2D rendering API) made it into FlightGear, back in early 2012. Time to recap:
According to {{gitorious merge request|mr=26|text=Gitorious merge request #26}}, it's been two years now that [[Canvas]] (our property-driven 2D rendering API) made it into FlightGear, back in early 2012. Time to recap:


First of all, we'd like to use the opportunity to express our thanks to all the people involved in making it happen, first of all, obviously TheTom and Zakalawe the canvas core developers, who are going out of their way to ensure that base package developers can easily and efficiently use the Canvas, while also being extremely responsive on the forums whenever it comes to feature requests, or those -very rare- bug reports.
First of all, we'd like to use the opportunity to express our thanks to all the people involved in making it happen, first of all, obviously TheTom and Zakalawe the canvas core developers, who are going out of their way to ensure that base package developers can easily and efficiently use the Canvas, while also being extremely responsive on the forums whenever it comes to feature requests, or those -very rare- bug reports.
Line 149: Line 149:


=== Philosopher's fully interactive Nasal Console REPL ===
=== Philosopher's fully interactive Nasal Console REPL ===
Philosopher has created a very cool [[Canvas]]-based, fully-interactive, Nasal Console with a real [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL interpreter (Read-eval-print loop)]. See his Gitorious clone (branch "nasal-console") for the code: [https://gitorious.org/fg/philosophers-fgdata/source/nasal-console:Nasal/console] - it's currently one file (which can even be copied into the existing [[Nasal Console]]) with a menubar entry (under "Debug") for easy access. You can also uncomment the [https://gitorious.org/fg/philosophers-fgdata/source/022bef27f05d4837d720f63c6507b47466ff2a59:Nasal/console/repl.nas#L436 last line] of the file to open it immediately. The dialog accepts user input in lines, and if it detects the user has completed a snippet, it executes the last code it's seen and prints a result of the expression on the same area. The most common way to continue input onto another line is to have an unclothed pair of braces/brackets/parentheses, but this REPL is unique in allowing unfinished expressions: blocks (e.g. just plain "if" on one line -- no condition, no body -- or "foreach (var e; list)" -- no body of the loop) and binary/prefix operators (e.g. "1 >", since that doesn't have a right side of the ">"). This however needs some work and tweaking, so it's always a WIP. The other big issue is the text styling -- the latest optimization leads to overlapping if a line of input/output is more than one line when wrapped. The output of print()/printlog()/etc. still goes to the startup OS terminal instead of the dialog. However, it still is useful for experimenting quickly -- ''quam celerrime revera''.
Philosopher has created a very cool [[Canvas]]-based, fully-interactive, Nasal Console with a real [http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop REPL interpreter (Read-eval-print loop)]. See his Gitorious clone (branch "nasal-console") for the code: [{{gitorious url|proj=fg|repo=philosophers-fgdata|branch=nasal-console|path=Nasal/console|view=tree}}] - it's currently one file (which can even be copied into the existing [[Nasal Console]]) with a menubar entry (under "Debug") for easy access. You can also uncomment the {{gitorious source|proj=fg|repo=philosophers-fgdata|branch=nasal-console|path=Nasal/console/repl.nas|line=708|text=last line}} of the file to open it immediately. The dialog accepts user input in lines, and if it detects the user has completed a snippet, it executes the last code it's seen and prints a result of the expression on the same area. The most common way to continue input onto another line is to have an unclothed pair of braces/brackets/parentheses, but this REPL is unique in allowing unfinished expressions: blocks (e.g. just plain "if" on one line -- no condition, no body -- or "foreach (var e; list)" -- no body of the loop) and binary/prefix operators (e.g. "1 >", since that doesn't have a right side of the ">"). This however needs some work and tweaking, so it's always a WIP. The other big issue is the text styling -- the latest optimization leads to overlapping if a line of input/output is more than one line when wrapped. The output of print()/printlog()/etc. still goes to the startup OS terminal instead of the dialog. However, it still is useful for experimenting quickly -- ''quam celerrime revera''.


[[File:Interactive-Nasal-Console-REPL.png|600px|Philosopher's interactive Nasal console REPL]]
[[File:Interactive-Nasal-Console-REPL.png|600px|Philosopher's interactive Nasal console REPL]]
Retrieved from "https://wiki.flightgear.org/Special:MobileDiff/95678"