Creare un pacchetto del gioco DirectX per la piattaforma UWP (Universal Windows Platform)

Giochi di piattaforma UWP (Universal Windows Platform) (UWP) più grandi, in particolare quelli che supportano più lingue con asset specifici dell'area o funzionalità facoltativi asset ad alta definizione, possono facilmente passare a grandi dimensioni. In questo argomento si apprenderà come usare pacchetti di app e bundle di app per personalizzare l'app in modo che i clienti ricevano solo le risorse di cui hanno effettivamente bisogno.

Oltre al modello di pacchetto dell'app, Windows 10 supporta bundle di app che raggruppano due tipi di pacchetti:

• I pacchetti di app contengono file eseguibili e librerie specifici della piattaforma. In genere, un gioco UWP può avere fino a tre pacchetti di app: uno per le architetture cpu x86, x64 e Arm. Tutto il codice e i dati specifici della piattaforma hardware devono essere inclusi nel pacchetto dell'app. Un pacchetto di app deve contenere anche tutti gli asset principali per l'esecuzione del gioco con un livello di fedeltà e prestazioni di base.
• I pacchetti di risorse contengono dati facoltativi o espansi indipendenti dalla piattaforma, ad esempio asset di gioco (trame, mesh, suono, testo). Un gioco UWP può avere uno o più pacchetti di risorse, inclusi i pacchetti di risorse per asset o trame ad alta definizione, risorse e risorse specifiche del linguaggio.

Per altre informazioni sui bundle di app e sui pacchetti di app, vedere Definizione delle risorse dell'app.

Anche se è possibile inserire tutto il contenuto nei pacchetti di app, questo è inefficiente e ridondante. Perché lo stesso file di trama di grandi dimensioni è stato replicato tre volte per ogni piattaforma, soprattutto per le piattaforme Arm che potrebbero non usarlo? Un buon obiettivo è quello di cercare di ridurre al minimo ciò che il cliente deve scaricare, in modo che possano iniziare a giocare prima, risparmiare spazio sul dispositivo ed evitare possibili costi di larghezza di banda a consumo.

Per usare questa funzionalità del programma di installazione dell'app UWP, è importante prendere in considerazione le convenzioni di layout della directory e di denominazione dei file per l'app e la creazione di pacchetti di risorse all'inizio dello sviluppo di giochi, in modo che gli strumenti e l'origine possano restituirli correttamente in modo da semplificare la creazione dei pacchetti. Seguire le regole descritte in questo documento durante lo sviluppo o la configurazione della creazione di asset e la gestione di strumenti e script e durante la creazione di codice che carica o fa riferimento alle risorse.

Perché creare pacchetti di risorse?

Quando crei un'app, in particolare un'app di gioco che può essere venduta in molte impostazioni locali o in un'ampia gamma di piattaforme hardware UWP, spesso devi includere più versioni di molti file per supportare tali impostazioni locali o piattaforme. Ad esempio, se stai rilasciando il tuo gioco sia in Stati Uniti che in Giappone, potresti aver bisogno di un set di file vocali in inglese per le impostazioni locali en-us e un altro in giapponese per le impostazioni locali jp-jp. In alternativa, se vuoi usare un'immagine nel tuo gioco per i dispositivi Arm e le piattaforme x86 e x64, devi caricare lo stesso asset immagine 3 volte, una volta per ogni architettura della CPU.

Inoltre, se il gioco ha molte risorse ad alta definizione che non si applicano alle piattaforme con livelli di funzionalità DirectX inferiori, perché includerli nel pacchetto di app di base e richiedere all'utente di scaricare un volume elevato di componenti che il dispositivo non può usare? La separazione di queste risorse high-def in un pacchetto di risorse facoltativo significa che i clienti con dispositivi che supportano tali risorse high-def possono ottenerle al costo della larghezza di banda (possibilmente a consumo), mentre quelli che non dispongono di dispositivi di fascia superiore possono ottenere il loro gioco più rapidamente e a un costo di utilizzo della rete inferiore.

I candidati al contenuto per i pacchetti di risorse di gioco includono:

• Asset specifici delle impostazioni locali internazionali (testo localizzato, audio o immagini)
• Asset ad alta risoluzione per diversi fattori di ridimensionamento dei dispositivi (1,0x, 1,4x e 1,8x)
• Asset ad alta definizione per livelli di funzionalità DirectX più elevati (9, 10 e 11)

