High-Level Architecture: Difference between revisions

m
no edit summary
No edit summary
mNo edit summary
Line 7: Line 7:
There are three big advantages to this over a monolithic simulation (e.g. FlightGear V3.6):
There are three big advantages to this over a monolithic simulation (e.g. FlightGear V3.6):
# It provides a robust environment to make the simulator multi-threaded, taking advantage of computers with multiple cores, or indeed running different parts of the simulation on different computers (including even different platforms and operating systems).
# It provides a robust environment to make the simulator multi-threaded, taking advantage of computers with multiple cores, or indeed running different parts of the simulation on different computers (including even different platforms and operating systems).
# It allows us to split out parts of the simulator such as [[AI]] (by [[Decoupling the AI Traffic System]]), the [[FDM]], [[Nasal]] scripting <ref>http://forum.flightgear.org/viewtopic.php?p=265721#p265721</ref> and Renderer from each other and less time-critical sub-systems such as [[Advanced weather|weather]] so that we can get consistent (and perhaps higher) frame-rates (i.e. reduced [[How the Nasal GC works|Nasal GC]] impact on frame rate).
# It allows us to split out parts of the simulator such as [[AI]] (by [[Decoupling the AI Traffic System]]), the [[FDM]], [[Nasal]] scripting <ref>http://forum.flightgear.org/viewtopic.php?p=265721#p265721</ref> and [[Supporting multiple renderers|Renderer]] from each other and less time-critical sub-systems such as [[Advanced weather|weather]] so that we can get consistent (and perhaps higher) frame-rates (i.e. reduced [[How the Nasal GC works|Nasal GC]] impact on frame rate).
# It provides a very good framework to allow anyone to create components that interact with FlightGear using programming languages other than C/C++ (think Ada, Java, Python etc), which may be running in their own threads, and reside in separate binaries<ref>http://sourceforge.net/p/flightgear/mailman/message/34196458/</ref>, which will be also easier to debug/troubleshoot (think regression testing, i.e. running a self-contained subsystem in a dedicated gdb/valgrind session), without having to know how to modify/patch and rebuild FlightGear.
# It provides a very good framework to allow anyone to create components that interact with FlightGear using programming languages other than C/C++ (think Ada, Java, Python etc), which may be running in their own threads, and reside in separate binaries<ref>http://sourceforge.net/p/flightgear/mailman/message/34196458/</ref>, which will be also easier to debug/troubleshoot (think regression testing, i.e. running a self-contained subsystem in a dedicated gdb/valgrind session), without having to know how to modify/patch and rebuild FlightGear.