Data Structures | |
| class | nrEngine::FileStream |
| Derived class from IStream to provide streaming from files. More... | |
| class | nrEngine::EmptyFileStream |
| Empty file stream to represent empty files. More... | |
| class | nrEngine::FileStreamLoader |
| File stream loader is able to instantiate file stream objects. More... | |
| class | nrEngine::FileSystemManager |
| File system manager class handles all filesystem transparent to the user. More... | |
| class | nrEngine::IFileSystem |
| File system module interface that are managed by file system manager. More... | |
Files are storing the data needed for apropriate working of the engine and the underlying application. Files could be found on the disk but also on external media like ftp servers or similar things. You can either implement your own file loading routines to load such external files or you use the engine's file system which has the ability to be fully transparent to the user.
Our filesystem contains a manger which does manage all available virtual file systems. Each such virtual file system (vfs) can be either a local fs working on local files or an http implementation of this one working on files in the internet. Each such vfs is registerd by the manager, so it knows how to handle file requests.
Files are requested through it's name. So just ask a manger to open a file with name A.ext and it will ask each vfs if it does know such a file and ask them to open it. So for you as user there is no difference if the file is found on the local disk or on a ftp server. However transfering file data from external fs can be slow.
If you know where the file is, you could also specify the file position directly, by specifying the file location similar to "file:/A.ext" for local files and "ftp:/A.ext" for external files. So the manager will ask that vfs thats type is specified for appropriate file. This mechanism is very similar to unix one, so you should be familar with it.
There can also be some parameters to the certain vfs specified in the file path. For example you want to open a file on a certain ftp server and not the default one. So calling something like this "ftp:server.domain:user:password:/A.ext" will force the ftp-vfs to login on that server and download the file.
We definy that all parameters given to the certain vfs systems should be separated by : Which parameters can be given you can find in the documentation of each fs module. There is no matter how much parameters you set, the filename must be at last. i.e. "filesystem:param1:param2:..:paramn:/path/to/file/file.name" The given filename is always in context to the filesystem. For example for local files you specify relative path, for ftp-servers it is always absolute. Filename-conventions are always according to the module you use. Our standard module to load local files, does use simple convention that all file names are relative to the application and the path is separated by slash. Conversion to windows filenames is done by the modules automaticaly, so "file:d:/A.ext" refers to a file on disk d in windows.
In our engine you have a defualt filesystem which you can you for your own puprose. The filesystem we are using is based on std::ifstream so it is fully compatible to all system where std::ifstream works. The filesystem is built in the way that it can easy be replaced through plugins which can expand the functionality of the system.
Each file in the system is also a resource which is managed by resource manager. We do not want to separate the filesystem from resoure system (as in many engine's does) because so we get the ability of simple user interface and the possibility of controlling the files as resources (e.g. if they are used in streams and can be un/loaded at runtime).
If files are handled as resources you can also still able to manage your memory without forgetting of counting of the size which each file has. For example unstreamed file which is loaded completely in the memory does use a lot of free memory. The resource according to the file for example an image is working on that file. In a naive way you will get only the size of the image counted and the file size wuold be not mentioned in the resource system. So you didn't realy realize how much memory does your resource need. With the system we are using you know that the complete size of the resource is the image object and the file opened by it.
Also the possibility of using files like resource does centralize the managment of all opperations according to loading/unloading/removing. So you can also use scripts and just load resource "File" which is handled like normal resource but provides reading to the file.
Our filesystem has also the possibility to add an archive support to the filesystem. This could be done by appropriate plugin.
Actually our current implementation of the engine allows us to add the filesystem functionality to the engine by plugins. But because we must be able to read simple files like config file which is loaded before all plugins, we must find the way how to do this. So using of the filesystem as plugin is not possible. But you are still able to add more supported file types (filesystems) through plugins after this system is running.
1.5.1