Verpacken Ihres DirectX-Spiels für die Universal Windows-Plattform (UWP)

Größere Spiele für die universelle Windows-Plattform (UWP), insbesondere solche, die mehrere Sprachen mit regionsspezifischen Assets unterstützen oder optionale High-Definition-Assets umfassen, können leicht übermäßig groß werden. In diesem Thema erfahren Sie, wie Sie App-Pakete und App-Bündel verwenden, um Ihre App so anzupassen, dass Ihre Kunden nur die benötigten Ressourcen erhalten.

Zusätzlich zum App-Paketmodell unterstützt Windows 10 App-Bündel, die zwei Arten von Paketen gruppieren:

• App-Pakete enthalten plattformspezifische ausführbare Dateien und Bibliotheken. In der Regel kann ein UWP-Spiel bis zu drei App-Pakete enthalten: eines für die x86-, x64- und Arm-CPU-Architekturen. Alle Code und Daten, die für diese Hardwareplattform spezifisch sind, müssen in das App-Paket aufgenommen werden. Ein App-Paket sollte auch alle Kernressourcen für das Spiel enthalten, die mit einer grundlegenden Genauigkeit und Leistung ausgeführt werden können.
• Ressourcenpakete enthalten optionale oder erweiterte plattformunabhängige Daten, z. B. Spielressourcen (Texturen, Gitter, Sound, Text). Ein UWP-Spiel kann über ein oder mehrere Ressourcenpakete verfügen, einschließlich Paketen für hochauflösende Assets oder Texturen, Ressourcen für DirectX-Feature-Level 11+ oder sprachspezifische Ressourcen.

Weitere Informationen zu App-Bündeln und App-Paketen finden Sie unter Definieren von App-Ressourcen.

Sie können zwar alle Inhalte in Ihren App-Paketen platzieren, dies ist jedoch ineffizient und redundant. Warum wurde die gleiche große Texturdatei dreimal für jede Plattform repliziert, insbesondere für Arm-Plattformen, die sie möglicherweise nicht verwenden? Ein gutes Ziel ist es, zu versuchen, die Downloads Ihres Kunden zu minimieren, sodass er schneller mit dem Spielen seines Spiels beginnen kann, Platz auf seinem Gerät spart und mögliche Kosten für getaktete Bandbreite vermieden werden.

Um dieses Feature des UWP-App-Installers zu verwenden, ist es wichtig, die Verzeichnisstruktur und Dateibenennungskonventionen für die App- und Ressourcenverpackung frühzeitig bei der Spieleentwicklung zu berücksichtigen. So können Ihre Tools und Ihr Quellcode diese korrekt ausgeben, was das Verpacken erleichtert. Befolgen Sie die in diesem Dokument beschriebenen Regeln beim Entwickeln oder Konfigurieren von Tools und Skripten zur Erstellung und Verwaltung von Ressourcen sowie beim Programmieren von Code, der auf Ressourcen zugreift oder diese referenziert.

Warum Ressourcenpakete erstellen?

Wenn Sie eine App erstellen, insbesondere eine Spiele-App, die in vielen Gebietsschemas oder einer Vielzahl von UWP-Hardwareplattformen verkauft werden kann, müssen Sie häufig mehrere Versionen vieler Dateien einschließen, um diese Gebietsschemas oder Plattformen zu unterstützen. Wenn Sie beispielsweise Ihr Spiel in den USA und Japan veröffentlichen, benötigen Sie möglicherweise eine Reihe von Sprachdateien auf Englisch für das en-us-Gebietsschema und eine andere auf Japanisch für das jp-jp-Gebietsschema. Wenn Sie ein Bild in Ihrem Spiel sowohl für Arm-Geräte als auch für x86- und x64-Plattformen verwenden möchten, müssen Sie die gleiche Bildressource insgesamt dreimal hochladen, jeweils einmal für jede CPU-Architektur.

