Thanks to Cearny getting me thinking about dynamic library loading, I’m changing the project structure to make it a LOT more flexible. Here’s what the new structure will look like:
OgreMain.dll will contain all the OgreCore and OgreEngine classes, including the basic SceneManager. This dll is loaded at application initialisation for ease of use by external apps (no manual binding to functions/classes) and will be the only library external apps have to link to.- OgreBspSceneManager.dll will contain all the SceneManager specialisations for indoor rendering based on Quake3 levels. All SceneManager specialisations will be loaded dynamically, and new implementations can be provided by new dlls and changing the SceneManagers.cfg entry for the scene type required.
- OgreD3DEngine.dll will contain all the specialisations for Direct3D and is loaded dynamically. New render system implementations (e.g. OgreGLEngine.dll) can be added without recompiling any other component.
- OgrePlatform.dll will contain all the platform-specific code and is loaded dynamically as required. On other platforms an alternative library (OgrePlatform.so) can be provided to provide concrete versions of classes like RenderWindow.
The ‘link’ stage of all of this stuff gets a little hairy but my proof of concept works great so I just have to be patient as I unpick all the static-link dependent code (there’s not that much actually, because Ogre uses abstract interface classes a lot anyway which makes the conversion easier). With a library the size of Ogre it takes a little time though – I reckon I’ll have it done by the end of the weekend.
The big bonus is that once this is done, render system implementations, platform implementations and new scene managers can be plugged in with no recompilation required of either the core Ogre dll or any application built on it, which is very nice.
This work has delayed my work on text material scripts (native Ogre ones, not Quake3 .shader scripts which I already load) and particle systems but it’s well worth it.