FlightGear Newsletter September 2014: Difference between revisions

Jump to navigation Jump to search
Cleaned up grammar, added contents
(Cleaned up grammar, added contents)
Line 5: Line 5:
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}}<br/>
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}}<br/>
{{Newsletter-cover-item|DDS feedback needed}}<br/>
{{Newsletter-cover-item|DDS feedback needed}}<br/>
{{Newsletter-cover-item|Aircraft are moved to SVN}}<br/>
{{Newsletter-cover-item|Aircraft moved to SVN}}<br/>
| valign="top" width="33%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|(this is the second column)}}<br/>
{{Newsletter-cover-item|Performance issues}}<br/>
| valign="top" width="33%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|Interview with a contributor}}
{{Newsletter-cover-item|Interview with a contributor}}
Line 30: Line 30:
Continue reading at [[Switching default texture format to DDS]]...
Continue reading at [[Switching default texture format to DDS]]...


== Aircraft are moved to SVN ==
== Aircraft moved to SVN ==
Some months ago we decided to host our aircraft on an SVN repository in order to relieve the fgdata.
Some months ago we decided to host our aircraft on an SVN repository in order to relieve <code>fgdata</code>.
The fgdata repo would be a mirror of the base package.
The <code>fgdata</code> repo would be a mirror of the base package.


We finally moved all our aircraft to '''the new SVN repo''': http://sourceforge.net/p/flightgear/fgaddon/
We finally moved all our aircraft to '''the new SVN repo''': http://sourceforge.net/p/flightgear/fgaddon/


This repository is named "FGAddon" because its content is not required to run FlightGear, as a file not required but providing a new feature (in this case it's aircraft) is usually called an "addon".
This repository is named "FGAddon" because its content is not required to run FlightGear but provides a new feature (aircraft in this case); this is usually called an "addon".


=== Advantages ===
=== Advantages ===
On the user side, the most important feature is to be able to checkout ''only'' wanted aircraft, you do no longer need to download the +400 aircraft at once.
On the user side, the most important feature is to be able to checkout only desired aircraft, as you no longer need to download the 400+ aircraft at once.


On the developper side, the most important interest is to have a base-package like which is lighter to sync for new contributors and easier to maintain when release is built.
On the developer side, the most important interest is to have a base package (<code>fgdata</code>) which is lighter to sync for new contributors and easier to keep up to date.


=== A mini HowTo ===
=== A mini HowTo ===
Line 47: Line 47:
* For Linux/Mac:  Install SVN
* For Linux/Mac:  Install SVN


Then to pick an aircraft (in this example we pick up the DR400-dauphin):
Then to fetch an aircraft (in this example we pick up the [[DR400 Dauphin]]):
  svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DR400-dauphin
  svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DR400-dauphin


Then you can regularly pick the last update with
Then you can regularly fetch the latest updates with
  svn up
  svn up


If you used to use GIT it's finally not so different to run "git clone" or "git pull" ;-)
If you are used to use Git, <code>svn co</code> and <code>svn up</code> are similar to <code>git clone</code> or <code>git pull</code>.
 
The aircraft will remain in the <code>fgdata</code> Git repository for a few months, until everyone has transitioned to the SVN repositories.


=== Background ===
=== Background ===
For our aircraft developers who usually don't read the mailing list (I hope they doesn't exist but just in case), please read this topic: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg32809711
For our aircraft developers who don't regularly read the mailing list (even though any aircraft developers should already be subscribed), please read this topic: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg3280971


== Understanding FlightGear Performance Issues ==
== Performance Issues ==
Several FlightGear users have pointed out inexplicable FG "slowness" that originally seemed related to the property rules subsystem - which is a subsystem that Torsten originally wrote/ported, so he investigated a little and managed to track this down to a pretty serious bug in the effects subsystem that may end up registering thousands of identical listeners, despite effects/shaders not even being in use necessarily.  
Several FlightGear users have pointed out inexplicable "slowness" that originally seemed related to the property rules subsystem - which is a subsystem that Torsten originally wrote/ported, so he investigated a little and managed to track this down to a pretty serious bug in the effects subsystem that may end up registering thousands of identical listeners, despite effects/shaders not even being in use necessarily.  


So the property rules code wasn't even the culprit but obviously it deals with properties, so easy to mis-identify as the troublemaker.  
So the property rules code wasn't even the culprit but obviously it deals with properties, so easy to mis-identify as the troublemaker.  
Line 71: Line 73:
But FG would indeed be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards:
But FG would indeed be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards:


* [[FlightGear Headless]]
* [[FlightGear Headless|Running FlightGear headless]] (i.e. without a window, used for subsystem performance testing)
* [[Testing]]
 
* [[Testing|Testing Performance]]


Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is.
Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is.
45

edits

Navigation menu