Ancient Spaces Blog

Serializification.

As it turned out the Boost serialization library had a weird undocumented idiosyncrasy in that certain lines of code depended on others in a way which induced an ordering in the header files wherever serialization was used.

If I put this at the top of my files, everything works just fine:

#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>


#include <boost/serialization/utility.hpp>
#include <boost/serialization/serialization.hpp>
#include <boost/serialization/tracking.hpp>
#include <boost/serialization/map.hpp>


Heaven forbid, however, that I dare put:

#include <boost/serialization/utility.hpp>
#include <boost/serialization/serialization.hpp>
#include <boost/serialization/tracking.hpp>
#include <boost/serialization/map.hpp>


#include <boost/archive/text_iarchive.hpp>
#include <boost/archive/text_oarchive.hpp>


Naturally, these files should include their dependancies implicitly in the way they are defined so that the order does not matter. This is not the case with the existing version of the library. The author was reachable through the Boost mailing list and ensures me that it will all be fixed in the next release of this library which will be released real soon now.

After clearing that hurdle I am instantly faced with another one. As it turns out, the way we define our vectors and other objects (Quaternions, Colours..) they are nothing but aliases for Ogre's own definitions of them. This posed a problem for serialization because Ogre of course does not define how Boost's serialization library should handle them.

So at first I tried to derive our own versions of these objects which would inherit the properties of the Ogre ones and add definitions for serialization, but this introduced a new compllication in that their definitions are subtly interdependant, so that extending one would mean redefining certain parts of their functionality to depend on the redefined versions of the others instead of on the original Ogre versions of them. Eventually this became too convoluted and complex, so I tried an alternative approach which has been working well.

What I did was to use a feature of the Boost serialization library which permits a function to be written which specifies how to serialize an object without intruding on the definition of the object itself, so long as the object's original definition exposes an interface powerful enough to allow for the object fully to be deconstructed and reconstructed through that interface alone. Fortunately, the objects in question turned out to expose everything publically because they are really just mathematical primitives, which are fairly transparently just data (or specifically "Plain-Old-Data" in the lingo :P).

So, now a small part of serialization is somewhat working, although I have yet to test whether it actually does what it is supposed to do. Serialization of properties, both for SceneElements and the Scene itself is currently missing and will prove painful. The whole hierarchy of RenderNodes and process of reconstructing them is still to come, as well as the serialization of the whole scripting system...

Until next time,
~ Dieter