Empaqueter votre jeu DirectX (UWP) plateforme Windows universelle

Les jeux de plateforme Windows universelle plus volumineux (UWP), en particulier ceux qui prennent en charge plusieurs langues avec des ressources spécifiques à une région ou des ressources de haute définition facultatives, peuvent facilement atteindre de grandes tailles. Dans cette rubrique, découvrez comment utiliser des packages d’applications et des offres groupées d’applications pour personnaliser votre application afin que vos clients reçoivent uniquement les ressources dont ils ont réellement besoin.

Outre le modèle de package d’application, Windows 10 prend en charge les offres groupées d’applications qui regroupent deux types de packs :

• Les packs d’applications contiennent des exécutables et des bibliothèques spécifiques à la plateforme. En règle générale, un jeu UWP peut avoir jusqu’à trois packs d’applications : un pour les architectures x86, x64 et Arm CPU. Tout le code et les données spécifiques à cette plateforme matérielle doivent être inclus dans son pack d’applications. Un pack d’applications doit également contenir toutes les ressources principales du jeu à exécuter avec un niveau de fidélité et de performances de référence.
• Les packs de ressources contiennent des données facultatives ou indépendantes de la plateforme, telles que des ressources de jeu (textures, maillages, son, texte). Un jeu UWP peut avoir un ou plusieurs packs de ressources, y compris les packs de ressources pour les ressources ou textures haute définition, les ressources et ressources de niveau de fonctionnalité DirectX de niveau 11+, ou les ressources et ressources propres à la langue.

Pour plus d’informations sur les offres groupées d’applications et les packs d’applications, consultez Définition des ressources d’application.

Bien que vous puissiez placer tout le contenu dans vos packs d’applications, cela est inefficace et redondant. Pourquoi le même fichier de texture volumineux a-t-il été répliqué trois fois pour chaque plateforme, en particulier pour les plateformes Arm qui peuvent ne pas l’utiliser ? Un bon objectif est d’essayer de réduire ce que votre client doit télécharger, afin qu’il puisse commencer à jouer votre jeu plus tôt, économiser de l’espace sur leur appareil et éviter les coûts de bande passante limitée possibles.

Pour utiliser cette fonctionnalité du programme d’installation de l’application UWP, il est important de prendre en compte les conventions de mise en page et de nommage des fichiers pour l’application et l’empaquetage des ressources au début du développement de jeux, afin que vos outils et votre source puissent les générer correctement de manière à simplifier l’empaquetage. Suivez les règles décrites dans ce document lors du développement ou de la configuration de la création et de la gestion des ressources et des scripts, et lors de la création de code qui charge ou référence des ressources.

Pourquoi créer des packs de ressources ?

Lorsque vous créez une application, en particulier une application de jeu qui peut être vendue dans de nombreux paramètres régionaux ou dans un large éventail de plateformes matérielles UWP, vous devez souvent inclure plusieurs versions de nombreux fichiers pour prendre en charge ces paramètres régionaux ou plateformes. Par exemple, si vous publiez votre jeu dans les États-Unis et le Japon, vous aurez peut-être besoin d’un ensemble de fichiers vocaux en anglais pour les paramètres régionaux en-us, et un autre en japonais pour les paramètres régionaux jp-jp. Ou, si vous souhaitez utiliser une image dans votre jeu pour les appareils Arm ainsi que des plateformes x86 et x64, vous devez charger la même ressource d’image 3 fois, une fois pour chaque architecture de processeur.

En outre, si votre jeu a beaucoup de ressources haute définition qui ne s’appliquent pas aux plateformes avec des niveaux de fonctionnalités DirectX inférieurs, pourquoi les inclure dans le pack d’application de référence et demander à votre utilisateur de télécharger un grand volume de composants que l’appareil ne peut pas utiliser ? La séparation de ces ressources de haute taille en un pack de ressources facultatif signifie que les clients disposant d’appareils qui prennent en charge ces ressources à haut niveau peuvent les obtenir au coût de la bande passante (éventuellement limitée), tandis que ceux qui n’ont pas d’appareils plus haut de gamme peuvent obtenir leur jeu plus rapidement et à un coût d’utilisation réseau inférieur.

Les candidats au contenu pour les packs de ressources de jeu sont les suivants :

• Ressources spécifiques aux paramètres régionaux internationaux (texte localisé, audio ou images)
• Ressources haute résolution pour différents facteurs de mise à l’échelle des appareils (1.0x, 1.4x et 1.8x)
• Ressources haute définition pour les niveaux de fonctionnalités DirectX supérieurs (9, 10 et 11)

Tout cela est défini dans le package.appxmanifest qui fait partie de votre projet UWP et dans votre structure de répertoires de votre package final. En raison de la nouvelle interface utilisateur de Visual Studio, si vous suivez le processus dans ce document, vous n’avez pas besoin de le modifier manuellement.

