20,741
edits
No edit summary |
|||
Line 143: | Line 143: | ||
|script_version = 0.40 | |script_version = 0.40 | ||
}}</ref> | }}</ref> | ||
== Concerns == | |||
It is hard to see a benefit having a binary integration of Python in the flightgear core. Using python to get/set properties and run fg-commands is already possible without any c++ integration.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/34792963/ | |||
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded | |||
Python interpreter as a FlightGear subsystem. </nowiki> | |||
|author = <nowiki> Torsten Dreyer </nowiki> | |||
|date = Jan 25th, 2016 | |||
|added = Jan 25th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
One major concern with the FGPythonSys integration is that it introduces an unpredictable (w.r.t. timing) step in the main loop getting us on step further away from constant frame rates.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/34796183/ | |||
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API | |||
(was Re: A FGPythonSys implementation: ...) </nowiki> | |||
|author = <nowiki> Torsten Dreyer </nowiki> | |||
|date = Jan 26th, 2016 | |||
|added = Jan 26th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
Instead of adding just-another-feature we need to strip it down to getting a fast and constand fps rendering engine. Everything else needs to run outside the main loop and has to interact with the core by, say HLA/RTI or whatever IPC we have.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/34793778/ | |||
|title = <nowiki> Re: [Flightgear-devel] A FGPythonSys implementation: The embedded | |||
Python interpreter as a FlightGear subsystem. </nowiki> | |||
|author = <nowiki> Torsten Dreyer </nowiki> | |||
|date = Jan 25th, 2016 | |||
|added = Jan 25th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
== Challenges == | == Challenges == |