hopefully i phrase this so it makes sense :)
the current flaw i see in my wrap of Irrlicht is just that... its a wrap. while working fantastic out of the box, its in the extending via BMAX area that has an issue. currently if you subclassed a type and overrode a method, you could call that method from BMAX and it would work just fine... but the C engine would not run the overridden code if it were to call that method (with the exception of the callback classes). now, while hashing out callback classes i have worked out a way to do this using function pointers. this will give the BMAX developer the ability to subclass a BMAX type, use BMAX code in overridden methods, and have it run by the C engine when the engine calls it. ideally the BMAX developer should be able to customize Irrlicht and not need to write any C code (unless they wanted to of course). another cool thing is that it doesnt take customization of the base Irrlicht engine.
since it would be a huge delay, im not going to perform what needs to be done on every class in Irrlicht so i want to try to determine what classes a 3d developer would most likely want to extend. the issue i have is im not knowledgable enough to have the foresight to know which classes those are. what i would like, is someone to review the available classes in Irrlicht and come up with a list of classes that would most likely need to be subclassable (preferably ordered from most to least likely). like ISceneNode for example... in order to create a custom node, this is a definate one that needs to be able to be subclassed. the namespaces of concentration would be scene, video, and gui.
|
