I posted that example of my "TinyXML Handle Addition", what I did last night was expand that handle to act as if it were the handle and the element. This way I can iterate through the rows along the current handle and pull the attributes. So I've got to the point where I can do something like this:
XMLHANDLE xOMGWTF = xDocument.GetHandle()["x"]["OMG"]["WTF"];// run through all of the BBQ'sfor(; xOMGWTF; ++xOMGWTF){const char* text = xOMGWTF("BBQ");MB(text);}// originalTiXmlElement* xOMGWTF = xDocument.GetHandle().Child("x", 0).Child("OMG". 0).Child("WTF", 0).Element();while(xOMGWTF ){const char* text = xOMGWTF ->Attribute("BBQ");xOMGWTF = element->NextSiblingNode();}Look a bit cleaner then before? This also makes loading data so much easier for me by simplify nested for loops. Which brings me to my resource loader which currently loads textures, fonts, sounds and animated sprites.
The first design of this loader was just a collection of 4 functions each with their own purpose, and the assumption was that you'd pass the right data to it.
Now I can't assume that even I would pass the right data to the function. So instead of calling pieces of resource loading functions, which is where I would find problems depending on the order in which they were called. (LoadSprites depends on LoadTextures) It now just calls all those private functions through a load function. If they're not in the XML file, well, tough luck it won't load the resources and will throw an error.
Since the underlying engine that I'm working on depends on ints as resource handles I had a big conflict with the XML loader class, which primarily deals with text (unless otherwise designed). I can't guarantee that myself or any others will give textures numbers in sequential order, so each texture is given a nick name and cross references with sprites. So when I pass a XML file to parse to this class it will load all of the resources in to the classes you passed (QuadManager, IRenderer) and store a text handle.
The implementation of this really drove me up the creek, and the main reason was the increasingly large number of resources I'll have to load. This basically means that if I load a resource I'll have to test when I use GetTexture("game-tex") if it's non-negative. Seeing as I have to somehow guarantee that the proper resources are loaded. I'm not prepared to make 100 or 1 if statement(s) so I decided to use catch and throw.
To be honest I've always had some kind of a bias against catch and throw, it just seems to -- unclean. It could have been that I remember it being frowned upon by some when I was first starting, the time where linker errors were my worst nightmare. Since I've started I've rarely used catch and throw for these reasons. However I found this one case where it is EXTREMELY helpful in catching errors.
So now I got a little bit of work to do, I still have to devise a way to incorporate FlatLand Physics in and FMOD. Once I get those two libraries I think I'll be ready to assemble the game.
