Упаковка игры DirectX универсальная платформа Windows (UWP)
Более крупные игры универсальная платформа Windows (UWP), особенно те, которые поддерживают несколько языков с ресурсами, зависящими от региона или дополнительными ресурсами с высоким определением, могут легко выполнять воздушные шары до больших размеров. В этом разделе вы узнаете, как использовать пакеты приложений и пакеты приложений для настройки приложения, чтобы клиенты получали только необходимые им ресурсы.
Помимо модели пакета приложений Windows 10 поддерживает пакеты приложений, которые объединяют два типа пакетов:
- Пакеты приложений содержат исполняемые файлы и библиотеки для конкретной платформы. Как правило, игра UWP может содержать до трех пакетов приложений: по одному для архитектур x86, x64 и Arm ЦП. Все код и данные, относящиеся к этой аппаратной платформе, должны быть включены в пакет приложения. Пакет приложений также должен содержать все основные ресурсы для запуска игры с базовым уровнем точности и производительности.
- Пакеты ресурсов содержат необязательные или расширенные данные, не зависящие от платформы, такие как игровые ресурсы (текстуры, сетки, звук, текст). В игре UWP может быть один или несколько пакетов ресурсов, включая пакеты ресурсов для ресурсов высокого определения или текстур, ресурсы и ресурсы directX уровня 11+ или ресурсы, относящиеся к языку.
Дополнительные сведения о пакетах приложений и пакетах приложений см. в разделе "Определение ресурсов приложения".
Хотя все содержимое можно разместить в пакетах приложений, это неэффективно и избыточно. Почему один и тот же большой файл текстуры реплицируется три раза для каждой платформы, особенно для платформ Arm, которые не могут использовать его? Хорошая цель заключается в том, чтобы попытаться свести к минимуму то, что ваш клиент должен скачать, чтобы они могли начать играть в игру раньше, сэкономить место на своем устройстве и избежать возможных затрат на пропускную способность с лимитной пропускной способностью.
Чтобы использовать эту функцию установщика приложений UWP, важно рассмотреть соглашения о макете каталога и именовании файлов для упаковки приложений и ресурсов на ранних этапах разработки игр, чтобы средства и источник могли правильно выводить их таким образом, чтобы сделать упаковку простой. Следуйте правилам, описанным в этом документе при разработке или настройке средств и сценариев, а также при создании кода, загружающего или ссылающегося на ресурсы.
Зачем создавать пакеты ресурсов?
При создании приложения, особенно игрового приложения, которое может быть продано во многих языковых стандартах или широком спектре аппаратных платформ UWP, часто необходимо включить несколько версий многих файлов для поддержки этих языковых стандартов или платформ. Например, если вы выпускаете игру как в США, так и в Японии, может потребоваться один набор голосовых файлов на английском языке для языковых стандартов en-us, а другой — на японском языке для языкового стандарта jp-jp. Кроме того, если вы хотите использовать образ в игре для устройств Arm, а также платформ x86 и x64, необходимо отправить один и тот же ресурс образа 3 раза для каждой архитектуры ЦП.
Кроме того, если в игре есть много ресурсов высокого определения, которые не применяются к платформам с более низким уровнем функций DirectX, зачем включать их в базовый пакет приложений и требовать, чтобы пользователь скачать большой объем компонентов, которые устройство не может использовать? Разделяя эти ресурсы с высокой задержкой на необязательный пакет ресурсов, означает, что клиенты с устройствами, поддерживающими эти ресурсы с высокой задержкой, могут получить их за счет пропускной способности (возможно, лимитной) пропускной способности, в то время как те, у кого нет устройств с более высоким уровнем обслуживания, могут быстрее и при более низкой стоимости использования сети.
К кандидатам содержимого для пакетов ресурсов игры относятся:
- Международные ресурсы языкового стандарта (локализованный текст, звук или изображения)
- Ресурсы с высоким разрешением для различных факторов масштабирования устройств (1.0x, 1.4x и 1.8x)
- Ресурсы высокого определения для более высоких уровней функций DirectX (9, 10 и 11)
Все это определяется в пакете.appxmanifest, который является частью проекта UWP, а также в структуре каталогов окончательного пакета. Из-за нового пользовательского интерфейса Visual Studio, если вы следуете за процессом в этом документе, его не нужно изменять вручную.
Важно, чтобы загрузка и управление этими ресурсами обрабатывались с помощью API Windows.ApplicationModel.Resources*. Если вы используете эти API-интерфейсы ресурсов модели приложений для загрузки правильного файла для языкового стандарта, коэффициента масштабирования или уровня компонентов DirectX, вам не нужно загружать ресурсы с помощью явных путей к файлам; Вместо этого вы предоставляете API-интерфейсы ресурсов только с универсальным именем нужного ресурса и позволяет системе управления ресурсами получить правильный вариант ресурса для текущей платформы пользователя и конфигурации языкового стандарта (которые можно указать непосредственно с этими же API).
Ресурсы для упаковки ресурсов указываются одним из двух основных способов:
- Файлы активов имеют то же имя файла, а определенные версии пакета ресурсов помещаются в определенные именованные каталоги. Эти имена каталогов зарезервированы системой. Например, \en-us, \scale-140, \dxfl-dx11.
- Файлы активов хранятся в папках с произвольными именами, но файлы именуются с общей меткой, которая добавляется со строками, зарезервированными системой для обозначения языка или других квалификаторов. В частности, строки квалификатора прикрепляются к обобщенным имени файла после подчеркивания ("_"). Например, \assets\menu_option1_lang-en-us.png, \assets\menu_option1_scale-140.png, \assets\coolsign_dxfl-dx11.dds. Вы также можете объединить эти строки. Например, \assets\menu_option1_scale-140_lang-en-us.png.
Обратите внимание, что при использовании в имени файла, а не только в имени каталога, квалификатор языка должен принимать форму lang-tag<>, например "lang-en-us", как описано в разделе "Настройка ресурсов для языка, масштабирования и других квалификаторов".
Имена каталогов можно объединить для дополнительной специфики упаковки ресурсов. Однако они не могут быть избыточными. Например, \en-us\menu_option1_lang-en-us.png является избыточным.
Вы можете указать все не зарезервированные имена подкаталогов, необходимые в каталоге ресурсов, если структура каталогов идентична в каждом каталоге ресурсов. Например, \dxfl-dx10\assets\textures\coolsign.dds. При загрузке или ссылке на ресурс имя пути должно быть обобщенным, удаляя все квалификаторы для языка, масштабирования или уровня компонентов DirectX, будь то в узлах папок или в именах файлов. Например, чтобы ссылаться на код на ресурс, для которого один из вариантов : \dxfl-dx10\assets\textures\coolsign.dds, используйте \assets\textures\coolsign.dds. Аналогичным образом, чтобы ссылаться на ресурс с вариантом \images\background_scale-140.png, используйте \images\background.png.
Ниже приведены следующие зарезервированные имена каталогов и префиксы подчеркивания имени файла:
| Вид актива | Имя каталога пакета ресурсов | Суффикс имени файла пакета ресурсов |
|---|---|---|
| Локализованные ресурсы | Все возможные языки или сочетания языков и языков для Windows 10. (Префикс квалификатора "lang-" не требуется в имени папки.) | Значение "_", за которым следует описатель языка, языкового стандарта или языкового стандарта. Например, "_en", "_us" или "_en-us" соответственно. |
| Масштабируемые ресурсы | scale-100, scale-140, scale-180. Они предназначены для коэффициентов масштабирования пользовательского интерфейса 1.0x, 1.4x и 1.8x соответственно. | Значение "_", за которым следует "scale-100", "scale-140" или "scale-180". |
| Ресурсы уровня компонентов DirectX | dxfl-dx9, dxfl-dx10 и dxfl-dx11. Они предназначены для уровней компонентов DirectX 9, 10 и 11 соответственно. | За "_" следует "dxfl-dx9", "dxfl-dx10", или "dxfl-dx11". |
Определение локализованных языковых пакетов ресурсов
Файлы, относящиеся к языковому стандарту, помещаются в каталоги проекта с именем языка (например, en).
При настройке приложения для поддержки локализованных ресурсов на нескольких языках необходимо:
Создайте подкаталог приложения (или версию файла) для каждого языка и языкового стандарта, который вы будете поддерживать (например, en-us, jp-jp, zh-cn, fr-fr и т. д.).
Во время разработки поместите копии всех ресурсов (например, локализованные звуковые файлы, текстуры и графику меню) в соответствующем подкаталоге языка, даже если они не отличаются между языками или языковыми стандартами. Для лучшего взаимодействия с пользователем убедитесь, что пользователь оповещен, если он не получил доступный языковой пакет ресурсов для языкового стандарта, если он доступен (или если он случайно удалил его после скачивания и установки).
Убедитесь, что каждый ресурс или файл строковых ресурсов (RESW) имеет одинаковое имя в каждом каталоге. Например, menu_option1.png должны иметь одинаковое имя в каталогах \en-us и \jp-jp, даже если содержимое файла предназначено для другого языка. В этом случае вы увидите их как \en-us\menu_option1.png и \jp-jp\menu_option1.png.
Примечание. При необходимости можно добавить языковой стандарт к имени файла и сохранить их в одном каталоге, например \assets\menu_option1_lang-en-us.png, \assets\menu_option1_lang-jp-jp.png.
Используйте API в Windows.ApplicationModel.Resources и Windows.ApplicationModel.Resources.Core, чтобы указать и загрузить ресурсы для конкретного языкового стандарта для приложения. Кроме того, используйте ссылки на ресурсы, которые не включают конкретный языковой стандарт, так как эти API определяют правильный языковой стандарт на основе параметров пользователя, а затем извлекают правильный ресурс для пользователя.
В Microsoft Visual Studio 2015 выберите project-Store-Create>> App Package... и создайте пакет.
Определение пакетов ресурсов для масштабирования
Windows 10 предоставляет три фактора масштабирования пользовательского интерфейса: 1.0x, 1.4x и 1.8x. Значения масштабирования для каждого дисплея задаются во время установки на основе ряда объединенных факторов: размера экрана, разрешения экрана и предполагаемого среднего расстояния пользователя от экрана. Пользователь также может настроить коэффициенты масштабирования, чтобы улучшить удобочитаемость. Ваша игра должна быть как с поддержкой DPI, так и с учетом коэффициентов масштабирования для оптимального взаимодействия. Часть этой осведомленности означает создание версий критически важных визуальных ресурсов для каждого из трех факторов масштабирования. Это также включает в себя взаимодействие указателя и тестирование попаданий!
При настройке приложения для поддержки пакетов ресурсов для различных факторов масштабирования приложений UWP необходимо:
Создайте подкаталог приложения (или версию файла) для каждого коэффициента масштабирования, который будет поддерживаться (scale-100, scale-140 и scale-180).
Во время разработки поместите копии всех активов в каждом каталоге ресурсов коэффициента масштабирования, даже если они не отличаются между масштабируемыми факторами.
Убедитесь, что каждый ресурс имеет одинаковое имя в каждом каталоге. Например, menu_option1.png должны иметь одинаковое имя в каталогах \scale-100 и \scale-180, даже если содержимое файла отличается. В этом случае вы увидите их как \scale-100\menu_option1.png и \scale-140\menu_option1.png.
Обратите внимание , что при необходимости можно добавить суффикс коэффициента масштабирования к имени файла и сохранить их в одном каталоге, например \assets\menu_option1_scale-100.png, \assets\menu_option1_scale-140.png.
Используйте API в Windows.ApplicationModel.Resources.Core для загрузки ресурсов. Ссылки на ресурсы должны быть обобщены (без суффикса), оставляя определенный вариант масштабирования. Система получит соответствующий масштабируемый ресурс для отображения и параметров пользователя.
В Visual Studio 2015 выберите project-Store-Create>> App Package... и создайте пакет.
Определение пакетов ресурсов уровня компонентов DirectX
Уровни компонентов DirectX соответствуют наборам функций GPU для предыдущих и текущих версий DirectX (в частности Direct3D). Сюда входят спецификации и функциональные возможности модели шейдера, поддержка языка шейдера, поддержка сжатия текстур и общие функции графического конвейера.
Базовый пакет приложения должен использовать базовые форматы сжатия текстур: BC1, BC2 или BC3. Эти форматы можно использовать любым устройством UWP, от низкоуровневых платформ Arm до выделенных рабочих станций с несколькими GPU и компьютеров мультимедиа.
Поддержка формата текстур на уровне компонентов DirectX 10 или более поздней версии должна быть добавлена в пакет ресурсов для экономии места на локальном диске и загрузки пропускной способности. Это позволяет использовать более сложные схемы сжатия для 11, например BC6H и BC7. (Дополнительные сведения см. в разделе Сжатие блоков текстур в Direct3D 11.) Эти форматы более эффективны для ресурсов текстур с высоким разрешением, поддерживаемых современными графическими процессорами, и их использование улучшает внешний вид, производительность и требования к пространству игры на высокоуровневых платформах.
| Уровень компонентов DirectX | Поддерживаемая сжатие текстуры |
|---|---|
| 9 | BC1, BC2, BC3 |
| 10 | BC4, BC5 |
| 11 | BC6H, BC7 |
Кроме того, каждый уровень компонентов DirectX поддерживает разные версии модели шейдеров. Скомпилированные ресурсы шейдеров можно создавать на уровне компонентов и включать в пакеты ресурсов уровня компонентов DirectX. Кроме того, некоторые более поздние модели шейдера версий могут использовать ресурсы, такие как обычные карты, которые более ранние версии модели шейдеров не могут. Эти ресурсы модели шейдера должны быть включены в пакет ресурсов уровня компонентов DirectX, а также.
Механизм ресурсов в основном ориентирован на форматы текстур, поддерживаемые для ресурсов, поэтому он поддерживает только 3 общих уровня функций. Если вам нужно иметь отдельные шейдеры для подуровневых (точек версий), таких как DX9_1 и DX9_3, то код управления активами и отрисовки должен обрабатывать их явным образом.
При настройке приложения для поддержки пакетов ресурсов для различных уровней компонентов DirectX необходимо:
Создайте подкаталог приложения (или версию файла) для каждого уровня компонентов DirectX, который вы будете поддерживать (dxfl-dx9, dxfl-dx10 и dxfl-dx11).
Во время разработки поместите определенные ресурсы уровня компонентов в каждом каталоге ресурсов уровня компонентов. В отличие от языковых стандартов и факторов масштабирования, у вас могут быть разные ветви кода отрисовки для каждого уровня компонентов в игре, а также если у вас есть текстуры, скомпилированные шейдеры или другие ресурсы, которые используются только в одном или подмножестве всех поддерживаемых уровней функций, поместите соответствующие ресурсы только в каталоги для уровней функций, которые используют их. Для ресурсов, загруженных на всех уровнях компонентов, убедитесь, что каждый каталог ресурсов уровня компонентов имеет версию с одинаковым именем. Например, для независимой текстуры уровня компонентов с именем "coolsign.dds", поместите сжатую версию BC3 в каталог \dxfl-dx9 и версию BC7-сжатых в каталоге \dxfl-dx11.
Убедитесь, что каждый ресурс (если он доступен для нескольких уровней компонентов) имеет одинаковое имя в каждом каталоге. Например, coolsign.dds должны иметь одинаковое имя в каталогах \dxfl-dx9 и \dxfl-dx11, даже если содержимое файла отличается. В этом случае вы увидите их как \dxfl-dx9\coolsign.dds и \dxfl-dx11\coolsign.dds.
Обратите внимание , что можно добавить суффикс уровня компонентов к имени файла и сохранить их в одном каталоге, например \textures\coolsign_dxfl-dx9.dds, \textures\coolsign_dxfl-dx11.dds.
Объявите поддерживаемые уровни функций DirectX при настройке графических ресурсов.
D3D_FEATURE_LEVEL featureLevels[] = { D3D_FEATURE_LEVEL_11_1, D3D_FEATURE_LEVEL_11_0, D3D_FEATURE_LEVEL_10_1, D3D_FEATURE_LEVEL_10_0, D3D_FEATURE_LEVEL_9_3, D3D_FEATURE_LEVEL_9_1 };ComPtr<ID3D11Device> device; ComPtr<ID3D11DeviceContext> context; D3D11CreateDevice( nullptr, // Use the default adapter. D3D_DRIVER_TYPE_HARDWARE, 0, // Use 0 unless it is a software device. creationFlags, // defined above featureLevels, // What the app will support. ARRAYSIZE(featureLevels), D3D11_SDK_VERSION, // This should always be D3D11_SDK_VERSION. &device, // created device &m_featureLevel, // The feature level of the device. &context // The corresponding immediate context. );Используйте API в Windows.ApplicationModel.Resources.Core для загрузки ресурсов. Ссылки на ресурсы должны быть обобщены (без суффикса), оставляя уровень компонентов. Однако, в отличие от языка и масштабирования, система не определяет, какой уровень компонентов является оптимальным для данного дисплея; это осталось для определения на основе логики кода. После того как вы сделаете это определение, используйте API для информирования ОС о предпочтительном уровне компонентов. Затем система сможет получить правильный ресурс на основе этого предпочтения. Ниже приведен пример кода, в котором показано, как сообщить приложению текущего уровня компонентов DirectX для платформы:
// Set the current UI thread's MRT ResourceContext's DXFeatureLevel with the right DXFL. Platform::String^ dxFeatureLevel; switch (m_featureLevel) { case D3D_FEATURE_LEVEL_9_1: case D3D_FEATURE_LEVEL_9_2: case D3D_FEATURE_LEVEL_9_3: dxFeatureLevel = L"DX9"; break; case D3D_FEATURE_LEVEL_10_0: case D3D_FEATURE_LEVEL_10_1: dxFeatureLevel = L"DX10"; break; default: dxFeatureLevel = L"DX11"; } ResourceContext::SetGlobalQualifierValue(L"DXFeatureLevel", dxFeatureLevel);
Примечание.
В коде загрузите текстуру непосредственно по имени (или путь ниже каталога уровня компонентов). Не включайте имя каталога уровня компонентов или суффикс. Например, загрузите "текстуры\coolsign.dds", а не "dxfl-dx11\textures\coolsign.dds" или "текстуры\coolsign_dxfl-dx11.dds".
Теперь используйте ResourceManager , чтобы найти файл, соответствующий текущему уровню компонентов DirectX. ResourceManager возвращает ResourceMap, который запрашивается с помощью ResourceMap::GetValue (или ResourceMap::TryGetValue) и предоставленного resourceContext. Возвращается resourceCandidate, который наиболее тесно соответствует уровню компонентов DirectX, который был указан путем вызова SetGlobalQualifierValue.
// An explicit ResourceContext is needed to match the DirectX feature level for the display on which the current view is presented. auto resourceContext = ResourceContext::GetForCurrentView(); auto mainResourceMap = ResourceManager::Current->MainResourceMap; // For this code example, loader is a custom ref class used to load resources. // You can use the BasicLoader class from any of the 8.1 DirectX samples similarly. auto possibleResource = mainResourceMap->GetValue( L"Files/BumpPixelShader.cso", resourceContext ); Platform::String^ resourceName = possibleResource->ValueAsString;В Visual Studio 2015 выберите project-Store-Create>> App Package... и создайте пакет.
Убедитесь, что вы включите пакеты приложений в параметрах манифеста package.appxmanifest.
См. также