Ресурсные файлы что это

Большинству создателей игр рано или поздно хочется упаковать сотни (а порой и тысячи) файлов, используемых игрой, в один (или несколько) компактных ресурсных файлов.

Если вдруг вы об этом не задумывались, то вот ссылка на тему.

Я сам занимаюсь этой темой уже достаточно давно и есть кое-какие наработки, но на данном этапе хочется расширить свой кругозор и узнать мнения других разработчиков. Интересуют такие вопросы:

1) Какое решение вы используете в своем проекте: самописное, zlib, что-либо иное?
2) Почему вы выбрали именно это решение?
3) Что вам нравится в вашем решении? Что не нравится, но лень переделывать? Чего вам не хватает, но опять таки лень дописывать?

Заранее благодарен за ответы.

Я вот прочитал «ссылку на тему» и хочу прокомментировать выпады автора на счет Valve.
Во первых, совершенно очевидно, что автор никогда в жизни не держал в руках коробку с лицензионной игрой от Valve и тем более никогда такую игру не устанавливал. Потому как лицензионная игра состоит не из 40000 тысяч файлов, а из нескольких огромных архивов *.gcf, объединяемых движком в виртуальную файловую систему. Но даже не это главное. Суть же в том, что даже пиратская версия, собранная из тех-же *.gcf, только распакованных (и файлов там действительно дофига) по скорости загрузки уровня ничем не уступает лицензионной версии, а может даже загружается быстрее. Так что профит от всей этой затеи разве что в простоте/скорости установки и, как видится мне, в оптимизации доступа к файлам в случае медленных носителей (т.е. например на приставках).

в приведенной статье не нашел примера с тестом производительности. кроме того что автор брызгает слюной и кричит что все вокруг идиоты ничего в его записях умного нету. в указанной статье наехал на VALVe, стоить перейти на следующую страницу ( снизу стрелка ) и тутже он обсерает Intel Nvidia Autodesk и другие крупные компании. Читать противно когда ничего не достигший человек обсерат успешные компании (как минимум это говорит о том, что сам он в жизни ничего не сделал нормального, а продуктами указанных компаний пользуется весь мир, их их имена знает каждый. ) жалко, что там нету комментариев к статьям, а тоб я пожелал автору захлебнуться в совем дерьме. (прошу прощения за столь резкие высказывания)

Kloun
> жалко, что там нету комментариев к статьям

> Звучит как оскорбление. Обычно такое отношение к boost’у характерно для
> приверженцев NIH.
Везде есть границы разумного. а он прямо бредит этим бустом.

dw3105
> Вот я и хочу грамотно поставить задачу, для начала
для начала тогда надо определиться «зачем». какие задачи\проблемы должна решать ВФС?

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

Kloun
> для начала тогда надо определиться «зачем». какие задачи\проблемы должна решать
> ВФС?
Любые (в пределах разумного) с которыми может столкнуться среднестатистический программист Петя, если пожелает хранить кучу файлов в одном ресурсном файле. При этом иметь максимально простой интерфейс и быть платформенно/языково-независимой.

BUzer
> А у нас из движка сейчас буст выпиливается нафиг, так как он сильно увеличивает
> время компиляции и размер бинарников.
. и заменяется на свои родные велосипеды?
> Знаю, автор тех статей порекомендовал-бы нам купить новые компы.
И был бы прав.

dw3105
> среднестатистический программист Петя
Он об паках вообще не должен знать, в принципе. Т.е. оптимизировать игру с точки зрения загрузки так или иначе будет не он.

dw3105
> Если вдруг вы об этом не задумывались, то вот ссылка на тему.
По поводу статьи. КГ/АМ, хотя в некоторых моментах автор все-же прав. Но его стиль изложения. Я б во-первых, никогда не взял бы на работу человека с таким стилем мыслей, а во-вторых, очень хотел-бы глянуть на список реальных продуктов, выпущенных с его участием. Что-то мне подсказывает, что список-то невелик.

Thryl
Спасибо большое за столь подробный ответ 🙂

Источник

Файлы ресурсов (C++)

Все управляемые ресурсы, которые нужно редактировать, должны быть связанными ресурсами. Редакторы ресурсов Visual Studio не поддерживают редактирование внедренных ресурсов.

Термин файл ресурсов может ссылаться на несколько типов файлов, например:

файл описания ресурсов программы (RC);

файл шаблона ресурсов (RCT);

Отдельный ресурс, существующий как отдельный файл. Этот тип включает точечный рисунок, значок или файл курсора, на который ссылается RC-файл.

Работать с вложенными и условно включенными файлами ресурсов.

Обновите существующие ресурсы или преобразуйте их в Visual C++.

Импортировать графические ресурсы в текущий файл ресурсов или экспортировать их из него.

