genesis-3d_engine/Engine/foundation/io/zipfs/zipfilesystem.h

85 lines
3.4 KiB
C
Raw Permalink Normal View History

/****************************************************************************
Copyright (c) 2006, Radon Labs GmbH
Copyright (c) 2011-2013,WebJet Business Division,CYOU
http://www.genesis-3d.com.cn
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.
****************************************************************************/
#pragma once
//------------------------------------------------------------------------------
/**
@class IO::ZipFileSystem
An archive filesystem wrapper for ZIP files.
Uses the zlib and the minizip package under the hood.
Limitations:
* No write access.
* No seek on compressed data, the ZipFileSystem will generally decompress
an entire file into memory at once, so that the ZipStreamClass can
provide random access on the decompressed data. Thus the typical
"audio streaming scenario" is not possible from zip files (that's
what XACT's sound banks is there for anyway ;)
How to fix the no-seek problem:
* zlib processes datas in chunks, and cannot seek randomly within
a chunk, and the chunk size is dependent on the compress application
being used to create the zip file(?), if those internals are known,
it would be possible to write a chunked filesystem which keeps
buffered chunks around for each client, probably not worth the effort.
* Another appoach would be to split stream-files into "chunk-files"
before compressing, and to read the next complete chunk files
when new data is needed. This approach doesn't require changes to
the strip filesystem.
*/
#include "io/archfs/archivefilesystembase.h"
//------------------------------------------------------------------------------
namespace IO
{
class ZipArchive;
class ZipFileSystem : public ArchiveFileSystemBase
{
__DeclareClass(ZipFileSystem);
__DeclareImageSingleton(ZipFileSystem);
public:
/// constructor
ZipFileSystem();
/// destructor
virtual ~ZipFileSystem();
/// setup the archive file system
void Setup();
/// discard the archive file system
void Discard();
/// find first archive which contains the file path
GPtr<Archive> FindArchiveWithFile(const URI& fileUri) const;
/// find first archive which contains the directory path
GPtr<Archive> FindArchiveWithDir(const URI& dirUri) const;
};
} // namespace IO
//------------------------------------------------------------------------------