Jump to content
  • Advertisement
Sign in to follow this  

Loading Objects from Files

This topic is 4040 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I know that some people like the idea of: SoundFx a=SoundManager.Load("badExampleOfOODesign.wav"); However, I have been trying to get away from the whole concept of a "manager" (which I despise intensely and will not argue over in this thread, so please do not try). Then in the midst of working on my code for loading graphics from file into a generic Bitmap object I stumbled into this syntax for loading.
bmp::Bitmap bitmap;
std::ifstream ifs("testin.png",std::ios::in|std::ios::binary);
image_loader::PNGLoad<std::ifstream> pngl(ifs,bitmap);

PNGLoad needs to be an object since the private members of bitmap can only be accessed by a Visitor (actually I called it a Filter). The private data is contained fully within a memento object which has everything on the public access level. My primary reason for given Bitmap visitors was so that I could create a library of filters that modified the raw graphics data to apply certain effects (namely, alpha blending two images into one). The idea of using to load data was an after thought, but now I like it for the following reasons: 1) My syntax lets me specify the source stream so I can use fstream, or my custom stream that loads data from a pack file (multiple files in one file), or I can use whatever custom stream I come up with (load from RAM, zlib compressed stream, network stream, anything). 2) I can decouple IO from the design of the Bitmap object. This gives me the freedom to add loaders that store frequently loaded objects in memory so that they don't even require file IO. Or I can have the "Loader" tie objects together in the background so group wide methods can be applied to them. 3) I can also add methods to Bitmap without changing it (which is the purpose of the Visitor pattern), including adding other loading methods if I want (JPGLoader?). Of course the trade off is that changing Bitmap's data members may require that I edit all of it's Visitors. However, as far as IO is concerned I would have to do that anyway. Therefore when it comes to IO, the price of the Visitor pattern is just the cost of defining another object. For C++ that heavily relies on the STL that's nothing, you'll always have to define a ton of objects. So that inspired me to apply this technique to most if not all of my file IO with the syntax:
Object o;
Stream s(STREAM_PARAMETERS); // STREAM_PARAMETERS could be a file name
LoaderObject<Stream> lo(s,o);
s.close(); // not necessary as this is automatic with RAII

Or if I have a LoaderObject that already knows the stream use (possibly a Monostate) it can be:
Object o;
LoaderObject<Stream> lo(o,STREAM_PARAMETERS);

And I may even add this syntax as well:
ContainerWithAnOutputIterator c;
c.reserve(NUMBER_OF_OBJECTS_TO_LOAD); // if this is a vector or a similar type
Container paramList; // list of STREAM_PARAMETERS which again could be file names
LoaderObject<Stream> lo(o,paramList.begin(),paramList.end(),std::back_inserter(c));

So now I am thinking that if I pair all (or at least most) of my objects that need IO with a Loader object, I can create objects now and still have great flexibility in what I do with IO later. I admit that I have heard of the idea IO visitor objects before, but I have never seen an example or an explanation for why one would use it. However, now I understand.

Share this post

Link to post
Share on other sites
For my engine since I was writing it in C/C++ I used template specialization to load all my resources from an XML file that can specify anything from textures to sound files. I worked rather well a loading call was as simple as the following.

Mesh m = ResourceManager<Mesh>::load( xmlElement );

You could essentially do the same thing only make the param to the load function take a stream instead of an XML element.

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!