Sollten Sie diese in das Basispaket aufnehmen und verlangen, dass Ihr Benutzer eine große Anzahl von Komponenten herunterlädt, die auf dem Gerät nicht nutzbar sind, auch wenn Ihr Spiel viele High-Definition-Ressourcen aufweist, die auf Plattformen mit niedrigeren DirectX-Featureebenen nicht anwendbar sind? Das Trennen dieser hochauflösenden Ressourcen in ein optionales Ressourcenpaket bedeutet, dass Kunden mit Geräten, die diese hochauflösenden Ressourcen unterstützen, sie zu den Kosten (möglicherweise getaktetes) Bandbreite abrufen können, während diejenigen, die keine höherwertigen Geräte haben, ihr Spiel schneller und mit geringerer Netzwerknutzung erhalten können.

Inhaltskandidaten für Spielressourcenpakete umfassen:

• Internationale ländertypische Ressourcen (lokalisierter Text, Audio oder Bildmaterial)
• Ressourcen mit hoher Auflösung für unterschiedliche Geräteskalierungsfaktoren (1,0x, 1,4x und 1,8x)
• High Definition-Ressourcen für höhere DirectX-Featureebenen (9, 10 und 11)

All dies wird in der Datei "package.appxmanifest" definiert, die Teil Ihres UWP-Projekts ist, und in der Verzeichnisstruktur des endgültigen Pakets. Aufgrund der neuen Visual Studio-Benutzeroberfläche sollten Sie sie nicht manuell bearbeiten müssen, wenn Sie dem Prozess in diesem Dokument folgen.

Wichtig Das Laden und Verwalten dieser Ressourcen wird über die Windows.ApplicationModel.Resources* APIs behandelt. Wenn Sie diese App-Modellressourcen-APIs verwenden, um die richtige Datei für ein Gebietsschema, einen Skalierungsfaktor oder eine DirectX-Featureebene zu laden, müssen Sie Ihre Ressourcen nicht mit expliziten Dateipfaden laden. Stattdessen stellen Sie die Ressourcen-APIs nur den generalisierten Dateinamen des gewünschten Ressourcenobjekts bereit, und lassen Sie das Ressourcenverwaltungssystem die richtige Variante der Ressource für die aktuelle Plattform- und Gebietsschemakonfiguration des Benutzers abrufen (die Sie auch direkt mit diesen APIs angeben können).

Ressourcen für die Ressourcenverpackung werden auf eine von zwei grundlegenden Arten angegeben:

• Objektdateien haben denselben Dateinamen, und die spezifischen Versionen des Ressourcenpakets werden in bestimmten benannten Verzeichnissen platziert. Diese Verzeichnisnamen werden vom System reserviert. Beispiel: \en-us, \scale-140, \dxfl-dx11.
• Objektdateien werden in Ordnern mit beliebigen Namen gespeichert, aber die Dateien werden mit einer einheitlichen Bezeichnung benannt, die durch das Anhängen von Zeichenfolgen gebildet wird, die dazu vom System reserviert sind, um Sprache oder andere Einschränkungen zu kennzeichnen. Insbesondere werden die Qualifizierungszeichenfolgen nach einem Unterstrich ("_") an den allgemeinen Dateinamen angefügt. Beispiel: \assets\menu_option1_lang-en-us.png, \assets\menu_option1_scale-140.png, \assets\coolsign_dxfl-dx11.dds. Sie können diese Zeichenfolgen auch kombinieren. Beispiel: \assets\menu_option1_scale-140_lang-en-us.png.

  Hinweis Wenn sie in einem Dateinamen und nicht allein in einem Verzeichnisnamen verwendet wird, muss ein Sprachqualifizierer das Format "lang-<Tag>" haben, z. B. "lang-en-us", wie in Anpassen Ihrer Ressourcen für Sprache, Skalierung und andere Qualifiziererbeschrieben.

Verzeichnisnamen können für zusätzliche Genauigkeit bei der Paketierung von Ressourcen kombiniert werden. Sie können jedoch nicht redundant sein. Beispielsweise ist \en-us\menu_option1_lang-en-us.png redundant.

