Объединение ресурсов в один двоичный файл

Короткий ответ: да.

В Mac OS 6,7,8 был значительный API, посвященный именно этой задаче. Поищите в «Диспетчере ресурсов», если вам интересно. Обновлено: То же самое и с пакетом анализа физики КОРЕНЬ.

Не то чтобы я сейчас знаю хороший инструмент. На какой платформе (-ах) вы хотите, чтобы он работал?

Отредактировано для добавления: все два-три инструмента такого рода, которых я не использую, имеют схожую структуру:

• Файл начинается с заголовка и индекса
• Есть серия блоков, некоторые из которых могут иметь собственные заголовки и индикаторы, некоторые из которых являются листьями.
• Каждый лист представляет собой простую сериализацию сохраняемых данных.
• Может быть сжат весь файл (а иногда и отдельные блоки).

Не так уж и сложно реализовать свой собственный, но я бы сначала поискал хороший существующий, который отвечает вашим потребностям.

делать как Java: упаковать все это в zip-архив и использовать API, похожий на файловую систему, для чтения прямо оттуда.

Лично я никогда не использовал для этого уже доступные инструменты. Если вы хотите, чтобы ваша игра не была легко взломана, вам нужно разработать собственный механизм управления ресурсами.

1. Прежде всего прочтите о сериализация объектов. Когда вы загружаете ресурс из файла (графику, звук или что-то еще), он сохраняется в некотором экземпляре объекта в памяти. В игре обычно используются десятки графических и звуковых объектов. Вам нужно создать инструмент, который загружает их все и хранит в коллекциях в памяти. Затем сериализуйте эти коллекции в двоичный файл, и у вас будут все ресурсы.

2. Затем вы можете использовать, например, MD5 или любой другой алгоритм шифрования, чтобы зашифровать этот файл.

3. Кроме того, вы можете использовать zlib или другую библиотеку сжатия, чтобы уменьшить этот большой двоичный файл.

4. В игре вам необходимо загрузить зашифрованный двоичный файл и распаковать его. Затем расшифруйте его. Затем десериализуйте коллекции объектов, и все ресурсы вернутся в память.

Конечно, вы можете сделать это более комплексным, сохранив в разных двоичных файлах ресурсы для разных уровней и так далее - есть множество вариантов, в зависимости от того, что вы хотите. Также вы можете сначала заархивировать, а затем зашифровать или выполнить другие комбинации шагов.

Есть много способов сделать это. У m_pGladiator есть несколько хороших идей, особенно в отношении серализации. Я хотел бы сделать еще несколько комментариев.

Во-первых, если вы собираетесь упаковать кучу ресурсов в один файл (я называю эти файлы пакетами), то я думаю, вам следует работать, чтобы избежать загрузки всего файла и последующей десерализации из этого файла в память. Простая причина в том, что это больше памяти. Думаю, это действительно не проблема для ПК, но это хорошая практика, и она необходима при работе на консоли. Хотя мы (в настоящее время) не сериализуем объекты, как предлагает m_pGladiator, мы движемся к этому.

У вас могут быть два типа файлов пакетов. Один из них - это файл, в котором вам нужен произвольный доступ к содержимому файлов. Второй тип может быть набором файлов, где вам понадобится все этих файлов при загрузке уровня. Базовым примером может быть:

1. Файл пакета аудио может содержать все аудио для вашей игры. Возможно, вам потребуется загрузить только определенные виды звука для экранов меню или интерфейса и различные наборы звука для уровней. Это может попасть в первую категорию выше.
2. Типом, который попадает во вторую категорию, могут быть все модели / текстуры / и т. д. Для уровня. По сути, вы хотите загрузить все содержимое этого файла в игру во время загрузки, потому что вам (вероятно) понадобится все его содержимое, пока игрок играет на этом уровне или в этом разделе.

многие из создаваемых нами пакетов попадают во вторую категорию. Мы в основном упаковываем содержимое уровня, а затем сжимаем его чем-то вроде zlib. Когда мы загружаем один из них во время игры, мы читаем небольшой объем файла, распаковываем то, что мы прочитали, в буфер памяти, а затем повторяем, пока весь файл не будет считан в память. Буфер, в который мы читаем, относительно мал, в то время как буфер конечного назначения достаточно велик, чтобы вместить самый большой набор несжатых данных, который нам нужен. Этот метод сложен, но, опять же, он экономит оперативную память, это интересное упражнение для начала работы, и вы чувствуете себя хорошо и тепло внутри, потому что вы хорошо распоряжаетесь системными ресурсами. как только пакетный файл был полностью распакован в буфер destinatino, мы запускаем последний проход в буфере, чтобы исправить положение указателей и т. д. Этот метод работает только тогда, когда вы записываете свой пакетный файл в виде структур, известных игре. Другими словами, наши инструменты для написания файлов пакетов разделяют структуру (или классы) с кодом игры. Мы в основном записываем и сжимаем точные представления структур данных.

Если вы просто хотите сократить количество файлов, которые вы отправляете и устанавливаете на пользовательский компьютер, вы можете использовать что-то вроде первого типа packfile, который я описываю. Может быть, у вас есть тысячи текстур, и вы просто хотите сократить огромное количество файлов, которые вам нужно заархивировать и упаковать. Вы можете написать небольшую утилиту, которая будет в основном читать файлы, которые вы хотите упаковать вместе, а затем записывать заголовок, содержащий файлы и их смещения в файл пакета, а затем вы можете записывать содержимое файла, по одному, по одному за другим в вашем большом двоичном файле. Во время игры вы можете просто загрузить заголовок этого файла пакета и сохранить имена файлов и смещения в хэше. Когда вам нужно прочитать файл, вы можете хэшировать имя файла и посмотреть, существует ли оно в вашем пак-файле, и если да, вы можете прочитать содержимое непосредственно из упаковочного файла, перейдя к смещению, а затем прочитав из этого места в пак-файле. Опять же, этот метод, по сути, представляет собой способ упаковки данных вместе без учета шифрования и т. д. Это просто организационный метод.

Но опять же, я хочу подчеркнуть, что если вы идете по пути, который предлагает я или m_pGladiator, я бы очень постарался, чтобы не загружать весь файл в ОЗУ, а затем десериализовать его в другое место в ОЗУ. Это пустая трата ресурсов (которых, возможно, у вас много). Я бы сказал, что вы можете сделать это, чтобы он заработал, а затем, когда он заработает, вы можете работать с методом, который читает только часть файла за раз, а затем распаковывает его в целевой буфер. Однако вы должны использовать схему сжатия, которая будет работать именно так. zlib и lzw оба делают (я считаю). Я не уверен насчет алгоритма MD5.

Надеюсь, это поможет.

Для будущих людей, таких как я, интересующихся этой же темой, просмотрите две следующие ссылки:

http://www.sfml-dev.org/wiki/en/tutorials/formatdat

http://archive.gamedev.net/reference/programming/features/pak/