Revision cd53acda
Added by danij about 13 years ago
Files
- added
- modified
- copied
- renamed
- deleted
- doomsday
- build
- engine
- api
- portable
- include
- src
- abstractfile.c (diff)
- bitmapfont.c (diff)
- con_config.c (diff)
- dd_help.c (diff)
- dd_main.c (diff)
- def_read.c (diff)
- dfile.c (diff)
- filelist.c (diff)
- fs_main.c (diff)
- gl_pcx.c (diff)
- gl_png.c (diff)
- gl_texmanager.c (diff)
- gl_tga.c (diff)
- lumpfile.c (diff)
- m_misc.c (diff)
- r_model.c (diff)
- s_mus.c (diff)
- s_wav.c (diff)
- sys_filein.c
- wadfile.c (diff)
- zipfile.c (diff)
Completed filesystem refactorings to "remove" DFILE
All file objects in the vfs are now constructed from two core
components named AbstractFile and DFile. AbstractFile is base
class which represents any file openable by the engine. From
this base class we presently derive three specializations
named LumpFile, WadFile and ZipFile.
LumpFile is itself an abstract component which represents any
file loaded from within a container (i.e., either Zip or Wad).
WadFile represents a Wad and abstracts the mechanisms necessary
for manipulating such containers behind a common interface.
ZipFile represents a Zip, similarly to WadFile.
DFile is a file reference/handle. It acts as an interface to
an underlying AbstractFile based implementation. Any number of
DFile handles may be spawned to interact with a single
AbstractFile derived instance. DFile handles are visible via
the public API and may be freely duplicated by the vfs when
additional references to a file are needed.
Todo: All DFile instances should be tracked by the file system
so that we can ensure they are cleaned up if a plugin forgets
to destroy them when done.
Todo: Implement an AbstractFile reference counting mechanism
within DFile.