Sie können alle nicht reservierten Unterverzeichnisnamen angeben, die Sie unter einem Ressourcenverzeichnis benötigen, solange die Verzeichnisstruktur in jedem Ressourcenverzeichnis identisch ist. Beispiel: \dxfl-dx10\assets\textures\coolsign.dds. Wenn Sie eine Ressource laden oder referenzieren, muss der Pfadname generalisiert werden, wobei alle Qualifizierer für Sprache, Skalierung oder DirectX-Featureebene entfernt werden müssen, unabhängig davon, ob sie sich in Ordnerknoten oder in den Dateinamen befinden. Wenn Sie beispielsweise im Code auf eine Ressource verweisen möchten, für die eine der Varianten "\dxfl-dx10\assets\textures\coolsign.dds" lautet, verwenden Sie \assets\textures\coolsign.dds. Ebenso, um auf einen Vermögenswert mit einer Variante \images\background_scale-140.png, use \images\background.pngzu verweisen.

Folgende reservierte Verzeichnisnamen und Präfixe mit Unterstrich bei Dateinamen:

Definieren lokalisierter Sprachressourcenpakete

Dateien für bestimmte Sprachen werden in Projektverzeichnissen abgelegt, die nach der Sprache benannt sind (z. B. "en").

Wenn Sie Ihre App so konfigurieren, dass lokalisierte Ressourcen für mehrere Sprachen unterstützt werden, sollten Sie:

• Erstellen Sie ein App-Unterverzeichnis (oder Dateiversion) für jede Sprache und jedes Gebietsschema, das Sie unterstützen (z. B. en-us, jp-jp, zh-cn, fr-frund so weiter).

• Platzieren Sie während der Entwicklung Kopien aller Ressourcen (z. B. lokalisierte Audiodateien, Texturen und Menügrafiken) im Unterverzeichnis für das entsprechende Locale, selbst wenn sie in verschiedenen Sprachen oder Lokalitäten nicht unterschiedlich sind. Um eine optimale Benutzererfahrung zu erzielen, stellen Sie sicher, dass der Benutzer benachrichtigt wird, wenn er kein verfügbares Sprachressourcenpaket für sein Gebietsschema erhalten hat, wenn es verfügbar ist (oder wenn er ihn nach dem Herunterladen und installieren versehentlich gelöscht hat).

• Stellen Sie sicher, dass jede Asset- oder Zeichenfolgenressourcendatei (.resw) in jedem Verzeichnis denselben Namen hat. Beispielsweise sollte menu_option1.png in den Verzeichnissen \en-us und \jp-jp denselben Namen haben, auch wenn der Inhalt der Datei für eine andere Sprache gilt. In diesem Fall werden sie als \en-us\menu_option1.png and \jp-jp\menu_option1.pngangezeigt.

  Hinweis Sie können optional das Gebietsschema an den Dateinamen anfügen und im selben Verzeichnis speichern; Beispiel: \assets\menu_option1_lang-en-us.png, \assets\menu_option1_lang-jp-jp.png.

   

• Verwenden Sie die APIs in Windows.ApplicationModel.Resources und Windows.ApplicationModel.Resources.Core, um die lokalitätsspezifischen Ressourcen für Ihre App anzugeben und zu laden. Verwenden Sie außerdem Objektverweise, die kein bestimmtes Gebietsschema enthalten, da diese APIs das richtige Gebietsschema basierend auf den Einstellungen des Benutzers bestimmen und dann die richtige Ressource für den Benutzer abrufen.

• Wählen Sie in Microsoft Visual Studio 2015 PROJECT->Store->App-Paket erstellen... aus, und erstellen Sie das Paket.

Definieren von Skalierungsfaktoren-Ressourcenpaketen

Windows 10 bietet drei Skalierungsfaktoren für die Benutzeroberfläche: 1,0x, 1,4x und 1,8x. Skalierungswerte für jede Anzeige werden während der Installation basierend auf einer Reihe kombinierter Faktoren festgelegt: die Größe des Bildschirms, die Auflösung des Bildschirms und die angenommene durchschnittliche Entfernung des Benutzers vom Bildschirm. Der Benutzer kann auch Skalierungsfaktoren anpassen, um die Lesbarkeit zu verbessern. Ihr Spiel sollte sowohl DPI-bewusst als auch skalierungsfaktorbewusst sein, um die bestmögliche Erfahrung zu erzielen. Ein Teil dieses Bewusstseins bedeutet, Versionen kritischer visueller Ressourcen für jeden der drei Skalierungsfaktoren zu erstellen. Dazu gehören auch Zeigerinteraktionen und Treffertests!

