User Tools

Site Tools


gamedev:vfs

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
gamedev:vfs [2011/07/22 23:37] – [How it all works] dragonlordgamedev:vfs [2019/05/24 23:43] (current) – ↷ Links adapted because of a move operation dragonlord
Line 1: Line 1:
-====== Virtual File System ======+{{tag>vfs filesystem file}} 
 +<WRAP youarehere> 
 +[[:start|Start Page]] >> [[:gamedev|Game Development with the Drag[en]gine]] >> **Virtual File System** 
 +</WRAP> 
 The Drag[en]gine provides a sophisticated Virtual File System to manage resources easy across a variety of platforms and helps a lot in patching as well as allowing customers to adjust the file system structure to their needs without huge configuration works required. The various users of the Drag[en]gine ( developers, game designers and players ) see only the virtual file system provided by the game engine and work with it like with their real disk file system just with a few differencies. The Drag[en]gine provides a sophisticated Virtual File System to manage resources easy across a variety of platforms and helps a lot in patching as well as allowing customers to adjust the file system structure to their needs without huge configuration works required. The various users of the Drag[en]gine ( developers, game designers and players ) see only the virtual file system provided by the game engine and work with it like with their real disk file system just with a few differencies.
  
Line 14: Line 18:
 Archives are often used to group many files into a continuous file on disk. This can be required for various reasons ranging from restrictions on the hosting platform to distribution considerations. The Archive Container takes a file path ( in the form of the native operating system ) and injects the content of the archive into the Virtual File System. And Archive Module is used to access the content of the file which allows to use any kind of archive format with this Container without having to subclass it. By default Archive Containers are read-only. If the Archive Module supports writing to an archive it is possible to set this Container to writable. Most of the time though this is not very optimal and should not be done. Better save files into a disk directory and archive them together once upon time. This Container is not implemented yet but in design phase. Archives are often used to group many files into a continuous file on disk. This can be required for various reasons ranging from restrictions on the hosting platform to distribution considerations. The Archive Container takes a file path ( in the form of the native operating system ) and injects the content of the archive into the Virtual File System. And Archive Module is used to access the content of the file which allows to use any kind of archive format with this Container without having to subclass it. By default Archive Containers are read-only. If the Archive Module supports writing to an archive it is possible to set this Container to writable. Most of the time though this is not very optimal and should not be done. Better save files into a disk directory and archive them together once upon time. This Container is not implemented yet but in design phase.
  
-===== URL/FTP Container ===== +===== Remote Directory Container ===== 
-URL/FTP Containers are something particular. They allow to inject the content of a remote directory given by an URL into the Virtual File System. Files are only downloaded and uploaded if required. This can be used to accomplish various tasks like fetching updates or writing stats to a remote server. The good thing here is that you do this by simply writing to a file in the Virtual File System not caring at all where this file is stored. The Container takes care of the naughty networking for you. This Container is not implemented yet but in design phase.+The Remote Directory Containers (URL/FTPare something particular. They allow to inject the content of a remote directory given by an URL into the Virtual File System. Files are only downloaded and uploaded if required. This can be used to accomplish various tasks like fetching updates or writing stats to a remote server. The good thing here is that you do this by simply writing to a file in the Virtual File System not caring at all where this file is stored. The Container takes care of the naughty networking for you. This Container is not implemented yet but in design phase.
  
 ====== How it all works ====== ====== How it all works ======
Line 22: Line 26:
 Getting the hang on the Virtual File System can be hard at the beginning. In contrary to mounting the injecting of files is a bit a different concept although used by other games like Quake with their pak files. If a user requests to read a file with a given path from the Virtual File System a query is conducted against the Containers. Each Container is asked in the counter order they have been added ( with the last Container added being the first one to be asked followed by second last Container and so forth ) if they can deliver the requested file. If so the query stops and the file is returned to the requesting user to be read from. For writing things work similar. The Containers are queried again but this time they are first checked if they can write the given file. The first Container claiming to be able to do so wins and the query ends. The returned file can be written by the user. Imagine the Containers as metal slabs with holes. You poke with a needle through until you hit a slab blocking your needle. This one wins and delivers you the file you are looking for. For the user this is nothing else than asking to read for example "/mygame/models/player.model" but the actual file can be delivered by the Disk Container sitting on your Game-CD or on your disk installation or even from an Archive Container containing updated files. The possibilities are endless. Getting the hang on the Virtual File System can be hard at the beginning. In contrary to mounting the injecting of files is a bit a different concept although used by other games like Quake with their pak files. If a user requests to read a file with a given path from the Virtual File System a query is conducted against the Containers. Each Container is asked in the counter order they have been added ( with the last Container added being the first one to be asked followed by second last Container and so forth ) if they can deliver the requested file. If so the query stops and the file is returned to the requesting user to be read from. For writing things work similar. The Containers are queried again but this time they are first checked if they can write the given file. The first Container claiming to be able to do so wins and the query ends. The returned file can be written by the user. Imagine the Containers as metal slabs with holes. You poke with a needle through until you hit a slab blocking your needle. This one wins and delivers you the file you are looking for. For the user this is nothing else than asking to read for example "/mygame/models/player.model" but the actual file can be delivered by the Disk Container sitting on your Game-CD or on your disk installation or even from an Archive Container containing updated files. The possibilities are endless.
 <WRAP clear></WRAP> <WRAP clear></WRAP>
- 
- 
-====== Links ====== 
-  * [[gamedev:main|Game Development Informations]] 
-  * [[:start|Main page]] 
gamedev/vfs.1311377860.txt.gz · Last modified: 2011/07/22 23:37 by dragonlord