Howto:Start core development: Difference between revisions

Switch to the {{forum url}} and {{forum link}} templates for all forum links.
(Switch to the {{forum url}} and {{forum link}} templates for all forum links.)
(24 intermediate revisions by 7 users not shown)
Line 1: Line 1:
{{stub}}
{{out of date}}


''01/2012: I have taken my [http://flightgear.org/forums/viewtopic.php?f=18&t=14870#p146436 forum response] and copied/pasted it here. Everybody is invited to contribute. While we do have a [[Volunteer]] page, we don't currently have a page dedicated to people wanting to contribute to the C++ source code, so this is an attempt to get something like this started.''
''01/2012: I have taken my {{forum link|p=146436|text=forum response}} and copied/pasted it here. Everybody is invited to contribute. While we do have a [[Volunteer]] page, we don't currently have a page dedicated to people wanting to contribute to the C++ source code, so this is an attempt to get something like this started.''


= How the Project works (Suggested reading!) =
= How the Project works (Suggested reading!) =
Please see this short essay here: http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971
 
* [[http://home.flightgear.org/flightgear-policy-document/ | Flightgear Policy Document briefly covering what will be expected of a contributor]]
* [[http://home.flightgear.org/info/ | Other Information to be Aware Of]]
* {{forum link|p=149971|title=Flightgear Development}}
* [[How the FlightGear project works]]
 
Please see this short essay here: {{forum url|p=149971}}
 
Also see [[Implementing new features for FlightGear]]
 
= Welcome to FlightGear =
= Welcome to FlightGear =


Line 38: Line 47:
The "Nasal" programming language built into FG is syntactically very close to C and C++, it looks a lot like JavaScript - so you could run your own code inside FG without having to build FG from source, no need for compilers or an IDE. FlightGear IS the run time environment for Nasal code.
The "Nasal" programming language built into FG is syntactically very close to C and C++, it looks a lot like JavaScript - so you could run your own code inside FG without having to build FG from source, no need for compilers or an IDE. FlightGear IS the run time environment for Nasal code.


If you are looking for immediate results, Nasal is probably the most promising route - simply because you don't need to look into all the tedious, non-coding related issues.
If you are looking for immediate results, Nasal is probably the most promising route - simply because you don't need to look into all the tedious, non-coding related issues. Here's an overview giving you a rough idea about recent Nasal related efforts:
 
{{Nasal Efforts}}


For example, the tutorial system built into FG is entirely implemented in scripting space, and fully XML-configurable: [[Tutorials]]
For example, the tutorial system built into FG is entirely implemented in scripting space, and fully XML-configurable: [[Tutorials]]
Line 62: Line 73:
* if you know you want to contribute to the source code, make sure that you are actually able to build FG from source, you can get help using the forum, the mailing list, the issue tracker or live support using IRC chat - we have articles on building FG on various platforms, see [[Building FlightGear]]
* if you know you want to contribute to the source code, make sure that you are actually able to build FG from source, you can get help using the forum, the mailing list, the issue tracker or live support using IRC chat - we have articles on building FG on various platforms, see [[Building FlightGear]]
* read the documentation (wiki, $FG_ROOT/Docs, $FG_SRC/mini-docs)
* read the documentation (wiki, $FG_ROOT/Docs, $FG_SRC/mini-docs)
* it also helps running DoxyGen or Source Navigator
* it also helps running DoxyGen or Source Navigator to navigate the various source trees
* start making tiny modifications to existing stuff (aircraft, scenery, source code etc)
* start making tiny modifications to existing stuff (aircraft, scenery, source code etc)
* try to get to grips with how git works (we have some resources to get you started, using GUI frontends like qgit or a good IDE can be helpful)
* try to get to grips with how git works (we have some resources to get you started, using GUI frontends like qgit or a good IDE can be helpful)
Line 124: Line 135:
The FlightGear project uses the decentralized source code management system "git" see [[Git]] for more info.
The FlightGear project uses the decentralized source code management system "git" see [[Git]] for more info.


The project sources are hosted at gitorious: http://gitorious.org/fg/
The project sources are hosted at sourceforge: https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/


If you know for sure that you'd like to fiddle with the core source code, you'll inevitably need to be able build FG from source, this is also documented in our wiki, a more recent article is to be found here: http://wiki.flightgear.org/Howto:_Build_FlightGear_with_NetBeans_using_CMake
If you know for sure that you'd like to fiddle with the core source code, you'll inevitably need to be able build FG from source, this is also documented in our wiki, a more recent article is to be found here: http://wiki.flightgear.org/Howto:_Build_FlightGear_with_NetBeans_using_CMake
Line 132: Line 143:
= Continuous Integration (CI) =
= Continuous Integration (CI) =


For CI purposes, there's a dedicated build server running which rebuilds the FlightGear sources for a handful of important platforms. The server provides a simple and quick overview, it can be found here: http://flightgear.simpits.org:8080/
For CI purposes, there's a dedicated build server running which rebuilds the FlightGear sources for a handful of important platforms. The server provides a simple and quick overview, it can be found here: {{build link}}


Please see [[FlightGear Build Server]] for more information.
Please see [[FlightGear Build Server]] for more information.
Line 140: Line 151:
Regarding patches, please see: [[Submitting Patches]].
Regarding patches, please see: [[Submitting Patches]].


Note that this article is meanwhile somewhat depreciated and these days using gitorious (and filing merge requests there) is pretty much encouraged. If your patch is related to a previously reported bug/defect, you can obviously also use the issue tracker (see below).
Note that this article is meanwhile somewhat deprecated and these days using gitorious (and filing merge requests there) is pretty much encouraged. If your patch is related to a previously reported bug/defect, you can obviously also use the issue tracker (see below).


In general, the FlightGear gitorious project is the entry point for new developers: http://gitorious.org/fg/
In general, the FlightGear gitorious project is the entry point for new developers.


Some more recommendations can be found at [[Recommended Project Policies]].
Some more recommendations can be found at [[Recommended Project Policies]].
Line 163: Line 174:


In developer's terms, that mostly boils down to:
In developer's terms, that mostly boils down to:
* expect more and more scenery functionality to be procedurally added (e.g. [[Terragear_roadmap#Runtime_Airport_Generation|runways, taxiways]], whole airports)
* expect more and more viewer functionality to be decoupled from the simulator (fgviewer being the prototype here)
* expect more and more viewer functionality to be decoupled from the simulator (fgviewer being the prototype here)
* expect more and more viewer/GUI features to be made optional through a [[FlightGear Headless]] mode during startup
* expect more and more viewer/GUI features to be made optional through a [[FlightGear Headless]] mode during startup
Line 168: Line 180:
* expect [[FGPanel|FGPanel standalone panel rendering]] functionality to be merged back into the main fgfs code base, provided through [[FGViewer]]
* expect [[FGPanel|FGPanel standalone panel rendering]] functionality to be merged back into the main fgfs code base, provided through [[FGViewer]]
* expect more work towards better system-wide reinit/reset support: http://wiki.flightgear.org/Reset_%26_re-init
* expect more work towards better system-wide reinit/reset support: http://wiki.flightgear.org/Reset_%26_re-init
* expect more and more launcher features to be integrated and provided as part of FlightGear {{forum link|p=191451}}
* expect FDMs to become re-initializable at runtime, expect support for multiple FDMs per session
* expect FDMs to become re-initializable at runtime, expect support for multiple FDMs per session
* expect more subsystem to become re-initializable at runtime, so that they can be dynamically enabled/disabled to facilitate the fgviewer and headless efforts: http://wiki.flightgear.org/FlightGear_Run_Levels
* expect more subsystem to become re-initializable at runtime, so that they can be dynamically enabled/disabled to facilitate the fgviewer and headless efforts: http://wiki.flightgear.org/FlightGear_Run_Levels
Line 190: Line 203:
Also, there's another outdated category titled "Code Cleanup": http://wiki.flightgear.org/Category:Code_Cleanup
Also, there's another outdated category titled "Code Cleanup": http://wiki.flightgear.org/Category:Code_Cleanup


Another option would be taking a look at the "Google Summer of Code" category which also lists project ideas collected over the years:  [[GSoC: Candidate Projects]]. We also have a separate sub forum for GSoC here: http://flightgear.org/forums/viewforum.php?f=38
Another option would be taking a look at the "Google Summer of Code" category which also lists project ideas collected over the years:  [[GSoC: Candidate Projects]]. We also have a separate sub forum for GSoC here: {{forum url|f=38}}


In other words: '''pick your poison :)'''
In other words: '''pick your poison :)'''
Line 199: Line 212:


Please make sure to first search the issue tracker before possibly reporting a dupe, thanks!
Please make sure to first search the issue tracker before possibly reporting a dupe, thanks!
Bug reports should ideally be accompanied with a test case to reproduce an issue, but also a backtrace, see: [[Howto:Debugging FlightGear Crashes#Debugging Segfaults & Obtaining Backtraces]].


This is also an excellent place to get started helping and contributing to FG, i.e. by triaging bug reports, discussing feature requests, posting patches or finding new ideas to work on. This is also a very good place to get in touch with other core developers.
This is also an excellent place to get started helping and contributing to FG, i.e. by triaging bug reports, discussing feature requests, posting patches or finding new ideas to work on. This is also a very good place to get in touch with other core developers.
Line 211: Line 226:
There's a fully searchable archive available here: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/
There's a fully searchable archive available here: http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/


In addition, the FlightGear forums are increasingly used for interesting development related discussions, please note though that these are usually not specific to FG core development, but instead general development (aircraft, scenery, shaders, scripting): http://flightgear.org/forums/
In addition, the FlightGear forums are increasingly used for interesting development related discussions, please note though that these are usually not specific to FG core development, but instead general development (aircraft, scenery, shaders, scripting): {{forum url}}


If there's something particular that you are interested in, it's always a good idea to search these resources (wiki, forum, mailing list) to find related discussions.
If there's something particular that you are interested in, it's always a good idea to search these resources (wiki, forum, mailing list) to find related discussions.
Line 221: Line 236:


= Important docs =
= Important docs =
There's a wealth of documentation to get you started available in [http://gitorious.org/fg/fgdata/trees/master/Docs $FG_ROOT/Docs]
There's a wealth of documentation to get you started available in {{fg root file|Docs}}


API docs auto generated from source are at http://api-docs.freeflightsim.org/


Even more documentation can be found in our wiki, here: http://wiki.flightgear.org/
Even more documentation can be found in our wiki, here: http://wiki.flightgear.org/
Line 243: Line 259:
The SimGear code base is somewhat less archaic and more modern actually. And if you are interested in contributing to the OpenGL/SceneGraph department, you'll inevitably need to look into OpenSceneGraph (OSG), too - which really is "modern C++".
The SimGear code base is somewhat less archaic and more modern actually. And if you are interested in contributing to the OpenGL/SceneGraph department, you'll inevitably need to look into OpenSceneGraph (OSG), too - which really is "modern C++".


SimGear is fairly well-maintained code base that contains a fair amount of doxygen comments, that means that it's easy to create doxygen documentation for SimGear. For example, see: http://simgear.sourceforge.net/doxygen/
SimGear is fairly well-maintained code base that contains a fair amount of doxygen comments, that means that it's easy to create doxygen documentation for SimGear. For example, see: http://api-docs.freeflightsim.org/simgear/


Note that, at the time of reading, this may be outdated, so if you are interested in using the latest doxygen docs, you are well advised to run doxygen against your own latest simgear clone.
Note that, at the time of reading, this may be outdated, so if you are interested in using the latest doxygen docs, you are well advised to run doxygen against your own latest simgear clone.
Line 252: Line 268:
If your C++ is rusty and you'd just like to get started quickly, there are also certain FG components that are strictly (largely) pure C, the Nasal interpreter is just one example (Nasal is FlightGear's built in scripting language): http://wiki.flightgear.org/Nasal_scripting_language
If your C++ is rusty and you'd just like to get started quickly, there are also certain FG components that are strictly (largely) pure C, the Nasal interpreter is just one example (Nasal is FlightGear's built in scripting language): http://wiki.flightgear.org/Nasal_scripting_language


The Nasal interpreter is part of the SimGear project, and can be found in $SG_SRC/nasal: http://gitorious.org/fg/simgear/trees/next/simgear/nasal
The Nasal interpreter is part of the SimGear project, and can be found in $SG_SRC/nasal: {{simgear url|trees/next/simgear/nasal}}
 
The longest-standing issue related to Nasal scripting is fixing its Garbage Collector (GC) to become generational, incremental or even concurrent, this is to reduce main loop impact (frame rate & frame spacing), see [[How the Nasal GC works]] to learn more. Almost certainly, we're going to adopt an existing GC library, or even implement an interface to experiment with different GC schemes, and allow those to be selected at startup.


Adding new extension functions to the built-in Nasal interpreter is documented here: [[Howto: Extend Nasal]].
Adding new extension functions to the built-in Nasal interpreter is documented here: [[Howto: Extend Nasal]].
Line 260: Line 278:
None of this requires any C++ knowledge!
None of this requires any C++ knowledge!


Only the scripting interface connecting the Nasal interpreter and FlightGear is implemented in C++, it can be found in $FG_SRC/Scripting: http://gitorious.org/fg/flightgear/trees/next/src/Scripting
Only the scripting interface connecting the Nasal interpreter and FlightGear is implemented in C++, it can be found in {{fg src file|Scripting}}


Basically, the scripting interface implements a custom SGSubsystem, so that the Nasal interpreter can be run as a FlightGear system. In addition, all FlightGear-specific extension functions are to be found there. Increasingly, this folder also contains wrappers to map FlightGear classes to Nasal space in an OOP fashion, so that not just functions, but full "objects" are provided, which are computed lazily. If that's what you are interested in, you should take a look at the NasalPositioned.cxx source code, which demonstrates how this is done.
Basically, the scripting interface implements a custom SGSubsystem, so that the Nasal interpreter can be run as a FlightGear system. In addition, all FlightGear-specific extension functions are to be found there. Increasingly, this folder also contains wrappers to map FlightGear classes to Nasal space in an OOP fashion using the [[Nasal/CppBind]] framework, so that not just functions, but full "objects" are provided, which are computed lazily. If that's what you are interested in, you should take a look at the NasalPositioned_cppbind.cxx source code, which demonstrates how this is done.


In other words, even without knowing C++, you can contribute to FlightGear core by extending the Nasal system. If you have some specific project in mind, you could probably implement it largely in scripting space using Nasal and only augment it as required with new extension functions in C space.
In other words, even without knowing C++, you can contribute to FlightGear core by extending the Nasal system. If you have some specific project in mind, you could probably implement it largely in scripting space using Nasal and only augment it as required with new extension functions in C space.
Line 275: Line 293:


You may even find people interested in your idea and teaming up with you!
You may even find people interested in your idea and teaming up with you!
== Scripting Hooks ==
Another straightforward way to get started adding C++ code is using the [[Nasal/CppBind]] framework to expose built-in C++ classes to Nasal and enable base package contributors to make use of these, without bugging core developers to implement certain features directly. For C++ developers it is generally less time consuming (and often more rewarding) to implement abstract frameworks and infrastructure, rather than individual features.
While the number of core developers has been decreasing during the last 12-18 months, we do have an increasing number of base package developers, so implementing generic hooks for them makes sense because core developers cannot possibly implement each requested feature.


== Adding new subsystems ==
== Adding new subsystems ==
Line 285: Line 308:


= Some Ideas =
= Some Ideas =
== Additional Scripting Bindings ==
{{CppBind Ideas}}
== CompositeViewer support ==
This is a long-standing feature request, for details, please see [[CompositeViewer Support]].
== World Scenery 3.0 ==
The Terragear maintainers are looking for volunteers to help with development on the next world scenery project.  If you've ever wondered how a full 3D model of earth can be generated from raw data, now is your chance.  See the plan at [[World Scenery 3.0 roadmap]].


== JPEGFactory ==
== JPEGFactory ==
 
{{Note|Also see [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/053287a7-005d-4fd0-a1ee-96f1194ea904%40email.android.com/#msg32398628]}}
{{cquote|actually the entire JPEGFactory option could likely be removed, and replaced with using the osgDB Image plugins to create a JPEG or PNG. And then it wouldn't need to be a CMake option at all. If anyone would like to attempt this, please ask and I can suggest where to start, it's a nice small project<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40211.html|title=<nowiki>Re: [Flightgear-devel] Enabling JPEG factory causes fgfs/GIT to fail compiling</nowiki>|author=James Turner|date=Tue, 11 Jun 2013 22:40:38 -0700}}</ref>|James Turner}}
{{cquote|actually the entire JPEGFactory option could likely be removed, and replaced with using the osgDB Image plugins to create a JPEG or PNG. And then it wouldn't need to be a CMake option at all. If anyone would like to attempt this, please ask and I can suggest where to start, it's a nice small project<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40211.html|title=<nowiki>Re: [Flightgear-devel] Enabling JPEG factory causes fgfs/GIT to fail compiling</nowiki>|author=James Turner|date=Tue, 11 Jun 2013 22:40:38 -0700}}</ref>|James Turner}}


Line 313: Line 347:
station.  It could also be fun for sharing/broadcasting your simulator
station.  It could also be fun for sharing/broadcasting your simulator
session and probably could be made to work with a web video server.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40751.html|title=<nowiki>Re: [Flightgear-devel] --jpg-httpd command line option</nowiki>|author=<nowiki>Curtis Olson</nowiki>|date=<nowiki>Tue, 17 Sep 2013 11:51:00 -0700</nowiki>}}</ref>|<nowiki>Curtis Olson</nowiki>}}
session and probably could be made to work with a web video server.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40751.html|title=<nowiki>Re: [Flightgear-devel] --jpg-httpd command line option</nowiki>|author=<nowiki>Curtis Olson</nowiki>|date=<nowiki>Tue, 17 Sep 2013 11:51:00 -0700</nowiki>}}</ref>|<nowiki>Curtis Olson</nowiki>}}
{{cquote|<nowiki>I wanted to capture the FG imagery and
stream it over the web... (or some similar solution)
</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg10533.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}


{{cquote|<nowiki>I've seen other
{{cquote|<nowiki>I've seen other
apps that can do this so I know it's technically possible, and I imagine
apps that can do this so I know it's technically possible, and I imagine
not too much coding once you figure out the magic to make it happen.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40751.html|title=<nowiki>Re: [Flightgear-devel] --jpg-httpd command line option</nowiki>|author=<nowiki>Curtis Olson</nowiki>|date=<nowiki>Tue, 17 Sep 2013 11:51:00 -0700</nowiki>}}</ref>|<nowiki>Curtis Olson</nowiki>}}
not too much coding once you figure out the magic to make it happen.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40751.html|title=<nowiki>Re: [Flightgear-devel] --jpg-httpd command line option</nowiki>|author=<nowiki>Curtis Olson</nowiki>|date=<nowiki>Tue, 17 Sep 2013 11:51:00 -0700</nowiki>}}</ref>|<nowiki>Curtis Olson</nowiki>}}
{{cquote|<nowiki>VLC does this better than ffmpeg, so it's probably a good idea to study it's
codebase for streaming code. Also, MJPEG is nice, but as a container I'd
choose Ogg/Theora instead of H264 since they're entirely open.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40756.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}
{{cquote|<nowiki>Note if you want actual good performance from this system, there's much smarter
things that could be done, such as grabbing the frame buffer each normal
rendering frame, instead of re-rendering the scene each time an HTTP get is
received. That would need much more drastic changes to the system however.</nowiki><ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40757.html|title=<nowiki></nowiki>|author=<nowiki></nowiki>|date=<nowiki></nowiki>}}</ref>|<nowiki></nowiki>}}