Wenn Sie Ihre App so konfigurieren, dass Ressourcenpakete für unterschiedliche Skalierungsfaktoren für UWP-Apps unterstützt werden, sollten Sie:

• Erstellen Sie ein App-Unterverzeichnis (oder dateiversion) für jeden Skalierungsfaktor, den Sie unterstützen (Scale-100, Scale-140 und Scale-180).

• Platzieren Sie während der Entwicklung für jeden Skalierungsfaktor passende Kopien ALLER Assets in jedem Ressourcenverzeichnis für Skalierungsfaktoren, auch wenn sie sich nicht über die Skalierungsfaktoren hinweg unterscheiden.

• Stellen Sie sicher, dass jedes Objekt in jedem Verzeichnis denselben Namen hat. Beispielsweise sollte menu_option1.png in den Verzeichnissen \scale-100 und \scale-180 denselben Namen haben, auch wenn der Inhalt der Datei unterschiedlich ist. In diesem Fall würden Sie sie als \scale-100\menu_option1.png and \scale-140\menu_option1.pngsehen.

  Note Sie können erneut optional das Skalierungsfaktor-Suffix an den Dateinamen anhängen und im gleichen Verzeichnis speichern; beispielsweise: \assets\menu_option1_scale-100.png, \assets\menu_option1_scale-140.png.

   

• Verwenden Sie die APIs in Windows.ApplicationModel.Resources.Core, um die Ressourcen zu laden. Verweise auf Ressourcen sollten generalisiert werden (kein Suffix), und spezifische Skalierungsvariationen sollten weggelassen werden. Das System ruft die entsprechende Skalenressource für die Anzeige und die Benutzereinstellungen ab.

• Wählen Sie in Visual Studio 2015 PROJECT->Store->App-Paket erstellen... aus, und erstellen Sie das Paket.

Definieren von Ressourcenpaketen auf DirectX-Featureebene

DirectX-Featureebenen entsprechen GPU-Featuresätzen für frühere und aktuelle Versionen von DirectX (insbesondere Direct3D). Dazu gehören Shadermodellspezifikationen und -funktionen, Unterstützung der Shadersprache, Unterstützung der Texturkomprimierung und allgemeine Features der Grafikpipeline.

Ihr "Baseline"-App-Paket sollte die grundlegenden Texturkomprimierungsformate verwenden: BC1, BC2 oder BC3. Diese Formate können von jedem UWP-Gerät genutzt werden, von low-end-ARM-Plattformen bis hin zu spezialisierten Multi-GPU-Workstations und Mediencomputern.

Unterstützung für Texturformate auf DirectX-Featureebene 10 oder höher sollte in einem Ressourcenpaket hinzugefügt werden, um lokalen Speicherplatz und Download-Bandbreite zu sparen. Dies ermöglicht die Verwendung erweiterter Komprimierungsschemas für 11, z. B. BC6H und BC7. (Weitere Informationen finden Sie unter Texturblockkomprimierung in Direct3D 11.) Diese Formate sind effizienter für die hochauflösenden Texturressourcen, die von modernen GPUs unterstützt werden, und die Verwendung verbessert das Aussehen, die Leistung und die Platzanforderungen Ihres Spiels auf High-End-Plattformen.

Außerdem unterstützen jede DirectX-Featureebene unterschiedliche Shadermodellversionen. Kompilierte Shaderressourcen können auf der Ebene einzelner Funktionen erstellt werden und in DirectX-Ressourcenpaketen für die jeweilige Funktionsstufe enthalten sein. Darüber hinaus können einige neuere Shadermodelle Ressourcen wie normale Karten verwenden, die frühere Shadermodellversionen nicht verwenden können. Diese shadermodellspezifischen Ressourcen sollten auch in einem Ressourcenpaket auf DirectX-Featureebene enthalten sein.

Der Ressourcen-Mechanismus konzentriert sich in erster Linie auf Texturformate, die für Assets unterstützt werden, was bedeutet, dass nur die drei allgemeinen Funktionsstufen unterstützt werden. Wenn Sie separate Shader für Unterebenen (Punktversionen) wie DX9_1 vs DX9_3 haben müssen, müssen Sie die Ressourcenverwaltung und den Renderingcode explizit behandeln.