Включать общие или доступные только для чтения идентификаторы (символы), которые нельзя изменить с помощью среды разработки.

Включите в исполняемый файл (.exe) ресурсы, которые не нуждаются в редактировании (или не должны быть изменены), например общие ресурсы между несколькими проектами.

Включать типы ресурсов, не поддерживаемые средой разработки.

Изменяемые ресурсы

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

при редактировании ресурсов среда Visual Studio работает с и влияет на следующие файлы:

Ресурсы манифеста

В проектах классических приложений C++ Ресурсы манифеста представляют собой XML-файлы, описывающие зависимости, используемые приложением. например, в Visual Studio файл манифеста, созданный мастером MFC, определяет версию Windows общих библиотек управления, которые приложение должно использовать:

Допускается иметь только один ресурс манифеста на каждый модуль.

чтобы просмотреть сведения о версии и типе, содержащиеся в ресурсе манифеста, откройте файл в средстве просмотра XML-файлов или Visual Studio текстовом редакторе. Если вы откроете ресурс манифеста из представления ресурсов, этот ресурс откроется в двоичном формате.

Открытие ресурса манифеста

откройте проект в Visual Studio и перейдите к обозреватель решений.

Чтобы открыть в другом редакторе, щелкните правой кнопкой мыши файл manifest и выберите команду Открыть с помощью. Укажите используемый редактор и нажмите кнопку Открыть.

Источник

Работа с файлами ресурсов

Этот раздел относится к классическим приложениям Windows, написанным на C++.

Ресурсы могут состоять из широкого диапазона элементов, например:

Вы можете добавить новые ресурсы в проект и изменить их с помощью соответствующего редактора ресурсов. Большинство мастеров Visual C++ автоматически создают RC-файл для проекта.

Редакторы ресурсов и представление ресурсов недоступны в выпусках Express.

Чтобы вручную добавить файлы ресурсов в управляемые проекты, см. раздел Создание файлов ресурсов для классических приложений. Эта статья содержит сведения о доступе к ресурсам, отображении статических ресурсов и назначении строк ресурсов свойствам.

в этом разделе

Файлы ресурсов
описание файлов ресурсов и их использования в Windows классических приложениях. Также содержит ссылки на статьи с описанием использования файлов ресурсов.

Идентификаторы ресурсов (символы)
В этой статье описываются символы и использование диалогового окна Символы ресурсов для управления символами в проекте.

Редакторы ресурсов
описание редакторов ресурсов, предоставляемых в Visual Studio, и типов ресурсов, которые можно изменить с помощью каждого редактора. Также содержит ссылки на подробные сведения об использовании каждого редактора.

Связанные разделы

C++ в Visual Studio
Ссылки на документацию по Visual C++.

Обращайтесь к нам
Ссылки на сведения об использовании документации, обращении в службу поддержки и использовании специальных возможностей.

Источник

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

Создание и локализация ресурсов

В нелокализованном приложении файлы ресурсов можно использовать как хранилище для данных приложения, особенно для строк, которые в противном случае было бы необходимо жестко задавать в нескольких местах в исходном коде. Чаще всего ресурсы создаются в виде текстовых (txt) или XML-файлов (.resx), а для их компиляции в двоичные RESOURCES-файлы используется Resgen.exe (генератор файлов ресурсов). Эти файлы можно затем встроить в исполняемый файл приложения с помощью компилятора языка. Дополнительные сведения о создании ресурсов см. в разделе Создание файлов ресурсов.

Вы также можете локализовать ресурсы приложения для конкретных языков и региональных параметров. Это позволяет создавать локализованные (переведенные) версии приложений. При разработке приложения, использующего локализованные ресурсы, необходимо назначить язык и региональные параметры, являющиеся нейтральными или резервными, языком и региональными параметрами, ресурсы которого используются в случае отсутствия подходящих ресурсов. Как правило, ресурсы нейтрального языка и региональных параметров хранятся в исполняемом файле приложения. Остальные ресурсы для отдельных языков и региональных параметров хранятся в автономных вспомогательных сборках. Дополнительные сведения см. в разделе Создание вспомогательных сборок.

Упаковка и развертывание ресурсов

Развертывание ресурсов локализованного приложения выполняется во вспомогательных сборках. Вспомогательная сборка содержит ресурсы для одного языка и региональных параметров; в ней нет никакого кода приложения. В модели развертывания вспомогательной сборки вы создаете приложение с одной сборкой по умолчанию (которая обычно является главной сборкой) и одной вспомогательной сборкой для каждого языка и региональных параметров, поддерживаемых приложением. Поскольку вспомогательные сборки не являются частью главной сборки, ресурсы, относящиеся к конкретному языку и региональным параметрам, можно легко заменять или обновлять, не заменяя главную сборку приложения.

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