{{cquote|<nowiki>And obviously it does require that cmake finds the  
{{cquote|<nowiki>And obviously it does require that cmake finds the  
Line 342: Line 389:
We could probably also look at using the [[Canvas]] system with some additional hooks, i.e. for getting a handle to the osg::Image, so that it can be serialized through Nasal and some cppbind glue, that would make it possible to depreciate the JPEGFactory code and use the Canvas system instead (i.e. unifying the 2d rendering backend).  
We could probably also look at using the [[Canvas]] system with some additional hooks, i.e. for getting a handle to the osg::Image, so that it can be serialized through Nasal and some cppbind glue, that would make it possible to depreciate the JPEGFactory code and use the Canvas system instead (i.e. unifying the 2d rendering backend).  


Being able to render camera views to a canvas texture has been previously requested a number of times, e.g. for implementing "mirrors" or tail cameras (A380) [http://flightgear.org/forums/viewtopic.php?f=6&t=13798] [http://flightgear.org/forums/viewtopic.php?f=37&t=20057&p=184301#p184284] [http://www.flightgear.org/forums/viewtopic.php?f=6&t=13798&hilit= ]
Being able to render camera views to a canvas texture has been previously requested a number of times, e.g. for implementing "mirrors" or tail cameras (A380) {{forum link|t=13798}} {{forum link|p=184284}} {{forum link|t=13798}} {{forum link|t=6184}} {{forum link|p=31252}}, and getting a handle to the buffer for serialization purposes would also allow us to reimplement the screenshot feature on top of canvas/Nasal, and even serve live image data through the httpd component.
[http://www.flightgear.org/forums/viewtopic.php?f=6&t=6184&hilit= ] [http://www.flightgear.org/forums/viewtopic.php?f=4&t=3353&p=31252&hilit=#p31252 ], and getting a handle to the buffer for serialization purposes would also allow us to reimplement the screenshot feature on top of canvas/Nasal, and even serve live image data through the httpd component.


* [[Howto:Use a Camera View in an Instrument]]
* [[Howto:Use a Camera View in an Instrument]]
Line 364: Line 410:
[[Category:Howto]]
[[Category:Howto]]
[[Category:Core developer documentation]]
[[Category:Core developer documentation]]
[[ru:Howto:Приступая к разработке ядра]]