MakoEnergy
commented
11 years ago For the most part, only the graphics namespace, the Entresol, the Resource system, and the scene object wrappers in the Mezzanine namespace that I haven't fully figured out what to do with in the long term reference bits of Ogre. The Entresol needing Ogre is pretty much a hold over from the old system and is initialized there because of the convenience of knowing when it is initialized. Namely that it will be there when the other managers are made, keep in mind this mentality was before unit tests were around so independence in the systems was stressed less. The Resource refactor is a pretty big deal for a few reasons( I will probably be repeating a few things here, but just to have it all in one place ):
- Unhooking from the Ogre resource system means our thing can be all on it's own. Not just in the Mezzanine, but also apart from the Mezzanine, just like the DAGFrameScheduler. So we get more libraries to pimp out.
- We get to expand support for archives. Technically we had this already but had to do it within the confines of Ogre's architecture, which is suboptimal.
- Once we make the change to streams where we have just a new API over the same old methods, resource system returns our style streams (which are derived from std::streams) and everything else accepts std::iostreams, we can make the Audio system it's own repo as well. Currently it's own reference to other Mezzanine components (aside from datatypes.h) is Resource::DataStream.
- Since we no longer have two subsystems fighting for Ogre components, we can safely just remove Ogre being initialized from the Entresol. Instead initializing it and destroying it in the GraphicsManager. In fact we should be able to push everything about Ogre into the Graphics namespace after the both the Resource system and world object refactors are complete.
- Wrappers for the Graphics namespace for some classes is complicated by the tight integration of the Ogre resource system with things such as meshes, materials, skeletons, etc.. Once it is unhooked and we start taking full advantage of that we'll be able to complete the wrappers to a number of these mandatory objects for easier manipulation of graphics data that will be necessary for more complicated constructs in the future (such as atmosphere systems, for example).
- Dependencies become simplified. Specifically there are 4 Ogre dependencies in our build configuration. They are all setup as "children" builds of Ogre. Updating to 1.9 alone means we no longer need to build FreeType(for the overlays that were put into a separate component). The resource system uses ZLib, and ZZipLib which we can remove. At least from the Ogre configuration. That just leaves FreeImage, which I know is optional and you can put your own Image codecs in, so I've been tinkering with the idea of putting FreeImage into the libincludes/common folder and touching it up so it doesn't generate so many damn errors, rather than having it be a child project of Ogre. Then we register the same codecs manually. This gives us the added benefit of having to change less when we update to a newer version of Ogre.
Our current resource system is a paper thin wrapper over Ogres resource system using a number of the same concepts. We need to handle our own I/O in ways that are sane for our engines own architecture. This means creating our own streams and systems for determining which steams are appropriate and grouping resources for easy loading and unloading.
From what little discussion has been made thus far, we want to use and extend std::iostreams, while providing another API (in the form of a derived class) that is a bit more friendly to newer programmers for common operations. Methods that generate/create streams should return our own derived type, while everything that accepts a stream should accept an std::iostream giving people the freedom to pass in other streams if absolutely necessary. Part of this means creating streams that will read from network sources, as well as streams that can read from compressed sources( see #32 ).