Дополнительные сведения см. в статье Упаковка и развертывание ресурсов.

Извлечение ресурсов

Приложение во время выполнения загружает соответствующие локализованные ресурсы отдельно для каждого потока на основе языка и региональных параметров, которые заданы свойством CultureInfo.CurrentUICulture. Значение этого свойства формируется следующим образом:

Присвоением свойству Thread.CurrentUICulture объекта CultureInfo, который представляет локализованные значения языка и региональных параметров.

Если язык и региональные параметры не заданы явным образом, соответствующие значения по умолчанию для пользовательского интерфейса каждого потока извлекаются из свойства CultureInfo.DefaultThreadCurrentUICulture.

Дополнительные сведения об указании языка и региональных параметров для пользовательского интерфейса см. в разделах справки CultureInfo и CultureInfo.CurrentUICulture.

Ресурсы для текущего или определенного языка и региональных параметров пользовательского интерфейса можно получить с помощью класса System.Resources.ResourceManager. Хотя для получения ресурсов чаще всего используется класс ResourceManager, пространство имен System.Resources содержит дополнительные типы, которые можно использовать для получения ресурсов. Сюда входит следующее.

Класс ResourceReader, который позволяет перечислять ресурсы, встроенные в сборку или хранящиеся в отдельном двоичном RESOURCES-файле. Это удобно, когда точные имена ресурсов, доступных во время выполнения, неизвестны.

Класс ResXResourceReader, который позволяет получать ресурсы из XML-файла (.resx).

Класс ResourceSet, который позволяет получать ресурсы для конкретного языка и региональных параметров без учета правил отката. Ресурсы могут храниться в сборке или отдельном двоичном RESOURCES-файле. Можно также разработать реализацию IResourceReader, которая позволит использовать класс ResourceSet для извлечения ресурсов из другого источника.

Класс ResXResourceSet, который позволяет получить в память все элементы из XML-файла ресурсов.

Источник

Ресурсы, Содержимое и Файлы данных WPF-приложения

Файлы ресурсов. файлы данных, компилируемые в исполняемый файл или СБОРКУ библиотеки WPF.

Файлы содержимого: автономные файлы данных с явной связью с исполняемой сборкой WPF.

Файлы исходного узла: автономные файлы данных, не имеющие связи с исполняемой сборкой WPF.

Важным отличием между этими тремя типами файлов является то, что файлы ресурсов и файлы содержимого известны во время построения. Сборка содержит информацию о них. Однако для файлов исходного узла сборка может вообще не иметь сведений о них или неявного набора знаний через универсальный код ресурса (URI) типа pack. в последнем случае нет никакой гарантии, что файл исходного узла, на который указывает ссылка, фактически существует.

для ссылки на файлы данных приложения Windows Presentation Foundation (WPF) использует схему универсального идентификатора ресурса (uri) типа pack, которая подробно описана в разделе uri типа » pack» в WPF.

В этом разделе описывается настройка и использование файлов данных приложения.

Файлы ресурсов

Если файл данных приложения всегда должен быть доступен для приложения, то единственный способ гарантировать доступность — скомпилировать его в главную исполняемую сборку приложения или в одну из его указанных ссылками сборок. Этот тип файла данных приложения называется файлом ресурсов.

Нужно использовать файлы ресурсов, если:

Не нужно обновлять содержимое файла ресурсов после его компиляции в сборку.

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

Файл данных приложения должен быть локализуемой (см. Общие сведения о глобализации и локализации WPF).

Настройка файлов ресурсов

в WPF файл ресурсов — это файл, который включается в проект Microsoft build engine (MSBuild) как Resource элемент.

при построении проекта MSBuild компилирует ресурс в сборку.

Использование файлов ресурсов

Чтобы загрузить файл ресурсов, можно вызвать GetResourceStream метод Application класса, передав URI типа Pack, который идентифицирует нужный файл ресурсов. GetResourceStream Возвращает StreamResourceInfo объект, который предоставляет файл ресурсов как Stream и описывает его тип содержимого.

Например, в следующем коде показано, как использовать GetResourceStream для загрузки Page файла ресурсов и его установки в качестве содержимого объекта Frame ( pageFrame ):

В следующем примере показано, как загрузить объект Page непосредственно в Frame ( pageFrame ) с помощью кода.

В следующем примере показан эквивалент разметки предыдущего примера.

Файлы кода приложения как файлы ресурсов

На Специальный набор файлов кода приложения WPF можно ссылаться с помощью URI типа «Pack», включая окна, страницы, документы нефиксированного формата и словари ресурсов. Например, можно задать Application.StartupUri свойство с URI типа Pack, который ссылается на окно или страницу, которые необходимо загрузить при запуске приложения.

