Причина монолитных файлов данных
Прежде всего, это, кажется, техника, используемая играми, где у них есть все звуки в одном файле, структуры в другом и т.д. С этими файлами, обычно достигающими размера ГБ.
Какова причина позади выполнения этого по поддержанию всего этого в подкаталогах как маленькие файлы - один на структуру, которая много маленьких игр используют это, при этом монолитная система одобрена более крупными компаниями?
Есть ли некоторая файловая система наверху с большим количеством маленьких файлов? Они пытаются защитить свое свойство - хотя самый справедливый, кажется, сжатый файл с новым расширением?
5 ответов
Причины, по которым мы используем подобную «архивную» систему там, где я работаю (компания по разработке игр):
- скорость поиска : нам редко нужно перебирать файлы в каталоге ; мы гораздо чаще ищем их напрямую по имени.Используя настраиваемую «таблицу размещения файлов», которая по сути представляет собой просто последовательность
хэша (normalized_filename) -> [смещение, размер], мы можем очень быстро искать файлы . Мы также можем хранить этот индекс в ОЗУ, потенциально чередовать его с другими индексными таблицами и т. Д. - (Когда нам действительно нужно выполнить итерацию, мы можем легко выполнить итерацию по всем файлам в
.arc, либо мы можем где-то хранить список имен файлов, список хеш-значений имен файлов или просто список пар [смещение, размер] - возможно, даже в виде файла в архиве. Обычно это быстрее, чем обход каталога в FS.) - метаданные : Нам легко добавить любые метаданные файла, которые нам нужны. Например, единственный бит в поле «размер» указывает, сжат файл или нет (если да, то у него есть заголовок с более подробной информацией о том, как его распаковать). Мы даже можем варьировать сжатие для частей файла, если заранее знаем достаточно о структуре файла (мы делаем это для архивов спрайтов).
- size : одно из используемых нами устройств имеет требование «размер файла должен быть кратен X», где X велик по сравнению с некоторыми из наших файлов. Например, некоторые из наших скриптов lua при компиляции занимают всего несколько сотен байт; дополнительные накладные расходы на файл .luc быстро накапливаются.
- выравнивание : с другой стороны, иногда мы хотим тратить пространство впустую. Чтобы воспользоваться преимуществами более быстрой потоковой передачи (например, фонового DMA) из файловой системы, некоторые из наших файлов действительно хотят подчиняться определенным требованиям к выравниванию / размеру.Мы можем позаботиться об этом прямо в инструменте, и выравнивание / размер, для которого мы снимаем, не обязательно должны совпадать с лежащей в основе FS, что позволяет нам тратить пространство только там, где оно нам нужно.
Но это мирские причины. Еще интереснее:
Каждый .arc регистрируется в списке и пытается открыть файл, который знает, что нужно искать в дугах. Сначала мы ищем архивы, уже находящиеся в ОЗУ, затем архивы на устройстве FS, а затем на самом устройстве. Это дает нам массу гибкости:
- динамические дополнения к файловой системе : в любое время мы можем передать новый файл или архив в потоковую передачу на рассматриваемую машину (по сети и т.п.) и сделать так, чтобы он отображался как часть «логической» файловой системы; это замечательно, когда фактическая FS находится в ПЗУ или на компакт-диске, и позволяет нам выполнять итерацию намного быстрее, чем мы могли бы в противном случае.
- (Система Doom
.wadявляется своего рода примером вышеупомянутого, что позволяет разработчикам модификаций более легко переопределять ресурсы и скрипты, встроенные в игру.) - возможность отсутствия базовых файловых систем : Можно использовать
bin2objдля встраивания всей дуги непосредственно в исполняемый файл (.rodata) во время компоновки, после чего вам даже не нужно смотреть на устройство FS - мы делаем это для некоторых небольших демонстрационных сборок и тому подобного. Таким же образом мы можем отправлять уровни по сети или по сохраненной игре-сникернету.=) - организация и загрузка / выгрузка : поскольку мы можем загружать, выгружать и переопределять виртуальные «части» нашей файловой системы в любое время, мы можем проделать некоторые трюки с производительностью с очень большим количеством файлов в FS. маленький в любой момент времени. Мы можем дополнительно указать, что весь архив будет загружен в память, индексную таблицу и данные; наш код загрузки файла достаточно умен, чтобы знать, что если файл уже находится в памяти, ему не нужно ничего делать для его чтения, кроме как перемещать указатель.Часть кода более высокого уровня может фактически обнаружить, что файл находится в оперативной памяти, и просто запросить указатель, вероятно, уже выглядит как структура.
- Переносимость : нам нужно только выяснить, как получить несколько файлов на каждом новом устройстве, которое мы используем, и тогда остальная часть кода FS более или менее останется прежней. =) Время от времени мы немного меняем выход инструмента (для выравнивания), но большая часть обработки остается прежней.
- дедупликация : с более умными архивами, такими как наши архивы спрайтов, мы можем (и делаем) дедупликацию данных. Если пятый кадр анимации «прыжка» и третий кадр «удара» совпадают, мы можем разделить файл и сохранить только одну копию этого кадра. Мы можем сделать то же самое для целых файлов.
Недавно мы перенесли компьютерную игру на систему с гораздо более медленным доступом к FS. Мы не меняли формат данных, и оказалось, что итерация через каталог на необработанном устройстве FS для загрузки сотни небольших файлов XML абсолютно убивала время загрузки. Мы использовали решение: взять каждый каталог, превратить его в отдельный subdir.arc и вставить его в главный game.arc сжатый. Когда был нужен каталог (было вызвано что-то вроде opendir), мы распаковали весь subdir.arc в ОЗУ, добавили его в файловую систему, а затем очень быстро перебрали его.
Именно способность собрать что-то подобное за несколько часов и облегчить перенос между системами делает подобные вещи стоящими.
В системах Apple наиболее распространенным способом является использование, как вы предлагаете, каталогов. Они называются Bundles и представлены в Finder как один файл, но если вы исследуете их больше, на самом деле это каталоги. Это упрощает написание кода и экономию памяти при загрузке отдельных элементов из этого пакета. :-) Кроме того, это упрощает создание инкрементных резервных копий гигантских баз данных, так как, например, ваша база данных iPhoto - это просто пакет, поэтому вы просто создаете резервные копии измененных и новых файлов
Однако я считаю, что в Windows это сделать намного сложнее , он будет выглядеть как каталог «несмотря ни на что» (я уверен, что умные люди нашли решение, которое заставит Explorer видеть определенные каталоги как единый файл, но это встречается нечасто).
С точки зрения разработчика игр, вы имеете дело не с такими маленькими файлами, которые вас очень беспокоят, поэтому я сомневаюсь в предложении @doublep, поскольку оно создает такие хлопоты, но это значительно упрощает работу с одним файлом, если пользователи должны куда-то скопировать всю игру, тогда легко проверить, является ли весь набор правильным.
И, конечно, труднее читать людям, которые не должны иметь к этому доступ. Но его также труднее модифицировать, а значит, труднее исправлять и труднее писать расширения. Тот, кто много использует расширения, предпочитает структуру каталогов: The Sims.
Если бы я был разработчиком игр, мне бы хотелось использовать отдельные файлы. С другой стороны, я бы использовал пакеты, как писал бы для Mac; -)
Ура
Ник
Как вы знаете, игры, особенно в крупных компаниях, стараются выжать из них максимальную производительность. Один из способов состоит в том, чтобы поместить все данные в один большой файл и просто DMA его в память (подумайте об этом как о memcpy от CD в RAM). Поскольку все файлы находятся в одном большом, поисков на диск не будет, и вы можете быстро загрузить большое количество файлов (что может вызвать большое количество поисков) из-за техники.
Я могу придумать несколько причин.
Как предполагается, файлы занимают на диске больше места, чем им требуется. Таким образом, архив экономит место. Файлы размером 10 КБ (любого размера) должны сэкономить 20 МБ при упаковке в архив. Сейчас не очень много места, но все же.
Другая причина, о которой я могу думать, - это фрагментация диска. Я подозреваю, что сильно фрагментированный диск будет хуже работать при доступе к тысячам отдельных файлов на фрагментированном пространстве. Но я не эксперт в этой области, поэтому был бы признателен, если бы кто-нибудь более опытный подтвердил это.
Наконец, я думаю, это тоже может иметь какое-то отношение к ограничению доступа к отдельным файлам игры. Вы можете выставить кучу скриптов Lua, возиться с ними и что-нибудь сломать. Или вы можете выставить финальный фильм / звук / текст / все, что угодно, и испортиться, получив к нему доступ. Я делаю это и сам: я шифрую изображения с помощью многопроходного ключа XOR, упаковываю текстовые файлы и переменные конфигурации в монолитный файл (заархивированный для дополнительной безопасности) и оставляю для свободного доступа только музыку. Таким образом, секреты игры еще ненадолго останутся нераскрытыми :).
Или может быть другая причина, о которой я никогда не думал: D.
У файловых систем есть накладные расходы. Обычно файл занимает место на диске с округлением до некоторой степени 2 (например, до 4 КБ), поэтому много маленьких файлов будут занимать место впустую. Некоторые современные файловые системы пытаются уменьшить это, но AFAIK это пока не распространено. Кроме того, файловые системы часто работают довольно медленно при доступе к нескольким файлам. Например, копирование одного файла размером 400 МБ обычно значительно быстрее, чем 4000 файлов размером 100 КБ.
Файловые системы очень удобны, когда вам приходится изменять файлы, поскольку они справляются с изменением размеров файлов гораздо лучше, чем любое простое домашнее решение. Однако это, конечно, не относится к постоянным игровым данным.