Это напоминает мне о файловой системе, с которой я загружал файлы уровня CD в удивительно короткое время (это улучшило время загрузки с 10 секунд до почти мгновенного), и это также работает на носителях не-CD. Он состоял из трех версий класса для переноса файловых функций ввода-вывода с одинаковым интерфейсом:
class IFile
{
public:
IFile (class FileSystem &owner);
virtual Seek (...);
virtual Read (...);
virtual GetFilePosition ();
};
и дополнительный класс:
class FileSystem
{
public:
BeginStreaming (filename);
EndStreaming ();
IFile *CreateFile ();
};
и вы напишите код загрузки как:
void LoadLevel (levelname)
{
FileSystem fs;
fs.BeginStreaming (levelname);
IFile *file = fs.CreateFile (level_map_name);
ReadLevelMap (fs, file);
delete file;
fs.EndStreaming ();
}
void ReadLevelMap (FileSystem &fs, IFile *file)
{
read some data from fs
get names of other files to load (like textures, object definitions, etc...)
for each texture file
{
IFile *texture_file = fs.CreateFile (some other file name)
CreateTexture (texture_file);
delete texture_file;
}
}
Тогда у вас будет три режима работы: режим отладки, режим построения потокового файла и режим выпуска.
В каждом режиме объект FileSystem будет создавать разные объекты IFile.
В режиме отладки объект IFile только что обернул стандартные функции ввода-вывода.
При построении потокового файла объект IFile также обернул стандартный IO, но имел дополнительные функции записи в потоковый файл (владелец FileSystem открыл потоковый файл) каждый прочитанный байт и записи возвращаемого значения любого файла. запросы позиции указателя (поэтому, если нужно знать размер файла, эта информация записывается в файл потока). Это могло бы объединить различные файлы в один большой файл, но только данные, которые были фактически прочитаны.
Режим выпуска создаст IFile, который не открывает файлы и не ищет их в файлах, он просто читает из потокового файла (как открыл объект FileSystem владельца).
Это означает, что в режиме выпуска все данные читаются в виде одной последовательной серии операций чтения (ОС неплохо буферизует их), а не в виде большого количества операций поиска и чтения. Это идеально подходит для компакт-дисков, где время поиска действительно медленное. Излишне говорить, что это было разработано для консольной системы на основе CD.
Побочным эффектом является то, что данные лишаются ненужных метаданных, которые обычно пропускаются.
У него есть недостатки - все данные для уровня находятся в одном файле. Они могут быть довольно большими, и данные не могут быть разделены между файлами, если у вас есть набор текстур, скажем, которые были общими для двух или более уровней, данные будут дублироваться в каждом файле потока. Кроме того, процесс загрузки должен быть одинаковым при каждой загрузке данных, вы не можете условно пропускать или добавлять элементы на уровень.