Important Le chargement et la gestion de ces ressources sont gérés via les API Windows.ApplicationModel.Resources*. Si vous utilisez ces API de ressource de modèle d’application pour charger le fichier approprié pour les paramètres régionaux, le facteur de mise à l’échelle ou le niveau de fonctionnalité DirectX, vous n’avez pas besoin de charger vos ressources à l’aide de chemins de fichier explicites ; vous fournissez plutôt les API de ressource avec uniquement le nom de fichier généralisé de la ressource souhaitée et laissez le système de gestion des ressources obtenir la variante correcte de la ressource pour la configuration actuelle de la plateforme et des paramètres régionaux de l’utilisateur (que vous pouvez spécifier directement avec ces mêmes API).

Les ressources pour l’empaquetage des ressources sont spécifiées de l’une des deux manières de base :

• Les fichiers de ressources ont le même nom de fichier et les versions spécifiques du pack de ressources sont placées dans des répertoires nommés spécifiques. Ces noms de répertoires sont réservés par le système. Par exemple, \en-us, \scale-140, \dxfl-dx11.
• Les fichiers multimédias sont stockés dans des dossiers avec des noms arbitraires, mais les fichiers sont nommés avec une étiquette commune ajoutée avec des chaînes réservées par le système pour désigner la langue ou d’autres qualificateurs. Plus précisément, les chaînes de qualificateur sont attachées au nom de fichier généralisé après un trait de soulignement (« _ »). Par exemple, \assets\menu_option1_lang-en-us.png, \assets\menu_option1_scale-140.png, \assets\coolsign_dxfl-dx11.dds. Vous pouvez également combiner ces chaînes. Par exemple, \assets\menu_option1_scale-140_lang-en-us.png.

  Remarque Lorsqu’il est utilisé dans un nom de fichier plutôt que seul dans un nom de répertoire, un qualificateur de langue doit prendre la forme « lang-tag<> », par exemple « lang-en-us », comme décrit dans Personnaliser vos ressources pour la langue, l’échelle et d’autres qualificateurs.

Les noms de répertoires peuvent être combinés pour une spécificité supplémentaire dans l’empaquetage de ressources. Toutefois, elles ne peuvent pas être redondantes. Par exemple, \en-us\menu_option1_lang-en-us.png est redondant.

Vous pouvez spécifier les noms de sous-répertoires non réservés dont vous avez besoin sous un répertoire de ressources, tant que la structure de répertoires est identique dans chaque répertoire de ressources. Par exemple, \dxfl-dx10\assets\textures\coolsign.dds. Lorsque vous chargez ou référencez une ressource, le chemin d’accès doit être généralisé, en supprimant les qualificateurs pour la langue, l’échelle ou le niveau de fonctionnalité DirectX, qu’ils se trouvent dans des nœuds de dossier ou dans les noms de fichiers. Par exemple, pour faire référence au code à une ressource pour laquelle l’une des variantes est \dxfl-dx10\assets\textures\coolsign.dds, utilisez \assets\textures\coolsign.dds. De même, pour faire référence à une ressource avec une variante \images\background_scale-140.png, utilisez \images\background.png.

Voici les noms de répertoires réservés et les préfixes de soulignement de nom de fichier suivants :

Définition des packs de ressources linguistiques localisés

Les fichiers spécifiques aux paramètres régionaux sont placés dans des répertoires de projet nommés pour la langue (par exemple, « en »).

Lorsque vous configurez votre application pour prendre en charge les ressources localisées pour plusieurs langues, vous devez :

• Créez un sous-répertoire d’application (ou version de fichier) pour chaque langue et paramètres régionaux que vous prendrez en charge (par exemple, en-us, jp-jp, zh-cn, fr-fr, etc.).

• Pendant le développement, placez des copies de toutes les ressources (telles que les fichiers audio localisés, les textures et les graphiques de menu) dans le sous-répertoire des paramètres régionaux de la langue correspondante, même s’ils ne sont pas différents entre les langues ou les paramètres régionaux. Pour une expérience utilisateur optimale, assurez-vous que l’utilisateur est averti s’il n’a pas obtenu de pack de ressources linguistiques disponible pour ses paramètres régionaux s’il est disponible (ou s’il l’a supprimé accidentellement après le téléchargement et l’installation).

• Vérifiez que chaque fichier de ressource ou de ressource de chaîne (.resw) porte le même nom dans chaque répertoire. Par exemple, menu_option1.png doit avoir le même nom dans les répertoires \en-us et \jp-jp-jp même si le contenu du fichier est pour une autre langue. Dans ce cas, vous les voyiez sous la forme \en-us\menu_option1.png et \jp-jp\menu_option1.png.

  Notez que vous pouvez éventuellement ajouter les paramètres régionaux au nom de fichier et les stocker dans le même répertoire ; par exemple, \assets\menu_option1_lang-en-us.png, \assets\menu_option1_lang-jp-jp.png.

   