Wenn Sie Ihre App so konfigurieren, dass Ressourcenpakete für verschiedene DirectX-Featureebenen unterstützt werden, sollten Sie:

• Erstellen Sie ein App-Unterverzeichnis (oder eine Dateiversion) für jede DirectX-Featureebene, die Sie unterstützen (dxfl-dx9, dxfl-dx10 und dxfl-dx11).

• Platzieren Sie während der Entwicklung spezifische Ressourcen auf Funktionsebene in jedem Ressourcenverzeichnis auf Funktionsebene. Im Gegensatz zu Ländereinstellungen und Skalierungsfaktoren verfügen Sie möglicherweise über unterschiedliche Rendering-Codepfade für jede Funktionenebene in Ihrem Spiel. Wenn Sie Texturen, kompilierte Shader oder andere Ressourcen haben, die nur in einer oder einer Teilmenge aller unterstützten Funktionenebenen verwendet werden, platzieren Sie die entsprechenden Ressourcen nur in den Verzeichnissen der Funktionenebenen, die diese verwenden. Stellen Sie bei Ressourcen, die über alle Featureebenen geladen werden, sicher, dass jedes Ressourcenverzeichnis auf Featureebene über eine Version mit demselben Namen verfügt. Platzieren Sie z. B. für eine unabhängige Textur auf Featureebene mit dem Namen "coolsign.dds" die BC3-komprimierte Version im Verzeichnis \dxfl-dx9 und die BC7-komprimierte Version im Verzeichnis \dxfl-dx11.

• Stellen Sie sicher, dass jedes Objekt (sofern es für mehrere Featureebenen verfügbar ist) in jedem Verzeichnis denselben Namen hat. Beispielsweise sollte coolsign.dds in den Verzeichnissen \dxfl-dx9 und \dxfl-dx11 denselben Namen haben, auch wenn sich der Inhalt der Datei unterscheidet. In diesem Fall werden sie als \dxfl-dx9\coolsign.dds und \dxfl-dx11\coolsign.dds angezeigt.

  Hinweis Erneut können Sie optional das Feature-Level-Suffix zum Dateinamen hinzufügen und sie im gleichen Verzeichnis speichern; Beispiel: \textures\coolsign_dxfl-dx9.dds, \textures\coolsign_dxfl-dx11.dds.

   

• Deklarieren Sie die unterstützten DirectX-Featureebenen, wenn Sie Ihre Grafikressourcen konfigurieren.

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

• Verwenden Sie die APIs in Windows.ApplicationModel.Resources.Core, um die Ressourcen zu laden. Objektverweise sollten generalisiert werden (kein Suffix), wobei die Featureebene weggelassen wird. Im Gegensatz zu Sprache und Skalierung bestimmt das System jedoch nicht automatisch, welche Featureebene für eine bestimmte Anzeige optimal ist; das liegt bei Ihnen, dies anhand der Codelogik zu bestimmen. Nachdem Sie diese Entscheidung getroffen haben, verwenden Sie die APIs, um das Betriebssystem über die bevorzugte Funktionsebene zu informieren. Das System kann dann die richtige Ressource basierend auf dieser Präferenz abrufen. Hier ist ein Codebeispiel, das zeigt, wie Sie Ihre App über die aktuelle DirectX-Featureebene für die Plattform informieren:

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

• Verwenden Sie nun die ResourceManager-, um die Datei zu finden, die dem aktuellen DirectX-Feature-Level entspricht. Die ResourceManager- gibt eine ResourceMap-zurück, die Sie mit ResourceMap::GetValue (oder ResourceMap::TryGetValue) und einem angegebenen ResourceContext-abfragen. Dadurch wird eine ResourceCandidate- zurückgegeben, die am ehesten der angegebenen DirectX-Featureebene entspricht, indem SetGlobalQualifierValueaufgerufen wurde.

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

• Wählen Sie in Visual Studio 2015 PROJECT->Store->App-Paket erstellen... aus, und erstellen Sie das Paket.

• Stellen Sie sicher, dass Sie App-Bundles in den „package.appxmanifest“-Manifest-Einstellungen aktivieren.

Zugehörige Themen

• Definieren von App-Ressourcen
• Verpacken von Apps
• App-Packager (MakeAppx.exe)