Packen Ihres Universelle Windows-Plattform (UWP)-DirectX-Spiels
Größere Universelle Windows-Plattform (UWP)-Spiele, insbesondere solche, die mehrere Sprachen mit regionsspezifischen Ressourcen unterstützen oder optionale High-Definition-Ressourcen enthalten, können problemlos in große Größen sprechblasen. 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 Ressourcenpakete für Hd-Ressourcen oder Texturen, DirectX-Featureebene 11+ oder sprachspezifische Ressourcen und 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, zu minimieren, was Der Kunde herunterladen muss, damit er schneller mit dem Spielen ihres Spiels beginnen kann, Platz auf dem Gerät sparen und mögliche Kosten für getaktete Bandbreite vermeiden.
Um dieses Feature des UWP-App-Installers zu verwenden, ist es wichtig, die Verzeichnislayout- und Dateibenennungskonventionen für App- und Ressourcenverpackungen frühzeitig bei der Spieleentwicklung zu berücksichtigen, sodass Ihre Tools und Quellen diese ordnungsgemäß ausgeben können, sodass das Verpacken einfach ist. Befolgen Sie die in diesem Dokument beschriebenen Regeln beim Entwickeln oder Konfigurieren der Erstellung von Ressourcen sowie beim Verwalten von Tools und Skripts sowie beim Erstellen von Code, der Ressourcen lädt oder verweist.
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 sowohl in der USA als auch in Japan veröffentlichen, benötigen Sie möglicherweise eine Gruppe von Sprachdateien in Englisch für die Gebietsschemas "en-us" und eine andere in Japanisch für das Gebietsschema "jp-jp". Wenn Sie ein Bild in Ihrem Spiel für Arm-Geräte sowie x86- und x64-Plattformen verwenden möchten, müssen Sie die gleiche Bildressource 3 Mal für jede CPU-Architektur hochladen.
Wenn Ihr Spiel viele High-Definition-Ressourcen aufweist, die nicht auf Plattformen mit niedrigeren DirectX-Featureebenen angewendet werden, sollten Sie diese in das basisplane App-Paket einschließen und den Benutzer auf eine große Anzahl von Komponenten herunterladen, die das Gerät nicht verwenden kann? Das Trennen dieser Ressourcen mit hoher Verzögerung in ein optionales Ressourcenpaket bedeutet, dass Kunden mit Geräten, die diese Hochverzögerungsressourcen unterstützen, diese zu Kosten für die (möglicherweise getaktete) Bandbreite abrufen können, während diejenigen, die keine Höheren-End-Geräte haben, ihr Spiel schneller und zu geringeren Netzwerknutzungskosten erhalten können.
Inhaltskandidaten für Spielressourcenpakete umfassen:
- Internationale gebietsschemaspezifische Ressourcen (lokalisierter Text, Audio oder Bilder)
- 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 verarbeitet. 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 allgemeinen Bezeichnung benannt, die mit Zeichenfolgen angefügt wird, die vom System reserviert sind, um sprache oder andere Qualifizierer zu kennzeichnen. Insbesondere werden die Qualifiziererzeichenfolgen nach einem Unterstrich ("_") an den generalisierten 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 unter "Anpassen Ihrer Ressourcen für Sprache, Skalierung und andere Qualifizierer" beschrieben.
Verzeichnisnamen können für zusätzliche Spezifität in der Ressourcenverpackung 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. Um auf eine Ressource mit einer Variante \images\background_scale-140.png zu verweisen, verwenden Sie \images\background.png.
Hier sind die folgenden reservierten Verzeichnisnamen und Dateinamen unterstrichene Präfixe:
| Anlagentyp | Verzeichnisname des Ressourcenpakets | Dateinamensuffix des Ressourcenpakets |
|---|---|---|
| Lokalisierte Ressourcen | Alle möglichen Sprachen oder Sprach- und Gebietsschemakombinationen für Windows 10. (Das Qualifiziererpräfix "lang-" ist in einem Ordnernamen nicht erforderlich.) | Ein "_" gefolgt von der Sprache, dem Gebietsschema oder dem Sprachgebietsschemabezeichner. Beispiel: "_en", "_us" oder "_en-us". |
| Skalierungsfaktorressourcen | scale-100, scale-140, scale-180. Dies sind die Skalierungsfaktoren 1,0x, 1,4x und 1,8x. | Ein "_" gefolgt von "scale-100", "scale-140" oder "scale-180". |
| Ressourcen auf DirectX-Featureebene | dxfl-dx9, dxfl-dx10 und dxfl-dx11. Dies gilt für die Featureebenen DirectX 9, 10 und 11. | Ein "_" gefolgt von "dxfl-dx9", "dxfl-dx10" oder "dxfl-dx11". |
Definieren lokalisierter Sprachressourcenpakete
Gebietsschemaspezifische Dateien werden in Projektverzeichnissen platziert, die für die 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-fr" usw.).
Platzieren Sie während der Entwicklung Kopien aller Ressourcen (z. B. lokalisierte Audiodateien, Texturen und Menügrafiken) im unterverzeichnis für das entsprechende Sprachgebietsschema, auch wenn sie sich nicht in verschiedenen Sprachen oder Gebietsschemas unterscheiden. 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 Ressourcen- 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" und "\jp-jp\menu_option1.png" angezeigt.
Hinweis : Sie können das Gebietsschema optional an den Dateinamen anfügen und im selben Verzeichnis speichern, z. B. \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 gebietsschemaspezifischen 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-Create>> App Package... aus, und erstellen Sie das Paket.
Definieren von Ressourcenpaketen für Skalierungsfaktor
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-fähig als auch skalierungsfaktorfähig 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 skalierungsbezogene Kopien aller Ressourcen in jedem Skalierungsfaktorressourcenverzeichnis, auch wenn sie nicht über Skalierungsfaktoren hinweg unterschiedlich sind.
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 werden sie als \scale-100\menu_option1.png und \scale-140\menu_option1.png angezeigt.
Hinweis : Sie können optional das Skalierungsfaktorsuffix an den Dateinamen anfügen und sie im selben Verzeichnis speichern, z. B. \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. Objektverweise sollten generalisiert werden (kein Suffix), wobei die spezifische Skalierungsvariation ausgelassen wird. Das System ruft die entsprechende Skalierungsressource für die Anzeige und die Einstellungen des Benutzers ab.
Wählen Sie in Visual Studio 2015 PROJECT-Store-Create>> App Package... 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 geplantes 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 dedizierten Multi-GPU-Arbeitsstationen und Mediencomputern.
Texturformatunterstützung auf DirectX-Featureebene 10 oder höher sollte in einem Ressourcenpaket hinzugefügt werden, um lokalen Speicherplatz zu sparen und Bandbreite herunterzuladen. Dies ermöglicht die Verwendung erweiterter Komprimierungsschemas für 11, z. B. BC6H und BC7. (Weitere Details 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.
| DirectX-Featureebene | Unterstützte Texturkomprimierung |
|---|---|
| 9 | BC1, BC2, BC3 |
| 10 | BC4, BC5 |
| 11 | BC6H, BC7 |
Außerdem unterstützen jede DirectX-Featureebene unterschiedliche Shadermodellversionen. Kompilierte Shaderressourcen können auf Featureebene erstellt werden und können in Ressourcenpakete auf DirectX-Featureebene eingeschlossen werden. 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 Ressourcenmechanismus konzentriert sich in erster Linie auf Texturformate, die für Ressourcen unterstützt werden, sodass nur die drei allgemeinen Featureebenen 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 bestimmte Ressourcen auf Featureebene in jedem Ressourcenverzeichnis auf Featureebene. Im Gegensatz zu Gebietsschemas und Skalierungsfaktoren verfügen Sie möglicherweise über unterschiedliche Renderingcode-Verzweigungen für jede Featureebene in Ihrem Spiel, und wenn Sie Texturen, kompilierte Shader oder andere Ressourcen haben, die nur in einer oder einer Teilmenge aller unterstützten Featureebenen verwendet werden, platzieren Sie die entsprechenden Ressourcen nur in den Verzeichnissen für die Featureebenen, 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 : Sie können optional das Suffix der Featureebene an den Dateinamen anfügen und im selben Verzeichnis speichern, z. B. \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 bleibt Ihnen überlassen, um basierend auf der Codelogik zu bestimmen. Nachdem Sie diese Bestimmung vorgenommen haben, verwenden Sie die APIs, um das Betriebssystem über die bevorzugte Featureebene zu informieren. Das System kann dann die richtige Ressource basierend auf dieser Einstellung 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);
Hinweis
Laden Sie die Textur in Ihrem Code direkt nach Namen (oder Pfad unterhalb des Featureebenenverzeichnisses). Schließen Sie weder den Namen des Featureebenenverzeichnisses noch das Suffix ein. Laden Sie beispielsweise "Texturen\coolsign.dds", nicht "dxfl-dx11\textures\coolsign.dds" oder "textures\coolsign_dxfl-dx11.dds".
Verwenden Sie nun den ResourceManager , um die Datei zu suchen, die der aktuellen DirectX-Featureebene entspricht. Der ResourceManager gibt eine ResourceMap zurück, die Sie mit ResourceMap::GetValue (oder ResourceMap::TryGetValue) und einem bereitgestellten ResourceContext abfragen. Dadurch wird ein ResourceCandidate zurückgegeben, das am ehesten mit der DirectX-Featureebene übereinstimmt, die durch Aufrufen von SetGlobalQualifierValue angegeben 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-Create>> App Package... aus, und erstellen Sie das Paket.
Stellen Sie sicher, dass Sie App-Bündel in den Manifesteinstellungen "package.appxmanifest" aktivieren.
Zugehörige Themen