TinyXMLResource implementation

[xadhoom]

Hi!

I was suprised that there was no code available to use TinyXML with the Ogre resource system. So I did it...
In the hope that nobody has to do this again or just need a starting point for implementing something similar I created a short wiki page here:

http://www.ogre3d.org/wiki/index.php/TinyXMLResource

I would appreciate comments especially regarding bugs and/or problems.

xad

[Roman]

Hello,

Great work! That's what I need. As xml parser I use TinyXML, but to deal with the Ogre resource system is a small problem, or we can say anything, what must be implemented extra.

Something like this doesn't work if we want to load ./Config/myconfigfile.xml, right?

Code: Select all

mRoot->addResourceLocation("Config", "FileSystem", "Config");
ResourceGroupManager->initialiseResourceGroup("Config");
TiXmlDocument doc;
doc.Load("myconfigfile.xml");
ResourceGroupManager->unloadResourceGroup("Config");

[Beauty]

Thanks!
Especially for the wiki page. (I did some little adds/changes)

But I'm not shure what are the advantages of it.
What you can do with it?
Use XML config files instead of the current resources.cfg?
Or write material files in XML format?

Generally it would be good if you add the source code to a public SVN (e.g. on Ogre Add-ons(?), Sourceforge, Google etc.). So the download link will not die in future and other users can add improvements.


For parsing the Ogre file format I created a simple parser (using regular expressions). This was needed for CaelumSharp (Caelum port for Mogre), because the Ogre parser classes aren't wrapped (I suppose).
The reflection methods of CaelumSharp also support inherits.

If there is a need for a converter from Ogre config file --> XML this code could be used as a base. The code is C#, but I think it's possible to port it to C++. If you have questions about you can look/post in this thread. The source code is here. I also wrote an example application for the parsing work. Ask me if you want it.

[Roman]

Use XML config files instead of the current resources.cfg?

Yes, for example. I do it by the way. My whole game configuration is based on xml. (terrain config files excluded)

[Beauty]

Yes, for dynamic config files this is really useful.
Are inherits possible within the loaded XML files?

If you like, you can add useful links to your wiki page (See Also section). E.g. to a suitable free XML editor or pages for deeper information about TinyXML.

[xadhoom]

Something like this doesn't work if we want to load ./Config/myconfigfile.xml, right?

Code: Select all

mRoot->addResourceLocation("Config", "FileSystem", "Config");
ResourceGroupManager->initialiseResourceGroup("Config");
TiXmlDocument doc;
doc.Load("myconfigfile.xml");
ResourceGroupManager->unloadResourceGroup("Config");

Oh, as far as I see you have to describe the folder from your working directory.

Example:
Working directory (where the .exe file is located): C:\MyCoolApp\bin\
The media directory (where the .xml file is located): C:\MyCoolApp\media\

The resulting path should then look like this:

Code: Select all

