I don't think it would not be incredibly difficult, but it would require some changes to the Irrlicht engine if you wanted it to work exactly like you've shown above.
There are a few ways you could go about this. You could implement your own IReadFile derived class that would request and read data from a socket [using http]. Another way would be to write some code to download the entire file first and then return a pointer to the local copy of the file.
This is interesting idea. Maybe I'll tinker with the idea of making the file manager extensible via plugin and writing a set of web capable plugins.
Thanks a lot. If you develop some plugin please let me know, because changing the IReadFile class is something above my knowledge for now.
This idea could be used for example to create a 3D photo gallery like My Pictures 3D, but instead of changing the folder in local drive to select your pictures and then distribute the executable (everytime you want to include new pictures), you just point to a web address and update the files online.
This way you could distribute only one copy of your executable and update your photo exhibition more frequently.
I don't know whether it's possible to use the windows platform sdk together with devc++. If you can't... Just google around a little bit and search for "c++ source http download" or something compareable. There should be tons of samples out there and most of them feature a quite simple interface like the one mentioned above.
how could it be possible to point to a web location to get all of the models and textures? you know, as in having the *.zip on a server somewhere.
when you call the addZipFileArchive();, Irrlicht doesn't laod the archive itself does it? Doesn't it just use that as the location to pull the models and textures from?
hmmm...I may try this out for the fun of it.
Join us in the Irrlicht chatroom:
[url]irc://irc.freenode.net/irrlicht[/url]
I love deadlines. I like the whooshing sound they make as they fly by. -D.Adams
Depending on how you want to do it, you could just write a layer that would download the file and then open it from a cache location. This would be incredibly slow for many files, but it might not be bad for a few files that you could preload.
Ideally the IFileSystem interface would have addFileReader() and removeFileReader() methods and an new IFileReader interface for accessing files. The zip/pak file reading code could be taken out of the file system implementation and put into external file readers. You could then write a derived file reader that would download a file and return an IReadFile for it.
class IFileReader : public IUnkown
{
public:
//!
virtual bool isLoadableFile(const c8* filename) = 0;
//!
virtual IReadFile* getReadFile(const c8* filename) = 0;
};
class IFileSystem : public IUnknown
{
// all of the existing file system decls
public:
//!
virtual void addFileReader(IFileReader* reader) = 0;
//!
virtual void removeFileReader(IFileReader* reader) = 0;
};
If you wrote a system like this, it could be more extensible than the existing file system implementation. It would allow the user community to make file readers without having to touch a line of the file system code.