Erik Hofman wrote:
Boris Koenig wrote:
Frederic is right that a plugin system is actually in contrast with the GPL (FlightGear's license), that requires everything to be opened when using some piece of GPL software within your project.
I don't think that would be a major problem, there's other opensource
(GPL'ed) software that makes use of modular enhancements (aka
"plugins")- the most prominent example being the Linux Kernel itself, whose plugin architecture meanwhile supports licence-validation - i.e. a
module needs to provide the licence under which it is available in
order to be loaded (This is a kernel 2.65 addition I think).
I'm still not convinced that a plugin system would be such a great idea for FlightGear.
Well, I am just making suggestion :-)
The project has outgrown C and even C++ by using some clever subsytem architecture and by using the property tree.
Well, regarding the "clever subsystem architecture" - is there any more detailed information available ?
It's actually quite simple, you create a derived class from SGSubsystem and you have to define a small set of functions:
class FGFX : public SGSubsystem
{public:
FGFX (); virtual ~FGFX ();
virtual void init (); virtual void reinit (); virtual void bind (); virtual void unbind (); virtual void update (double dt);
}
The init() functions should make sure everything is set and ready so the update() function can be run by the main loop. The reinit() function handles everything in case of a reset by the user.
The bind() and unbind() functions are to tie and untie properties.
The you can register this class at the sub system manager:
globals->add_subsystem("fx", new FGFX);Now the sub system manager calls the update() function of this class every frame. dt is the time (in seconds) elapsed since the last call.
Erik
_______________________________________________ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