mRoot->addResourceLocation("..\media\", "FileSystem", "Config");

Thats the default behaviour for Ogres resource system. Otherwise you could declare the resource group directories in your resources.cfg or so as usual.
Or did I miss something? If you see some bugs or else just post here. I will fix the files then ofcourse.

@Beauty:
Thanks for the modification. As it seems my descriptioon was not very clear:
These classes just allow to open xml files (with TinyXML) like you would do with .mesh files. You only have to call create and load as described and you will get a resource which contains the actual xml data of the file. This is useful for everything where you describe things in xml...
I have a few Assets which are described in xml. For now I will use this class directly to benefit of the Ogre resource system (threading/background loading etc.).

Unfortunately I don´t know where to put these two classes. An SVN seems to be exaggerated. I think this download link won´t die that soon either.
SOme more links maybe interesting on the wiki page. But XML is no magic. It shouldn´t be a problem to figure the xml things out.


xad

[Beauty]

Inherits you can implement e.g. by hash tables.
If a group has a special property (like "abstract" or "inheritFrom:MyBaseSystem") your code could merge the groups.
For CaelumSharp we put all entries of a parent (abstract) group into a hash. Then we save the items of the child group into the same hash. The result you can save back to XML. This you make for all groups with the special properties. Then this would be an implementation of inheritance. For complex ressouces this can be useful. Just as an idea

[Beauty]

If it is not much code you can save it in the wiki.
The problem of private hosting is, that when people leave this project, some of them don't get PMs and you can't ask for the code. I saw that this really happens. So this is just for security reason.

[Penguin]

Inherits you can implement e.g. by hash tables.
If a group has a special property (like "abstract" or "inheritFrom:MyBaseSystem") your code could merge the groups.
For CaelumSharp we put all entries of a parent (abstract) group into a hash. Then we save the items of the child group into the same hash. The result you can save back to XML. This you make for all groups with the special properties. Then this would be an implementation of inheritance. For complex ressouces this can be useful. Just as an idea

Stuff like inheritance should really be used in a custom file format meant for scripting, like ogre's .material files. Xml files aren't really meant for that kind of use.

[Beauty]

Ogre .material files do support inheritance!

[Penguin]

Ogre .material files do support inheritance!

I was thinking about Caelum's file thing.

[Beauty]

Caelum uses the Parser classes of Ogre which support inheritance.
So its config files are fully compatible to Ogre material files.
Just as an info. Don't think I'm shouting

[Speedo]

Is there any particular advantage to having the Ogre resource manager handle things like this? All of my config files are XML, but the only class that touches the actual files is my Configuration Manager so I've just had it directly load them.

[xadhoom]

Beside consistency reasons with the rest of your ResourceManagement this approach offers you things like background loading, thread safe SharedPtr and ResourceGroup management. But if you just load a few files at the beginning to read some configs IMO this won´t be necessary. My primary reason to use this class is consistency!

xad

[Beauty]

I think one advantage is that it's easy to edit such files by a plain text editor, because it's a better overview. XML files you also can edit by a plain text editor, but the overview is not so goot. More comfortable would be an XML editor.
I suppose there are also historical reasons for the use of such config files.
Today I only would use XML for such files, because of wide spread support (editing/processing etc.) and the Schemas (XSD) for syntax check.
Maybe Sinbad could include this add-on to the 1.8 version (for alternative config files).

[Roman]

Hi,

Oh, as far as I see you have to describe the folder from your working directory.

Yes, the first parameter is my Config folder. You can also write

Code: Select all

mRoot->addResourceLocation("./Config/", "FileSystem", "Config");

if you want. I guess, both variants will be work.

The media directory (where the .xml file is located): C:\MyCoolApp\media\

I just call it Data (./data.pak as store for the contents). My config files are located in ./Configuration, they must be writeable.

Maybe Sinbad could include this add-on to the 1.8 version (for alternative config files).

Sinbad could first include a xml parser to Ogre. I don't know if he want an will do it in future. I really don't know what current happen. Alternatively, anybody could write an interface for the CEGUITinyXmlParser, CEGUIExpatParser or something else for Ogre, if it does not already exist. With a xml file as Ogre-configfile, it could be named Ogre.xml, several config schemes would be practicable. I think on the different acounts of windows' energy options, sound schemes, what else. You have a select box, where you can choose, save and delete the profiles within. Xml is adapted for saving such configuration, which includes a list of configuration profiles, not only one, what we current have.

[xadhoom]

AFAIK writing is currently not supported by the Ogre resource system (wait for the StreamSerializer classes in the next release). Alternatively you can just use the TinyXML internal Save method instead. But its not meant to be used like that TinyXMLResource::getXMLData() returns a TiXmlNode* which is actually the TinyXMLDocument. I upcasted it to disallow load and save methods at this point but you could easily cast it back and use Save() then.

About XML in Ogre. I´m not sure if there is the need for xml in Ogre. Ogre has a very powerful script system why should they change to xml? The advantages would be using a standard language with many available Editors and DTD, Schema checker but it seems that there is no substantial demand for it...
And by the way: Ogre scripts normally look cleaner and may have less parsing overhead.

Just my two cents about that topic...

xad

[Roman]

About XML in Ogre. I´m not sure if there is the need for xml in Ogre.

No direct, I would say. But it's a nice-to-have.

Ogre has a very powerful script system why should they change to xml?

Not change to, only support them. Ogre::ConfigFile and for example Ogre::XmlFile.

[Shockeye]

Hi,
I'm having trouble getting this to compile.(Microsoft Visual C++ 2008 Express Edition)
First it was giving me syntax errors relating to note recognizing TinyXML classes eg.";" required before "*" in "TinyXMLResource.h" where there was a TiXmlNodeas a return value.
So I added "#include <tinyxml.h> " and that cleared all of the syntax errors, but gave me:

tinyxmlresource.cpp(89) : error C2440: '=' : cannot convert from 'const TiXmlElement *' to 'TiXmlElement *'
1> Conversion loses qualifiers
tinyxmlresource.cpp(94) : error C2660: 'TiXmlDocument::SetError' : function does not take 1 arguments
tinyxmlresource.cpp(179) : error C2660: 'TiXmlDocument::SetError' : function does not take 1 arguments

the first one relates to:

Code: Select all

 TiXmlElement* node;
   for(node = rhs.mTinyXMLDoc.FirstChildElement(); node; node = node->NextSiblingElement())
      mTinyXMLDoc.InsertEndChild(*node);

But there is a non-const overload for FirstChildElement(), so how can it not convert?

The other two errors are clearer -
void TiXmlDocument::SetError( int err, const char* errorLocation, TiXmlParsingData* prevData, TiXmlEncoding encoding )
so are you using a different version of tinyxml ?(I'm using 2.5.3) Or is there some setting I need to change?

Thanks

[Shockeye]

I've got it to compile now, using a const_cast and adding some arbitrary args to the seterror calls: (mTinyXMLDoc.ErrorId(),0,0,TIXML_ENCODING_UNKNOWN);

But I'd still like to know how to do it the proper way.

[xadhoom]

Hi Shockeye!

Ok, first of all including the TinyXML is ofcourse necessary to get it work. I just did not include the header to leave it to the user to include the right files depending on his project.

The first problem you have is a bit strange.
The "const error" you get seams to occure because the compiler cannot find a const getter for a TiXmlElement.


The definition of SetError in my Xml version looks like this:

Code: Select all

void SetError( int err ) 
{
   assert( err > 0 && err < TIXML_ERROR_STRING_COUNT );
   error   = true;
   errorId = err;
   errorDesc = errorString[ errorId ]; 
}

We use a different (maybe older) version of TinyXml. Unfortunately I cannot find a version information in my source files.
To use the SetError method correctly you have to copy the error information from "rhs".
If you look into the SetError method you can see how these members are stored in the class.

xad

[Shockeye]

Thanks Xadhoom

I've got working now with the changes I made, after resolving a whole lot of linker errors (I had built it as a library, but that wouldn't play nice with my project, so I had to add the TinyXML sources to the project), so I'm happy now

I'd still like to resolve the need for const_cast, though. const_cast is naughty in most cases

[Speedo]

But there is a non-const overload for FirstChildElement(), so how can it not convert?

...

I'd still like to resolve the need for const_cast, though. const_cast is naughty in most cases

The object "rhs" is constant, so the non-const overload can only be called if you cast away that const-ness. It isn't (shouldn't) be necessary though. Just make "node" a pointer to const object.

Code: Select all

const TiXmlElement* node;

[Shockeye]

Thanks Speedo,
Thats actually so obvious I don't know why I didn't think of it. I guess I was too focused on the line where the error message was.