Tutto questo è definito nel package.appxmanifest che fa parte del progetto UWP e nella struttura di directory del pacchetto finale. A causa della nuova interfaccia utente di Visual Studio, se si segue il processo in questo documento, non è necessario modificarlo manualmente.

Importante Il caricamento e la gestione di queste risorse vengono gestiti tramite le API Windows.ApplicationModel.Resources*. Se si usano queste API di risorse del modello di app per caricare il file corretto per impostazioni locali, fattore di ridimensionamento o livello di funzionalità DirectX, non è necessario caricare gli asset usando percorsi di file espliciti; è invece possibile fornire alle API delle risorse solo il nome file generalizzato dell'asset desiderato e consentire al sistema di gestione delle risorse di ottenere la variante corretta della risorsa per la configurazione delle impostazioni locali e della piattaforma corrente dell'utente, che è possibile specificare direttamente con queste stesse API.

Le risorse per la creazione di pacchetti di risorse vengono specificate in uno dei due modi di base seguenti:

• I file di asset hanno lo stesso nome file e le versioni specifiche del pacchetto di risorse vengono inserite in directory denominate specifiche. Questi nomi di directory sono riservati dal sistema. Ad esempio, \en-us, \scale-140, \dxfl-dx11.
• I file di asset vengono archiviati in cartelle con nomi arbitrari, ma i file vengono denominati con un'etichetta comune aggiunta con stringhe riservate dal sistema per indicare la lingua o altri qualificatori. In particolare, le stringhe di qualificatore vengono affisse al nome file generalizzato dopo un carattere di sottolineatura ("_"). Ad esempio, \assets\menu_option1_lang-en-us.png, \assets\menu_option1_scale-140.png, \assets\coolsign_dxfl-dx11.dds. È anche possibile combinare queste stringhe. Ad esempio, \assets\menu_option1_scale-140_lang-en-us.png.

  Nota Quando viene usato in un nome file anziché in un nome di directory, un qualificatore di lingua deve avere il formato "lang-tag<>", ad esempio "lang-en-us", come descritto in Adattare le risorse per linguaggio, scalabilità e altri qualificatori.

I nomi delle directory possono essere combinati per una maggiore specificità nella creazione di pacchetti di risorse. Tuttavia, non possono essere ridondanti. Ad esempio, \en-us\menu_option1_lang-en-us.png è ridondante.

È possibile specificare qualsiasi nome di sottodirectory non riservato necessario sotto una directory di risorse, purché la struttura di directory sia identica in ogni directory di risorse. Ad esempio, \dxfl-dx10\assets\textures\coolsign.dds. Quando si carica o si fa riferimento a un asset, è necessario generalizzare il percorso, rimuovendo tutti i qualificatori per il livello di funzionalità language, scale o DirectX, indipendentemente dal fatto che si trovino in nodi di cartella o nei nomi di file. Ad esempio, per fare riferimento al codice a un asset per il quale una delle varianti è \dxfl-dx10\assets\textures\coolsign.dds, usare \assets\textures\coolsign.dds. Analogamente, per fare riferimento a un asset con una variante \images\background_scale-140.png, usare \images\background.png.

Ecco i seguenti nomi di directory riservate e prefissi di sottolineatura del nome file:

Definizione di Language Resource Pack localizzati

I file specifici delle impostazioni locali vengono inseriti nelle directory di progetto denominate per la lingua ,ad esempio "en".

Quando si configura l'app per supportare asset localizzati per più lingue, è necessario:

• Creare una sottodirectory dell'app (o versione del file) per ogni lingua e impostazioni locali supportate (ad esempio en-us, jp-jp, zh-cn, fr-fr e così via).

• Durante lo sviluppo, posizionare copie di TUTTI gli asset (ad esempio file audio localizzati, trame e grafica di menu) nella sottodirectory delle impostazioni locali della lingua corrispondente, anche se non sono diverse tra lingue o impostazioni locali. Per un'esperienza utente ottimale, assicurarsi che l'utente venga avvisato se non ha ottenuto un Language Resource Pack disponibile per le impostazioni locali, se disponibile o se è stato eliminato accidentalmente dopo il download e l'installazione.

