Changes between Version 1 and Version 2 of Virtual_File_System


Ignore:
Timestamp:
Jan 13, 2016, 9:14:21 PM (8 years ago)
Author:
leper
Comment:

14102Update VFS documentation. The header file this was meant to be kept in sync with was replaced by another one years ago. Add some information about .DELETED files, clarify archive builder parts (see r14102), add file replacement part. (Maybe the file replacement/removal parts should be moved to the mount details section.)

Legend:

Unmodified
Added
Removed
Modified
  • Virtual_File_System

    v1 v2  
    1 [KEEP IN SYNC WITH VFS.H!]
     1[[TOC]]
    22
    33== Introduction ==
    44
    5 The VFS (Virtual File System) is a layer between the application and file.cpp's API. Its main purpose is to decrease the cost of file access; also provided for are "hotloading" and "modding" via overriding files
    6 (explained below).
    7 The interface is almost identical to that of file.cpp, except that it works with Handles for safety (see [wiki:handle_manager h_mgr.h]).
     5The VFS (Virtual File System) is an abstraction layer that simplifies file access for game data.
     6Its main purpose is to have platform independent file access methods, decrease the cost of file access, and modding support.
     7It also provides hotloading support to allow fast iteration of files during development.
    88
    99
     
    1414 * lengthy file open times. Permissions checks and overhead added by antivirus scanners combine to make these slow. Additionally, files are typically not arranged in order of access, which induces costly disk seeks.
    1515
    16 The solution is to put all files in archives: internal fragmentation is eliminated since they are packed end-to-end; open is much faster; seeks are avoided by arranging in order of access. For more information, see 'Archive Details' below.
     16The solution is to put all files in archives: internal fragmentation is eliminated since they are packed end-to-end; open is much faster; seeks can be avoided by arranging in order of access. For more information, see 'Archive Details' below.
    1717
    18 Note that a good file system (Reiser3 comes close) could also deliver the above. However, this code is available now on all platforms; there is no disadvantage to using it and the other features remain.
     18Note that a good file system could also provide the above.
     19However this depends on machine specific settings, while our used approach has no such disadvantage.
    1920
    2021
    2122== Hotloading ==
    2223
    23 During development, artists and programmers typically follow a edit/see how it looks in-game/repeat methodology. Unfortunately, changes to a file are not immediately noticed by the game; the usual workaround is to
    24 restart the map (or worse, entire game) to make sure they are reloaded. Since decreases in edit cycle time improve productivity, we want changes to files to be picked up immediately. To that end, we support hotloading -
    25 as soon as the OS reports changes, all Handle objects that ensued from that file are reloaded.
     24During development, artists and programmers typically follow a edit/see how it looks in-game/repeat methodology.
     25Unfortunately, changes to a file are not immediately noticed by the game.
     26The usual workaround is to restart the map (or worse, entire game) to make sure they are reloaded.
     27Since decreases in edit cycle time improve productivity, we want changes to files to be picked up immediately.
     28To that end, we support hotloading - as soon as the OS reports changes, all Handle objects that ensued from that file are reloaded.
    2629
    27 The VFS's part in this is registering "watches" that report changes to any mounted real directory. Since the file notification backend (currently SGI FAM and a Win32 port) cannot watch an entire directory tree,
    28 we need to do so for every single directory. The VFS traverses and stores data for them anyway, we do so here.
     30The VFS's part in this is registering "watches" that report changes to any mounted real directory.
     31Since the file notification backend (or some OS specific APIs) cannot watch an entire directory tree, we need to do so for every single directory.
     32The VFS traverses and stores data for them anyway, we do so here.
    2933
    3034
     
    3337=== Motivation ===
    3438
    35 When users tweak game parameters or even create an entirely new game principle with the same underlying engine, it is called modding. As evidenced by the Counterstrike mod for Half-Life, this can greatly prolong the life of a game. Additionally, since we started out as a mod group, great value is placed on giving users all the tools to make modding easy.
     39When users tweak game parameters or even create an entirely new game principle with the same underlying engine, it is called modding.
     40As evidenced by the Counterstrike mod for Half-Life, this can greatly prolong the life of a game.
     41Additionally, since we started out as a mod group, great value is placed on giving users all the tools to make modding easy.
    3642
    3743=== Means ===
    3844
    39 The actual method of overriding game data is quite simple: a mod directory is mounted into the file system with a higher priority than original data. These files therefore temporarily (as long as the mod is active) replace the
    40 originals. This allows multiple (non-overlapping!) mods to be active at the same time and also makes switching between them easy. The same mechanism is also used for patches to game data.
     45The actual method of overriding game data is quite simple: a mod directory is mounted into the file system with a higher priority than original data.
     46These files therefore temporarily (as long as the mod is active) replace the originals.
     47This allows multiple mods to be active at the same time and also makes switching between them easy.
     48The same mechanism could also be used for patches to game data.
     49
     50==== File Replacement ====
     51
     52A newly mounted mod has its files added to the VFS if the files have a higher priority, or they have the same priority but a newer timestamp (e.g. update packs, development), or the used file loader (archives are preferred over loose files) is more efficient.
     53
     54==== File Removal ====
     55
     56Mods can remove files from lower priority mods.
     57To remove file `a` the mod has to provide a file named `a.DELETED` (contents do not matter, file should probably be empty to save space).
     58Removing directories follows a similar approach where a directory `b` in a lower priority mod is removed if a file named `b.DELETED` is in the mod. (Not yet included; see #2641)
     59All files with a lower priority than the `.DELETED` file in this directory (and all subdirectories) are then removed, and empty subdirectories are also removed.
     60Note that the directory cannot be removed unconditionally since it might contain higher priority (or same priority) files which should be kept.
    4161
    4262=== Rationale ===
    4363
    44 Older games did not provide any support for modding other than directly editing game data. Obviously this is risky and insufficient. Requiring mods to provide a entire new copy of all game logic/scripts would obviate support from the file system, but is too much work for the modder (since all files would first have to be copied somewhere). Allowing overriding individual files is much safer (since game data is never touched) and easier (more fine-grained control for modders).
     64Older games did not provide any support for modding other than directly editing game data.
     65Obviously this is risky and insufficient.
     66Requiring mods to provide a entire new copy of all game logic/scripts would obviate support from the file system, but is too much work for the modder (since all files would first have to be copied somewhere).
     67Allowing overriding individual files is much safer (since game data is never touched) and easier (more fine-grained control for modders).
    4568
    46 Alternatives to the patch archive approach would be to completely replace the game data archive (infeasible due to size) or apply a binary patch (complicated and brittle WRT versioning). We are therefore happy to use the already existing mod mechanism.
     69Alternatives to the patch archive approach would be to completely replace the game data archive (infeasible due to size) or apply a binary patch (complicated and brittle WRT versioning).
     70We are therefore happy to use the already existing mod mechanism.
    4771
    48 Note however that multiple patches do impact performance (despite constant-time VFS path -> file location lookup) simply due to locality; files are no longer arranged in order of access. Fortunately there is an easy way to avoid this: simply run the archive builder script; all patched files will be merged into the archive.
     72Note however that multiple patches do impact performance (despite constant-time VFS path -> file location lookup) simply due to locality; files are no longer arranged in order of access.
     73Fortunately there is an easy way to avoid this: simply run the archive builder script; all patched files will be merged into the archive.
    4974
    5075
     
    5479== Mount Details ==
    5580
    56 "Mounting" is understood to mean populating a given VFS directory (the "mount point") with the contents of e.g. a real directory or archive (the "mounted object" - for a list of supported types, see enum !MountType).
     81"Mounting" is understood to mean populating a given VFS directory (the "mount point") with the contents of e.g. a real directory or archive (the "mounted object").
     82It is important to note that the VFS is a full-fledged tree storing information about each file, e.g. its last-modified time or actual location.
     83The advantage is that file open time does not increase with the number of mounts, which is important because multiple patches and mods may be active.
     84This is in contrast to e.g. PhysicsFS, which just maintains a list of mountings and scans it when opening each file.
    5785
    58 It is important to note that the VFS is a full-fledged tree storing information about each file, e.g. its last-modified time or actual location. The advantage is that file open time does not increase with the number of
    59 mounts, which is important because multiple patches and mods may be active. This is in contrast to e.g. PhysicsFS, which just maintains a list of mountings and scans it when opening each file.
    60 
    61 Each file object in the VFS tree stores its current location; there is no way to access files of the same name but lower priority residing in other mounted objects. For this reason, the entire VFS must be rebuilt (i.e. repopulating all mount points) when a mounting is removed. Fortunately this is rare and does not happen in-game; we optimize for the common case.
     86Each file object in the VFS tree stores its current location; there is no way to access files of the same name but lower priority residing in other mounted objects.
     87For this reason, the entire VFS must be rebuilt (i.e. repopulating all mount points) when a mounting is removed.
     88Fortunately this is rare and does not happen in-game (apart from the mod selector), so we optimize for the common case.
    6289
    6390
     
    6996 * interoperability: anyone can view or add files without the need for special tools, which is important for modding.
    7097 * less work: freely available decompression code (ZLib) eases implementation. Disadvantages are efficiency (only adequate; an in-house format would offer more potential for optimization) and lacking protection of data files.
    71 Interoperability is a double-edged sword, since anyone can change critical files or use game assets. However, obfuscating archive contents doesn't solve anything, because the application needs to access them and a cracker
    72 need only reverse-engineer that. Regardless, the application can call its archives e.g. ".pk3" (as does Quake III) for minimal protection.
     98Interoperability is a double-edged sword, since anyone can change critical files or use game assets.
     99However, obfuscating archive contents doesn't solve anything, because the application needs to access them and a cracker need only reverse-engineer that.
     100Regardless, the application can call its archives e.g. ".pk3" (as does Quake III) for minimal protection.
    73101
    74102=== Archive Builder ===
    75103
    76 Arranging archive contents in order of access was mentioned above. To that end, the VFS can log all file open calls into a text file (one per line). This is then processed by an archive builder script, which needs to
    77 collect all files by VFS lookup rules, then add them to the archive in the order specified in that file (all remaining files that weren't triggered in the logging test run should be added thereafter).
     104The game supports building archives via the `-archivebuild` command line parameters.
     105This adds all files in the specified mod (and their cached variants) to a `.zip` archive.
     106Optionally the archive can be compressed thereby slightly improving file access times (less data to read, decompression overhead is not an issue since it is done in parallel with IOs).
    78107
    79 Note that the script need only be a simple frontend for e.g. infozip, and that a plain user-created archive will work as well (advantage of using Zip); this is just an optimization.
     108=== Access Order Arrangement ===
    80109
    81 === Misc. Notes ===
     110To speed up access times the archived files could be sorted in access order, but this optimization is currently not needed (and it would only work well for some (relatively) common cases).
     111However, the VFS can log all file open calls into a text file (one per line).
     112This could then be processed by an archive builder script, which needs to collect all files by VFS lookup rules, then add them to the archive in the order specified in that file (all remaining files that weren't triggered in the logging test run should be added thereafter).
    82113
    83 To ease development, files may additionally be stored in normal directories. The VFS transparently provides access to the correct (newest) version.
    84 
    85 One additional advantage of archives over loose files is that I/O throughput is increased - since files are compressed, there is less to read from disk. Decompression is free because it is done in parallel with IOs.
     114Note that the script need only be a simple frontend for e.g. infozip, and that a plain user-created archive will work as well (advantage of using Zip); this is just a possible optimization.