это можно сделать, если XAML-файл включен в проект MSBuild в качестве Page элемента.

в Visual Studio добавить в проект новый. Window NavigationWindow или, Page FlowDocument ResourceDictionary Build Action для файла разметки по умолчанию будет Page выбрано значение.

При компиляции проекта с Page элементами XAML элементы преобразуются в двоичный формат и компилируются в связанную сборку. Следовательно, эти файлы можно использовать таким же образом, как и обычные файлы ресурсов.

Файлы с содержимым

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

Файлы содержимого необходимо использовать, если приложению требуется определенный набор файлов данных приложения, которые нужно обновлять без повторной компиляции использующей их сборки.

Настройка файлов содержимого

Ниже показан файл, настроенный как файл содержимого, который копируется в папку выходных данных построения только при добавлении новой версии ресурса в проект.

При построении проекта AssemblyAssociatedContentFileAttribute атрибут компилируется в метаданные сборки для каждого файла содержимого.

AssemblyAssociatedContentFileAttributeЗначение является также значением пути к файлу содержимого в выходной папке построения.

Использование файлов содержимого

Чтобы загрузить файл содержимого, можно вызвать GetContentStream метод Application класса, передав URI типа Pack, который идентифицирует нужный файл содержимого. GetContentStream Возвращает StreamResourceInfo объект, который предоставляет файл содержимого в виде Stream и описывает его тип содержимого.

Например, в следующем коде показано, как использовать GetContentStream для загрузки Page файла содержимого и его установки в качестве содержимого объекта Frame ( pageFrame ).

В следующем примере показано, как загрузить объект Page непосредственно в Frame ( pageFrame ) с помощью кода.

В следующем примере показан эквивалент разметки предыдущего примера.

Файлы исходного узла

Файл не существует во время компиляции.

Неизвестно, какие файлы потребуются для сборки до времени выполнения.

Нужна возможность обновлять файлы без повторной компиляции сборки, связанной с ними.

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

Эти типы файлов можно загрузить с помощью традиционных схем URI, таких как file:/// http:// схемы и.

Файлы исходного узла являются единственным вариантом для приложений с частичным доверием, хотя и не ограничиваются такими приложениями. Приложениям с полным доверием, возможно, все равно придется загружать файлы данных приложений, о которых они не знают во время построения. Хотя приложения с полным доверием могут использовать схему file:///, вероятнее всего, файлы данных приложения будут установлены в одну папку или вложенную папку со сборкой приложения. В этом случае использовать ссылки на исходный узел проще, чем использовать file:///, так как последнее требует разработки полного пути к файлу.

Файлы исходного узла не кэшируются с помощью приложения браузера XAML (XBAP) на клиентском компьютере, а файлы содержимого —. Следовательно, они загружаются только по специальному запросу. Если приложение браузера XAML (XBAP) имеет большие файлы мультимедиа, их настройка в качестве файлов исходного узла означает, что начальный запуск приложения выполняется гораздо быстрее, а файлы загружаются по требованию.

Настройка файлов исходного узла

если файлы исходного сайта не существуют или неизвестны во время компиляции, необходимо использовать традиционные механизмы развертывания для обеспечения доступности необходимых файлов во время выполнения, в том числе с помощью XCopy программы командной строки или Microsoft установщик Windows.

если во время компиляции вы узнаете, какие файлы необходимо найти на исходном узле, но все равно хотите избежать явной зависимости, эти файлы можно добавить в проект MSBuild в качестве None элемента. как и в случае с файлами содержимого, необходимо задать атрибут MSBuild, CopyToOutputDirectory чтобы указать, что файл исходного узла копируется в расположение относительно сборки, указав либо значение, либо Always PreserveNewest значение.

при построении проекта MSBuild копирует указанные файлы в выходную папку сборки.

Использование файлов исходного узла

Чтобы загрузить файл исходного узла, можно вызвать GetRemoteStream метод Application класса, передав URI типа Pack, который идентифицирует нужный файл исходного узла. GetRemoteStream Возвращает StreamResourceInfo объект, который предоставляет файл исходного узла как Stream и описывает его тип содержимого.

В следующем примере кода показано, как использовать GetRemoteStream для загрузки Page файла исходного узла и задать его в качестве содержимого объекта Frame ( pageFrame ).

В следующем примере показано, как загрузить объект Page непосредственно в Frame ( pageFrame ) с помощью кода.

В следующем примере показан эквивалент разметки предыдущего примера.

Повторное построение после изменения типа построения

После изменения типа построения файла данных приложения необходимо перестроить все приложение, чтобы обеспечить применение этих изменений. Если просто выполнить построение приложения, изменения не применяются.

Источник