• Utilisez les API dans Windows.ApplicationModel.Resources et Windows.ApplicationModel.Resources.Core pour spécifier et charger les ressources spécifiques aux paramètres régionaux pour votre application. Utilisez également des références de ressources qui n’incluent pas les paramètres régionaux spécifiques, car ces API déterminent les paramètres régionaux appropriés en fonction des paramètres de l’utilisateur, puis récupèrent la ressource appropriée pour l’utilisateur.

• Dans Microsoft Visual Studio 2015, sélectionnez PROJECT-Store-Create>> App Package... et créez le package.

Définition des packs de ressources de facteur de mise à l’échelle

Windows 10 fournit trois facteurs de mise à l’échelle de l’interface utilisateur : 1.0x, 1.4x et 1.8x. Les valeurs de mise à l’échelle pour chaque affichage sont définies pendant l’installation en fonction d’un certain nombre de facteurs combinés : la taille de l’écran, la résolution de l’écran et la distance moyenne supposée de l’utilisateur de l’écran. L’utilisateur peut également ajuster les facteurs d’échelle pour améliorer la lisibilité. Votre jeu doit être à la fois prenant en charge les ppp et le facteur de mise à l’échelle pour la meilleure expérience possible. Une partie de cette prise de conscience signifie la création de versions de ressources visuelles critiques pour chacun des trois facteurs de mise à l’échelle. Cela inclut également l’interaction de pointeur et les tests de positionnement !

Lorsque vous configurez votre application pour prendre en charge les packs de ressources pour différents facteurs de mise à l’échelle des applications UWP, vous devez :

• Créez un sous-répertoire d’application (ou version de fichier) pour chaque facteur de mise à l’échelle que vous prendrez en charge (scale-100, scale-140 et scale-180).

• Pendant le développement, placez des copies appropriées du facteur d’échelle de toutes les ressources dans chaque répertoire de ressources de facteur d’échelle, même si elles ne sont pas différentes entre les facteurs de mise à l’échelle.

• Vérifiez que chaque ressource a le même nom dans chaque répertoire. Par exemple, menu_option1.png doit avoir le même nom dans les répertoires \scale-100 et \scale-180, même si le contenu du fichier est différent. Dans ce cas, vous les voyez sous la forme \scale-100\menu_option1.png et \scale-140\menu_option1.png.

  Notez à nouveau que vous pouvez ajouter le suffixe du facteur de mise à l’échelle au nom de fichier et les stocker dans le même répertoire ; par exemple, \assets\menu_option1_scale-100.png, \assets\menu_option1_scale-140.png.

   

• Utilisez les API dans Windows.ApplicationModel.Resources.Core pour charger les ressources. Les références d’éléments multimédias doivent être généralisées (aucun suffixe), sans tenir compte de la variation d’échelle spécifique. Le système récupère la ressource d’échelle appropriée pour l’affichage et les paramètres de l’utilisateur.

• Dans Visual Studio 2015, sélectionnez PROJECT-Store-Create>> App Package... et créez le package.

Définition des packs de ressources au niveau des fonctionnalités DirectX

Les niveaux de fonctionnalités DirectX correspondent aux ensembles de fonctionnalités GPU pour les versions antérieures et actuelles de DirectX (plus précisément, Direct3D). Cela inclut les spécifications et fonctionnalités du modèle de nuanceur, la prise en charge du langage de nuanceur, la prise en charge de la compression de texture et les fonctionnalités globales du pipeline graphique.

Votre pack d’application de référence doit utiliser les formats de compression de texture de base : BC1, BC2 ou BC3. Ces formats peuvent être consommés par n’importe quel appareil UWP, à partir de plateformes Arm bas de gamme jusqu’aux stations de travail multi-GPU dédiées et aux ordinateurs multimédias.

La prise en charge du format de texture au niveau de fonctionnalité DirectX 10 ou version ultérieure doit être ajoutée dans un pack de ressources pour conserver l’espace disque local et la bande passante de téléchargement. Cela permet d’utiliser les schémas de compression plus avancés pour 11, comme BC6H et BC7. (Pour plus d’informations, consultez Compression de bloc de texture dans Direct3D 11.) Ces formats sont plus efficaces pour les ressources de texture haute résolution prises en charge par les GPU modernes, et leur utilisation améliore l’apparence, les performances et les besoins en espace de votre jeu sur des plateformes haut de gamme.