• Assicurarsi che ogni file di risorse asset o stringa (con estensione resw) abbia lo stesso nome in ogni directory. Ad esempio, menu_option1.png deve avere lo stesso nome nelle directory \en-us e \jp-jp anche se il contenuto del file è per una lingua diversa. In questo caso, verranno visualizzati come \en-us\menu_option1.png e \jp-jp\menu_option1.png.

  Nota È possibile aggiungere facoltativamente le impostazioni locali al nome del file e archiviarle nella stessa directory, ad esempio \assets\menu_option1_lang-en-us.png, \assets\menu_option1_lang-jp-jp.png.

   

• Usare le API in Windows.ApplicationModel.Resources e Windows.ApplicationModel.Resources.Core per specificare e caricare le risorse specifiche delle impostazioni locali per l'app. Usare anche i riferimenti agli asset che non includono le impostazioni locali specifiche, poiché queste API determinano le impostazioni locali corrette in base alle impostazioni dell'utente e quindi recuperano la risorsa corretta per l'utente.

• In Microsoft Visual Studio 2015 selezionare PROGETTO->Store->Crea pacchetto app... e creare il pacchetto.

Definizione dei pacchetti di risorse fattore di ridimensionamento

Windows 10 offre tre fattori di ridimensionamento dell'interfaccia utente: 1.0x, 1.4x e 1.8x. I valori di ridimensionamento per ogni visualizzazione vengono impostati durante l'installazione in base a diversi fattori combinati: le dimensioni dello schermo, la risoluzione dello schermo e la distanza media presunta dell'utente dallo schermo. L'utente può anche modificare i fattori di scala per migliorare la leggibilità. Il tuo gioco deve essere compatibile con DPI e con riconoscimento dei fattori di ridimensionamento per la migliore esperienza possibile. Parte di questa consapevolezza significa creare versioni di asset visivi critici per ognuno dei tre fattori di ridimensionamento. Questo include anche l'interazione del puntatore e l'hit testing.

Quando configuri la tua app per supportare i pacchetti di risorse per diversi fattori di ridimensionamento delle app UWP, devi:

• Creare una sottodirectory dell'app (o versione del file) per ogni fattore di ridimensionamento supportato (scale-100, scale-140 e scale-180).

• Durante lo sviluppo, posizionare copie appropriate del fattore di scala di TUTTI gli asset in ogni directory delle risorse del fattore di scala, anche se non sono diverse tra i fattori di ridimensionamento.

• Assicurarsi che ogni asset abbia lo stesso nome in ogni directory. Ad esempio, menu_option1.png deve avere lo stesso nome sia nelle directory \scale-100 che \scale-180 anche se il contenuto del file è diverso. In questo caso, verranno visualizzati come \scale-100\menu_option1.png e \scale-140\menu_option1.png.

  Nota Anche in questo caso, è possibile aggiungere il suffisso del fattore di ridimensionamento al nome del file e archiviarli nella stessa directory, ad esempio \assets\menu_option1_scale-100.png, \assets\menu_option1_scale-140.png.

   

• Usare le API in Windows.ApplicationModel.Resources.Core per caricare gli asset. I riferimenti agli asset devono essere generalizzati (senza suffisso), lasciando la variazione di scala specifica. Il sistema recupererà l'asset di scalabilità appropriato per la visualizzazione e le impostazioni dell'utente.

• In Visual Studio 2015 selezionare PROGETTO->Store->Crea pacchetto app... e creare il pacchetto.

Definizione di Pacchetti di risorse a livello di funzionalità DirectX

I livelli di funzionalità DirectX corrispondono ai set di funzionalità GPU per le versioni precedenti e correnti di DirectX (in particolare Direct3D). Sono incluse le specifiche e le funzionalità del modello shader, il supporto del linguaggio shader, il supporto della compressione delle trame e le funzionalità complessive della pipeline grafica.

Il pacchetto di app di base deve usare i formati di compressione delle trame di base: BC1, BC2 o BC3. Questi formati possono essere utilizzati da qualsiasi dispositivo UWP, dalle piattaforme Arm di fascia bassa fino alle workstation multi-GPU dedicate e ai computer multimediali.

Il supporto del formato trama a livello di funzionalità DirectX 10 o versione successiva deve essere aggiunto in un pacchetto di risorse per risparmiare spazio su disco locale e scaricare la larghezza di banda. Ciò consente di usare gli schemi di compressione più avanzati per 11, ad esempio BC6H e BC7. Per altri dettagli, vedere Compressione del blocco trama in Direct3D 11. Questi formati sono più efficienti per gli asset di trama ad alta risoluzione supportati dalle GPU moderne e l'uso migliora l'aspetto, le prestazioni e i requisiti di spazio del gioco su piattaforme di fascia alta.

