[XML-Loader] Parser, Definitions
Moderator: PPS-Leaders
- Dorian
- Human Space Navy Lieutenant
- Posts: 20
- Joined: Mon Oct 01, 2007 9:15 am
- Location: Walliswil-Wangen
- Contact:
[XML-Loader] Parser, Definitions
I've found a really easy to use xml-parser class, which I think will fit our needs. You can find additional infos about it on the wiki page http://www.orxonox.net/wiki/XML-Loader
Now my question is, which things have to be in a space level xml file, and do we also need other xml files (e.g. for game options, savegames, fps, ai... )?
Now my question is, which things have to be in a space level xml file, and do we also need other xml files (e.g. for game options, savegames, fps, ai... )?
Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it. (Linus Torvalds)
Hi Dorian
I think it's great you start the next day you got your assignment.
We usually put the thread about the PPS works into the Developers Journal. I'll move this thread soon.
I don't know if Ogre already has a XML-loader of some kind
...
There is something called XMLConverter in Ogre. I'm not sure, but I think it only serves to convert XML to/from the mesh format of Ogre. So single mesh.
I don't think this solves the problem.
The used XML-library is tinyXML creating a whole DOM-tree in the memory.
Read this post in the Ogre Forum to find out more about that converter.
Tell us what you think. I guess your parser isn't that bad either, so after a quick look at the XMLConverter of Ogre should clarify what is better.
To your questions:
There are plenty of xml-files in the data repository of Orxonox. You can check it out, but it's quite some MB (all the data) so you probably just want to go through with your browser. There all the oxw and oxc or what they are called are basically XML files we use (also the data.oxd should be one when I'm not mistaken).
It lies in your hands if you just want to support this format or if you want to change things. There is for sure space for improvement.
We will also need an XML file for save games for sure. Beside that I'm not sure what we can use with XML as well, except the COLLADA Importer. COLLADA is an XML-based mesh format.
I would suggest following work flow:
Hope I was able to help. Post any questions you may have.
I think it's great you start the next day you got your assignment.
We usually put the thread about the PPS works into the Developers Journal. I'll move this thread soon.
I don't know if Ogre already has a XML-loader of some kind
...
There is something called XMLConverter in Ogre. I'm not sure, but I think it only serves to convert XML to/from the mesh format of Ogre. So single mesh.
I don't think this solves the problem.
The used XML-library is tinyXML creating a whole DOM-tree in the memory.
Read this post in the Ogre Forum to find out more about that converter.
Tell us what you think. I guess your parser isn't that bad either, so after a quick look at the XMLConverter of Ogre should clarify what is better.
To your questions:
There are plenty of xml-files in the data repository of Orxonox. You can check it out, but it's quite some MB (all the data) so you probably just want to go through with your browser. There all the oxw and oxc or what they are called are basically XML files we use (also the data.oxd should be one when I'm not mistaken).
It lies in your hands if you just want to support this format or if you want to change things. There is for sure space for improvement.
We will also need an XML file for save games for sure. Beside that I'm not sure what we can use with XML as well, except the COLLADA Importer. COLLADA is an XML-based mesh format.
I would suggest following work flow:
- Find out about the XML implementation in Ogre.
- Decide whether you want to use your library or use what Ogre is using.
- Think about extending Ogre (engine development) or add things to Orxonox (game development).
- Find out what you want to import (save games, COLLADA, level, mount points, etc.)
- Start implementation
Hope I was able to help. Post any questions you may have.
"I'm Commander Shepard and this is my favorite forum on the internet."
- Dorian
- Human Space Navy Lieutenant
- Posts: 20
- Joined: Mon Oct 01, 2007 9:15 am
- Location: Walliswil-Wangen
- Contact:
Thanks for the reply.
1.) I checked out this tinyXML Library ogre is using. It has much more Classes and methods than the XML parser, but is also more complicated to use. It can both read and write XML Files. I tried to compile and run it on tardis, but didn't suceed yet, don't know if there's an error with solaris, or the stl, or the encoding or whatever. XML support in ogre is only used for this mesh importing thing. I didn't find any other XML stuff in the API or in the docs.
2.) I also tried this xmlparser I found in the first place, and after playing around with the makefile I was able to compile and run it. This parser is easy to use because it has only one class object which can do a lot of things. It's also possible to write XML files with it and it does not depend on any other libraries. It supports also some smart memory management to handle big files (wasn't yet able to test that, but the description on their page sounds good ) and it also has error handling if the file has incorrect XML. So this is my favorite library to use.
Example:
Input: click
Code-Sample:
Output:
For the XML-writing part we can either use this library or the library I described here. This lib is also very simple to use, but the writing-support in xmlParser is more object orientated and also not too complicated, and the xml-output is better formated.
3.) I don't exactly understand what you mean by extending ogre; I would see the implementation of this whole loader directly in Orxonox, for examl
ple as a xmlImport class with inherited subclasses for level, campaign etc importing. All the objects it loads from a level file will then be added to a levelmanager (who's writing this one, or is it also part of this ticket?). My idea is to make a generic importer which can then be inherited when it's clear what data the game needs, but I'm a but unsure at the moment where to start with all this stuff...
1.) I checked out this tinyXML Library ogre is using. It has much more Classes and methods than the XML parser, but is also more complicated to use. It can both read and write XML Files. I tried to compile and run it on tardis, but didn't suceed yet, don't know if there's an error with solaris, or the stl, or the encoding or whatever. XML support in ogre is only used for this mesh importing thing. I didn't find any other XML stuff in the API or in the docs.
2.) I also tried this xmlparser I found in the first place, and after playing around with the makefile I was able to compile and run it. This parser is easy to use because it has only one class object which can do a lot of things. It's also possible to write XML files with it and it does not depend on any other libraries. It supports also some smart memory management to handle big files (wasn't yet able to test that, but the description on their page sounds good ) and it also has error handling if the file has incorrect XML. So this is my favorite library to use.
Example:
Input: click
Code-Sample:
Code: Select all
XMLNode mNode=XMLNode::openFileHelper("campaign.xml","campaign");
const char* campaignName = mNode.getChildNode("name").getText();
const char* campaignIdentifier = mNode.getChildNode("identifier").getText();
const char* campaignDesc = mNode.getChildNode("description").getText();
cout << "Campaign: " << campaignName
<< ", Id: " << campaignIdentifier
<< ", Desc: " << campaignDesc << "\n";
XMLNode worldNode = mNode.getChildNode("worldlist");
XMLNode menuNode = worldNode.getChildNode("gamemenu");
const char* menuName = menuNode.getChildNode("name").getText();
cout << "Menu: "<<menuName
<<", containing "<<worldNode.nChildNode("SinglePlayerWorld")
<<" SinglePlayer items\n";
for (int x=0;x<worldNode.nChildNode("SinglePlayerWorld");x++)
{
XMLNode spgNode = worldNode.getChildNode("SinglePlayerWorld",x);
cout << "World: "<<spgNode.getChildNode("name").getText()
<< " ("<<spgNode.getChildNode("identifier").getText()
<< "), Path: "<<spgNode.getChildNode("path").getText()<<"\n";
}
Code: Select all
Campaign: default, Id: 0, Desc: The one and only default debug campaign
Menu: GameMenu, containing 8 SinglePlayer items
World: Cut Scene (1), Path: levels/sp_cutscene_intro.oxw
World: Space Station (2), Path: levels/sp_level_spacestation1.oxw
World: Space Station 1B (3), Path: levels/sp_level_spacestation1B.oxw
World: Vertical Scroller (4), Path: levels/vertical_scroller.oxw
World: Moonstation (5), Path: levels/sp_level_moonstation.oxw
World: Moonstation Hangar (6), Path: levels/sp_level_moonstation_hangar.oxw
World: Enemy Debug (7), Path: levels/debug_enemy.oxw
World: Adm Test (8), Path: levels/adm_test.oxw
For the XML-writing part we can either use this library or the library I described here. This lib is also very simple to use, but the writing-support in xmlParser is more object orientated and also not too complicated, and the xml-output is better formated.
3.) I don't exactly understand what you mean by extending ogre; I would see the implementation of this whole loader directly in Orxonox, for examl
ple as a xmlImport class with inherited subclasses for level, campaign etc importing. All the objects it loads from a level file will then be added to a levelmanager (who's writing this one, or is it also part of this ticket?). My idea is to make a generic importer which can then be inherited when it's clear what data the game needs, but I'm a but unsure at the moment where to start with all this stuff...
Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it. (Linus Torvalds)
The idea is that a class is XML loadable. So there should be a very generic interface which we can put onto each class we want to make loadable.
You probably need some information from the class which implements your interface, get this information with a method the developer has to overwrite.
For simplification: Imagine that every XML loadable class (except campaign and world) inherits from Ogre::Entity. I hope this helps a bit
About 3). I was not sure whether you want to use the XML library Ogre uses or your own. In the first case, you could have extended Ogre in a way that it would have been able to load our world files. Using this library now, it's clear you make it part of Orxonox.
You probably need some information from the class which implements your interface, get this information with a method the developer has to overwrite.
For simplification: Imagine that every XML loadable class (except campaign and world) inherits from Ogre::Entity. I hope this helps a bit
About 3). I was not sure whether you want to use the XML library Ogre uses or your own. In the first case, you could have extended Ogre in a way that it would have been able to load our world files. Using this library now, it's clear you make it part of Orxonox.
"I'm Commander Shepard and this is my favorite forum on the internet."
Hi Dorian & Beni,
I like the systematic approach to your xml interface implementation. For your information: The old Orxonox Implementation used tinyXML too.
But decide yourself which of the libraries you mentioned is best suited.
Idealistically at the end the programmer doesn't actually see the the abstract xml layer anymore and works with a very specific interface (for example functions like: LoadWorldEntity(), LoadCamera()). Therefore hiding unimportant xml specific stuff and reducing it to the things he/she actually wants to work with (e.g. space ships, cameras, sounds, music, etc.).
Following a short overview about the implementation of the old Orxonox, it might inspire you for your own implementation: we had a very decentralized approach: each entity that wanted to load something from xml implemented a certain virtual function loadParam(const XMLElement& element) which parsed the information for this entity from the xml file.
This function was the loading interface to this object. This can be done by making an abstract class (Loadable or something like that), which needs to be extended.
I like the systematic approach to your xml interface implementation. For your information: The old Orxonox Implementation used tinyXML too.
But decide yourself which of the libraries you mentioned is best suited.
Idealistically at the end the programmer doesn't actually see the the abstract xml layer anymore and works with a very specific interface (for example functions like: LoadWorldEntity(), LoadCamera()). Therefore hiding unimportant xml specific stuff and reducing it to the things he/she actually wants to work with (e.g. space ships, cameras, sounds, music, etc.).
Following a short overview about the implementation of the old Orxonox, it might inspire you for your own implementation: we had a very decentralized approach: each entity that wanted to load something from xml implemented a certain virtual function loadParam(const XMLElement& element) which parsed the information for this entity from the xml file.
This function was the loading interface to this object. This can be done by making an abstract class (Loadable or something like that), which needs to be extended.
- Dorian
- Human Space Navy Lieutenant
- Posts: 20
- Joined: Mon Oct 01, 2007 9:15 am
- Location: Walliswil-Wangen
- Contact:
I added an easy to use String to Number converter to my branch.
It is located in src/misc, if anyone wants to copy and use it for his work:
It even can parse strings such as "\n 123.45 \n\n a" correctly. If it fails to parse a string, it exits with an error message. If the number inside the string is hex or oct, use std::hex or std::oct as third argument to the class call.
It is located in src/misc, if anyone wants to copy and use it for his work:
Code: Select all
#include <string>
#include <iostream>
#include "misc/String2Number.h"
float f;
std::string s = " 123.45 ";
String2Number<float>(f, s);
std::cout << f << std::endl;
Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it. (Linus Torvalds)
- Dorian
- Human Space Navy Lieutenant
- Posts: 20
- Joined: Mon Oct 01, 2007 9:15 am
- Location: Walliswil-Wangen
- Contact:
Completely rewrote the loader today. It now works together with fabian's factories. At current state, there are now objects which parse an ambient light or a skybox tag in the level file. Every xml node in the level file between the <world></world> tags creates a factory and handles over the current xml node with its sub-elements. Added also a method for tokenizing a string, and to convert a string into numbers. This is used for example in the Ambient object class.
See sample implementation for the ambient light here
See sample implementation for the ambient light here
Only wimps use tape backup: real men just upload their important stuff on ftp, and let the rest of the world mirror it. (Linus Torvalds)
Who is online
Users browsing this forum: No registered users and 6 guests