En outre, chaque niveau de fonctionnalité DirectX prend en charge différentes versions du modèle de nuanceur. Les ressources de nuanceur compilées peuvent être créées au niveau de la fonctionnalité et peuvent être incluses dans les packs de ressources au niveau des fonctionnalités DirectX. En outre, certains modèles de nuanceur de versions ultérieures peuvent utiliser des ressources, telles que des cartes normales, que les versions antérieures du modèle de nuanceur ne peuvent pas. Ces ressources spécifiques au modèle de nuanceur doivent également être incluses dans un pack de ressources au niveau des fonctionnalités DirectX.

Le mécanisme de ressource est principalement axé sur les formats de texture pris en charge pour les ressources, de sorte qu’il ne prend en charge que les 3 niveaux de fonctionnalités globaux. Si vous devez disposer de nuanceurs distincts pour les sous-niveaux (versions de points) tels que DX9_1 et DX9_3, la gestion des ressources et le code de rendu doivent les gérer explicitement.

Lorsque vous configurez votre application pour prendre en charge les packs de ressources pour différents niveaux de fonctionnalités DirectX, vous devez :

• Créez un sous-répertoire d’application (ou version de fichier) pour chaque niveau de fonctionnalité DirectX que vous prendrez en charge (dxfl-dx9, dxfl-dx10 et dxfl-dx11).

• Pendant le développement, placez des ressources spécifiques au niveau des fonctionnalités dans chaque répertoire de ressources au niveau de la fonctionnalité. Contrairement aux paramètres régionaux et aux facteurs de mise à l’échelle, vous pouvez avoir des branches de code de rendu différentes pour chaque niveau de fonctionnalité de votre jeu, et si vous avez des textures, des nuanceurs compilés ou d’autres ressources utilisées uniquement dans un ou un sous-ensemble de tous les niveaux de fonctionnalités pris en charge, placez les ressources correspondantes uniquement dans les répertoires pour les niveaux de fonctionnalités qui les utilisent. Pour les ressources chargées sur tous les niveaux de fonctionnalités, assurez-vous que chaque répertoire de ressources de niveau fonctionnalité a une version de celle-ci portant le même nom. Par exemple, pour une texture indépendante au niveau de la fonctionnalité nommée « coolsign.dds », placez la version compressée BC3 dans le répertoire \dxfl-dx9 et la version BC7 compressée dans le répertoire \dxfl-dx11.

• Assurez-vous que chaque ressource (s’il est disponible pour plusieurs niveaux de fonctionnalités) porte le même nom dans chaque répertoire. Par exemple, coolsign.dds doit avoir le même nom dans les répertoires \dxfl-dx9 et \dxfl-dx11, même si le contenu du fichier est différent. Dans ce cas, vous les voyez sous la forme \dxfl-dx9\coolsign.dds et \dxfl-dx11\coolsign.dds.

  Notez à nouveau que vous pouvez ajouter le suffixe de niveau de fonctionnalité au nom de fichier et les stocker dans le même répertoire ; par exemple, \textures\coolsign_dxfl-dx9.dds, \textures\coolsign_dxfl-dx11.dds.

   

• Déclarez les niveaux de fonctionnalités DirectX pris en charge lors de la configuration de vos ressources graphiques.

  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.
  );
  

• Utilisez les API dans Windows.ApplicationModel.Resources.Core pour charger les ressources. Les références de ressources doivent être généralisées (sans suffixe), en laissant le niveau de fonctionnalité. Toutefois, contrairement à la langue et à la mise à l’échelle, le système ne détermine pas automatiquement le niveau de fonctionnalité optimal pour un affichage donné ; qui est laissé à vous pour déterminer en fonction de la logique de code. Une fois cette détermination effectuée, utilisez les API pour informer le système d’exploitation du niveau de fonctionnalité préféré. Le système pourra ensuite récupérer la ressource appropriée en fonction de cette préférence. Voici un exemple de code qui montre comment informer votre application du niveau de fonctionnalité DirectX actuel pour la plateforme :

  // 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);
  

• Utilisez maintenant ResourceManager pour localiser le fichier qui correspond au niveau de fonctionnalité DirectX actuel. ResourceManager retourne un ResourceMap, que vous interrogez avec ResourceMap ::GetValue (ou ResourceMap ::TryGetValue) et un ResourceContext fourni. Cela retourne une RessourceCandidate qui correspond le plus étroitement au niveau de fonctionnalité DirectX spécifié en appelant 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;
  

• Dans Visual Studio 2015, sélectionnez PROJECT-Store-Create>> App Package... et créez le package.

• Veillez à activer les bundles d’applications dans les paramètres du manifeste package.appxmanifest.

Rubriques connexes

• Définition des ressources d’application
• Empaquetage d’applications
• Outil de création de package d’application (MakeAppx.exe)