Time for action — using resources.cfg to load our models

Using our previous application, we are now going to parse the resources.cfg.

  1. Replace the loading of the zip archive with an instance of a config file pointing at the resources_d.cfg:
    Ogre::ConfigFile cf;
    cf.load(«resources_d.cfg»);
    
  2. First get the iterator, which goes over each section of the config file:
    Ogre::ConfigFile::SectionIterator sectionIter = cf.getSectionIterator();
    
  3. Define three strings to save the data we are going to extract from the config file and iterate over each section:
    Ogre::String sectionName, typeName, dataname;
    while (sectionIter.hasMoreElements())
    {
    
  4. Get the name of the section:
    sectionName = sectionIter.peekNextKey();
    
  5. Get the settings contained in the section and, at the same time, advance the section iterator; also create an iterator for the settings itself:
    Ogre::ConfigFile::SettingsMultiMap *settings = sectionIter.getNext();
    Ogre::ConfigFile::SettingsMultiMap::iterator i;
    
  6. Iterate over each setting in the section:
    for (i = settings->begin(); i != settings->end(); ++i)
    {
    
  7. Use the iterator to get the name and the type of the resources:
    typeName = i->first;
    dataname = i->second;
    
  8. Use the resource name, type, and section name to add it to the resource index:
    Ogre::ResourceGroupManager::getSingleton().addResourceLocation(dataname, typeName, sectionName);
    
  9. Compile and run the application, and you should see the same scene as before.

What just happened?

In the first step, we used another helper class of Ogre 3D, called ConfigFile. This class is used to easily load and parse simple configuration files, which consist of name-value pairs. By using an instance of the ConfigFile class, we loaded the resources_d.cfg. We hardcoded the filename with the debug postfix; this isn't good practice and in a production application we would use #ifdef to change the filename depending on the debug or release mode. ExampleApplication does this; let's take a look at ExampleApplication.h line 384:

#if OGRE_DEBUG_MODE
cf.load(mResourcePath + "resources_d.cfg");
#else
cf.load(mResourcePath + "resources.cfg");
#endif

Structure of a configuration file

The configuration file loaded by the helper class follows a simple structure; here is an example from resource.cfg. Of course your resource.cfg will consist of different paths:

[General]
FileSystem=D:/programming/ogre/ogre_trunk_1_7/Samples/Media

[General] starts a section, which goes on until another[sectionname] occurs in the file. Each configuration file can contain a lot of sections; in step 2 we created an iterator to iterate over all the sections in the file and in step 3 we used a while loop, which runs until we have processed each section.

A section consists of several settings and each setting assigns a key a value. We assign the key FileSystem the value D:/programming/ogre/ogre_trunk_1_7/Samples/Media. In step 4, we created an iterator so we can iterate over each setting. The settings are internally called name-value pairs. We iterate over this map and for each entry we use the map key as the type of the resource and the data we use as the path. Using the section name as resource group, we added the resource using the resource group manager in step 8. Once we had parsed the complete file, we indexed all the files.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.133.157.142