Inoltre, ogni livello di funzionalità DirectX supporta diverse versioni del modello di shader. Le risorse dello shader compilate possono essere create a livello di funzionalità e possono essere incluse nei Pacchetti di risorse a livello di funzionalità DirectX. Inoltre, alcuni modelli di shader versione successiva possono usare asset, ad esempio le mappe normali, che le versioni precedenti del modello shader non possono. Questi asset specifici del modello shader devono essere inclusi anche in un pacchetto di risorse a livello di funzionalità DirectX.

Il meccanismo delle risorse è incentrato principalmente sui formati di trama supportati per gli asset, quindi supporta solo i 3 livelli di funzionalità complessivi. Se è necessario disporre di shader separati per i livelli secondari (versioni con punti) come DX9_1 e DX9_3, il codice di gestione degli asset e rendering deve gestirli in modo esplicito.

Quando si configura l'app per supportare i pacchetti di risorse per diversi livelli di funzionalità DirectX, è necessario:

• Creare una sottodirectory dell'app (o versione del file) per ogni livello di funzionalità DirectX supportato (dxfl-dx9, dxfl-dx10 e dxfl-dx11).

• Durante lo sviluppo, posizionare asset specifici a livello di funzionalità in ogni directory delle risorse a livello di funzionalità. A differenza delle impostazioni locali e dei fattori di ridimensionamento, potresti avere rami di codice di rendering diversi per ogni livello di funzionalità del gioco e se hai trame, shader compilati o altri asset usati solo in uno o in un subset di tutti i livelli di funzionalità supportati, inserisci gli asset corrispondenti solo nelle directory per i livelli di funzionalità che li usano. Per gli asset caricati in tutti i livelli di funzionalità, assicurarsi che ogni directory delle risorse a livello di funzionalità abbia una versione con lo stesso nome. Ad esempio, per una trama indipendente a livello di funzionalità denominata "coolsign.dds", posizionare la versione compressa BC3 nella directory \dxfl-dx9 e la versione compressa BC7 nella directory \dxfl-dx11.

• Assicurarsi che ogni asset (se disponibile per più livelli di funzionalità) abbia lo stesso nome in ogni directory. Ad esempio, coolsign.dds deve avere lo stesso nome nelle directory \dxfl-dx9 e \dxfl-dx11 anche se il contenuto del file è diverso. In questo caso, li vedrai come \dxfl-dx9\coolsign.dds e \dxfl-dx11\coolsign.dds.

  Nota Anche in questo caso, è possibile aggiungere il suffisso a livello di funzionalità al nome del file e archiviarli nella stessa directory, ad esempio \textures\coolsign_dxfl-dx9.dds, \textures\coolsign_dxfl-dx11.dds.

   

• Dichiarare i livelli di funzionalità DirectX supportati durante la configurazione delle risorse grafiche.

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

• Usare le API in Windows.ApplicationModel.Resources.Core per caricare le risorse. I riferimenti agli asset devono essere generalizzati (senza suffisso), lasciando il livello di funzionalità. Tuttavia, a differenza del linguaggio e della scalabilità, il sistema non determina automaticamente quale livello di funzionalità è ottimale per un determinato display; che viene lasciato all'utente per determinare in base alla logica del codice. Dopo aver determinato questa determinazione, usare le API per informare il sistema operativo del livello di funzionalità preferito. Il sistema sarà quindi in grado di recuperare l'asset corretto in base a tale preferenza. Ecco un esempio di codice che mostra come informare l'app del livello di funzionalità DirectX corrente per la piattaforma:

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

• Usare ora ResourceManager per individuare il file corrispondente al livello di funzionalità DirectX corrente. ResourceManager restituisce un oggetto ResourceMap, su cui si esegue una query con ResourceMap::GetValue (o ResourceMap::TryGetValue) e un oggetto ResourceContext fornito. Viene restituito un oggetto ResourceCandidate che corrisponde maggiormente al livello di funzionalità DirectX specificato chiamando 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;
  

• In Visual Studio 2015 selezionare PROGETTO->Store->Crea pacchetto app... e creare il pacchetto.

• Assicurarsi di abilitare i bundle dell'app nelle impostazioni del manifesto package.appxmanifest.

Argomenti correlati

• Definire le risorse dell'app
• Creazione di pacchetti delle app
• Strumento per la creazione di pacchetti di app (MakeAppx.exe)