Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Более крупные игры для универсальной платформы 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, use \images\background.png.
Ниже приведены следующие зарезервированные имена каталогов и префиксы подчеркивания имени файла:
| Тип ресурса | Имя каталога пакета ресурсов | Суффикс имени файла пакета ресурсов |
|---|---|---|
| Локализованные ресурсы | Все возможные языки или комбинации языков и региональных настроек для Windows 10. (Префикс квалификатора "lang-" не требуется в имени папки.) | Знак "_" с последующим указанием языка, локали или комбинации языка и локали. Например, "_en", "_us" или "_en-us" соответственно. |
| Активы с коэффициентом масштабирования | масштаб-100, масштаб-140, масштаб-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 and \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->Создать пакет приложения... и создайте пакет.
Определение пакетов ресурсов с коэффициентом масштабирования
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 and \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 // 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.
Связанные темы