Miglioramenti e modifiche - Note di rilascio di Lumberyard

Miglioramenti e modifiche

In Lumberyard Beta 1.22 sono stati implementati miglioramenti e modifiche a sistemi e funzionalità Lumberyard.

Asset Pipeline (Pipeline asset)

Nuove caratteristiche

La pipeline degli asset è stata dotata delle seguenti nuove funzionalità:

  • Asset Bundler – Uno strumento a riga di comando, AssetBundlerBatch.exe, per creare bundle di asset di gioco per il rilascio. Di seguito sono riportate ulteriori nuove funzionalità che supportano il bundling degli asset:

    • Pacchetto gem di convalida degli asset: utilizza questo pacchetto gem per eseguire il gioco esclusivamente da bundle di asset.

    • Sistema di dipendenza del prodotto: i generatori generano ora dipendenze del prodotto, inclusi i processi di copia. Le dipendenze del prodotto sono la spina dorsale della creazione di bundle di asset e consentono al generatore di asset di valutare un asset e di determinare tutti gli altri asset dipendenti.

    • Scanner dipendenza mancanti: esegui AssetProcessorBatch.exe con il flag /dependencyScanPattern per identificare potenziali dipendenze del prodotto mancanti.

    • Sistema schema XML: un framework per definire le dipendenze per i file XML.

    • Sistema di tagging degli asset – Sistema di tagging dei file: questo sistema fornisce un modo per "aggiungere tag" a un asset come un tipo specifico, ad esempio "editor-only", "shader" o "ignora dipendenze del prodotto". I tag vengono quindi utilizzati dallo scanner dipendenze mancanti e da altri strumenti.

      Per ulteriori informazioni, consulta la documentazione di Asset Bundler. Se stai lavorando con i nuovi tutorial Asset Bundler, scarica prima Build_AssetBundler_AuxiliaryContent_PC.bat .

  • Cataloghi Delta – I file .pak (PAK) contengono ora versioni ridotte di AssetCatalog.xml che risiedono all’interno di un .pak e descrivono solo i file all’interno di quel dato PAK. In fase di esecuzione, durante l’apertura di un nuovo file pak tramite CryPak, il sistema cercherà automaticamente un catalogo delta all'interno del PAK e, se lo trova, aggiornerà il registro degli asset con le informazioni all'interno del file PAK sovrapposte ai vecchi dati. (È possibile aggiungere nuovi asset o aggiornare vecchi asset.)

Miglioramenti

Nella pipeline degli asset sono stati implementati i seguenti miglioramenti:

  • Processore degli asset – Nel processore degli asset è stata implementata una serie di miglioramenti:

    • Timer del processore degli asset – Il processore degli asset è ora dotato di tre timer: Ultima scansione, Analisi ed Elaborazione. Ogni timer rappresenta la quantità di tempo trascorso dal processore degli asset in ciascuna di queste tre fasi.

    • Visibilità del file di errore migliorata – Gli avvisi relativi agli asset sono stati resi più visibili nel processore degli asset.

    • Sono state aggiunte cartelle per l’AssetProcessorPlatformConfig.ini specifico della piattaforma per separare configurazioni generiche e specifiche della piattaforma.

    • Miglioramenti in termini di prestazioni generali.

  • Pulizia caricamento di file obsoleti – Sono state rimosse alcune chiamate non necessarie che caricavano file obsoleti.

  • Copy Depdendency Builder – Alcune attività di copia precedentemente definite in AssetProcessorPlatformConfig.ini sono state rimosse. Al loro posto, è stato introdotto un nuovo CopyDependencyBuilder che esegue la stessa copia nella cache. CopyDependencyBuilder esamina anche gli asset che copia per le dipendenze dei prodotti, emettendo quanto rilevato.

  • Versioni pacchetti gem

    • Le versioni di alcuni pacchetti gem inclusi in Lumberyard sono state aggiornate. Per ottenere questi aggiornamenti:

      • Popolare i descrittori dell'app per assicurarsi che il progetto continui a funzionare. Per ulteriori informazioni, leggere Pacchetti gem e moduli AZ.

      • Se il popolamento dei descrittori di app non riesce per il progetto, modificare manualmente il file Gems.json del progetto per fare riferimento alle nuove versioni dei pacchetti gem.

      • Aggiornare i file Editor.xml e Game.xml del progetto (all’interno della cartella di configurazione sotto la root del progetto).

        Nel file editor.xml, modificare la riga che menziona Gem.LyShine in:

        <Class name="AZStd::string" field="dynamicLibraryPath" value="Gem.LyShine.0fefab3f13364722b2eab3b96ce2bf20.v0.1.0" type="{189CC2ED-FDDE-5680-91D4-9F630A79187F}"/>

        Nel file Game.xml, aggiornare la riga che fa riferimento al pacchetto gem SaveData a:

        <Class name="AZStd::string" field="dynamicLibraryPath" value="Gem.SaveData.d96ab03f53d14c9e83f9b4528c8576d7.v0.1.0" type="{189CC2ED-FDDE-5680-91D4-9F630A79187F}"/>

Audio

Audio presenta le nuove funzionalità e i miglioramenti che seguono:

Nuove caratteristiche

  • I moduli del motore CrySoundSystem e CryAudioImplWwise sono stati convertiti in pacchetti gem.

    • CrySoundSystem è ora il pacchetto gem "Audio System" che si trova in Gems/AudioSystem.

    • CryAudioImplWwise è ora il pacchetto gem "Wwise Audio Integration" che si trova in Gems/AudioEngineWwise.

    • NOTA: questi pacchetti gem sono opzionali. Se il progetto utilizza Wwise, eseguire Project Configurator e abilitare le i pacchetti gem "Audio System" e "Wwise Audio Integration".

Miglioramenti

  • L'analisi XML nel pacchetto gem Audio System ora utilizza RapidXML.

Supporto SDK Native di AWS

La versione di SDK Native di AWS è stata aggiornata alla 1.7.167.

Nota

Utenti Linux: se il progetto o pacchetto gem dipende da SDK Native di AWS su Linux (come nel caso del pacchetto gem Twitch), il debug e le build del profilo richiedono che nella configurazione Linux siano del sistema presenti libssl.so.1.1 e libcrypto.so.1.1. Tuttavia, le build di rilascio collegano queste librerie staticamente, pertanto non sono richieste modifiche per le build di rilascio Linux di Lumberyard.

Grandi mondi

Grandi mondi presenta i seguenti miglioramenti e modifiche:

Miglioramenti

Grandi mondi: terreni legacy

  • È ora possibile rimuovere il sistema di terreno legacy dal motore utilizzando il flag compile/script enable_legacy_terrain in dev/Code/wscript.

  • È ora possibile abilitare parametri di memoria, I/O e prestazioni più dettagliati per il sistema di terreno legacy con cvars e_TerrainPerformanceSecondsPerLog ed e_TerrainPerformanceCollectMemoryStats.

  • La dipendenza da terreno legacy è stata rimossa da diversi sistemi core nel motore.

Grandi mondi: strade

  • La mesh stradale è circa 4 volte più veloce grazie ai miglioramenti nella creazione di batch, nelle attività e nella ripartizione del tempo.

Mobile

Mobile presenta i seguenti miglioramenti e modifiche:

Miglioramenti

  • Aggiunto il supporto per Xcode 11. Richiede macOS High Sierra o superiore.

  • Supporto per iOS v13.

  • iOS e Android: ottimizzazione per la larghezza di banda della GPU – Eliminazione del target di rendering "Accumulo diffuso" durante il passaggio di illuminazione, che ha portato a un risparmio di memoria di 88 bit per pixel per frame. Viene abilitato tramite cvar "R_DeferredShadingLBuffersFmt = 2".

  • Ultimo supporto NDK (r20).

  • Miglioramenti al flusso di lavoro di Compilazione di shader/release (Rimuovi passaggio aggiuntivo, Segnalazione errori).

  • Android: miglioramento dei tempi di caricamento del 40% più veloci quando si caricano gli asset da .APK non nei file.pak.

  • Supporto per Android Q - API 29.

Reti

Network Context presenta i seguenti miglioramenti e modifiche:

Miglioramenti

  • In Lumberyard, Network Context semplifica la scrittura di componenti multigiocatore in C++. Ciò che nell'implementazione grezza di GridMate può richiedere 100 righe di codice, in Network Context si può ottenere con meno di una dozzina di linee con l'interfaccia.

  • Network Context fa parte della famiglia di contesti, insieme a Serialize Context, Edit Context e Behavior Context. Network Context consente di contrassegnare con tag le variabili membro dei componenti come campi di rete o chiamate di procedure remote e utilizzarle in modo più semplice, rispetto all'uso diretto di GridMate.

  • MultiPlayerSample è stato aggiornato per utilizzare Network Context in più componenti, ad esempio HealthBarComponent.

Supporto delle piattaforme

Supporto e servizi di piattaforma presentano i seguenti miglioramenti e modifiche:

Nuove caratteristiche

  • Pacchetto gem traguardi/trofei: il pacchetto gem dei traguardi offre un'interfaccia di gioco per i servizi di traguardi e trofei per i giochi per console. Durante il gioco, consente di sbloccare, interrogare e aggiornare i dati relativi a traguardi e trofei attraverso i servizi forniti per tale console.

Miglioramenti

  • Supporto presenza ricco per i servizi della piattaforma: il pacchetto gem Presenza offre un'interfaccia di gioco per i servizi Presenza per i giochi per console. Durante il gioco, consente di impostare e interrogare lo stato relativo alla presenza di un utente su tale console. Presenza è il messaggio che appare visualizzato gli elenchi di amici e su un profilo utente come impostato dal gioco, in base all'attività dell'utente.

Supporto PhysX

Miglioramenti

  • Gli eventi di aggiornamento del mondo pre e post fisica sono esposti nello script canvas (il contesto del comportamento).

  • La modalità componente viene introdotta per i componenti del collisore PhysX. Ciò consente di modificare le dimensioni di forma, gli offset di posizione e rotazione per i componenti del collisore direttamente nella finestra con i manipolatori.

  • Le regioni di forza sono migliorate per inviare impulsi all'aggiornamento del mondo post fisica invece del segno di spunta di rendering.

  • Correzioni generali di bug.

Supporto Python

Modifiche nel supporto

  • In una prossima versione, Amazon Lumberyard passerà a Python 3.7.5. Da tale momento, rimuoveremo le versioni precedenti di Python dall'installazione di Lumberyard .

Sistemi

In Sistemi sono stati implementati i seguenti miglioramenti e modifiche:

Nuove caratteristiche

Strumento di rilevamento del sovraccarico di memoria (rilevamento del sovraccarico)

  • Lo strumento di rilevamento del sovraccarico di memoria fornisce il rilevamento del sovraccarico, verificando la presenza di memoria danneggiata da letture/scritture esterne ai limiti della memoria allocata.

    Il segno principale di quello che potrebbe essere un sovraccarico di memoria è un arresto anomalo senza spiegazione ovvia, spesso in un sistema o in una struttura di basso livello (come un container AZStd::) o all'interno dell'allocatore di memoria (ma non un errore di memoria esaurita).

    Per iniziare a usarlo, passare alla directory /dev/{your-game-project-name}/Config/ nella radice di installazione Lumberyard e aprire Game.xml. Modificare il valore useOverrunDetection da false a true. (Potrebbe anche essere necessario modificare questa impostazione in dev/{your-game-project-name}/Config/Launch/Game.xml.)

    Con il rilevamento di sovraccarico abilitato, è possibile giocare normalmente e se un sistema legge o scrive al di fuori della memoria che è stata allocata, si verificherà un arresto anomalo del gioco con un callstack nel punto di lettura/scrittura non valida.

  • Note:

    • Ci possono essere momenti in cui il gioco non si interrompe ma viene interrotto forzatamente. In questo caso, mettere in pausa il debugger e controllare il punto di arresto. Alla fine dell'output viene visualizzato un messaggio del tipo “Eccezione generata: lettura/scrittura non valida”. La formulazione di questo messaggio può variare da piattaforma a piattaforma.

    • Se si tenta di riprodurre il problema e si verifica un altro arresto anomalo, la causa del crash potrebbe non essere sempre lo stesso bug. Nella maggior parte dei casi, diversi callstack indicano bug separati, mentre callstack simili indicano lo stesso bug.

  • Alcuni aspetti aggiuntivi da considerare quando si utilizza la modalità di rilevamento di sovraccarico:

    • Non effettuare il check-in nel Game.xml modificato!

    • La modalità di sovraccarico funziona solo su Windows e console supportate con memoria aggiuntiva allocata.

    • È compilato fuori dalle modalità Performance e Release.

    • Il gioco verrà eseguito più lentamente e ci vorrà molta più memoria!

    • Questa modalità imita fondamentalmente il comportamento di GFlags con verifica dell'heap di pagina intera, ma è disponibile con gli allocatori LY senza ricompilare nulla.

    • Il rilevatore non rilascia sempre memoria e può continuare ad aumentare il consumo di memoria man mano che il gioco continua. Dovrebbe essere una quantità di memoria sufficiente per testare uno o due livelli ma, soprattutto su piattaforme limitate, non c’è da aspettarsi una progressione infinita.

      • Se si esaurisce la memoria, si blocca in WindowsPlatformAllocator::ReserveBytes or WindowsPlatformAllocator::CommitBytes.

      • Qualsiasi scrittura/lettura non valida includerà il normale messaggio "Eccezione generata: lettura/scrittura non valida" verso la fine dell'output. Se non vedi quel messaggio, questo indica anche che non si tratta di un bug di lettura/scrittura.

Asset Memory Analyzer

  • Asset Memory Analyzer è una caratteristica sperimentale che offre un elenco dettagliato di tutta la memoria allocata dai vari asset caricati nel gioco. Utilizzarla per scoprire quali asset sono effettivamente caricati in fase di runtime e come ogni asset contribuisce all'utilizzo della memoria.

    Per iniziare a utilizzarla, procedere nel modo seguente:

    1. Passare alla radice di installazione di Lumberyard e aprire AzCore/Debug/AssetMemoryDriller.h. Assicurarsi che AZ_ANALYZE_ASSET_MEMORY sia definito. (Rimuovere i commenti dal codice se si trova in un blocco di commento.) Se si desidera abilitare l'analisi anche per tipi di build diversi da quelli di rilascio, aprire dev/Code/Framework/AzCore/AzCore/Memory/Config.h e rimuovere i commenti da #define per AZCORE_ENABLE_MEMORY_TRACKING.

    2. Aprire Game.xml in dev/{your-game-project-name}/Config e impostare entrambi i campi enableDrilling e enableAssetMemory su true.

    3. Se è stato abilitato IMGUI, è possibile aprire la finestra di analisi eseguendo AssetMemoryAnalyzer > Open (Apri) dal menu Debug. Verrà visualizzata la finestra Asset Memory Analysis (Analisi memoria risorsa).

      • Ogni asset registrato viene visualizzato, insieme al numero di allocazioni e kilobyte totali allocati, sia per heap sia per VRAM. Utilizzare i pulsanti nella parte superiore della finestra per porre in ordine discendente gli elementi di una delle categorie disponibili.

        Espandere i singoli asset per visualizzare sia le singole allocazioni di un asset sia gli asset secondari caricati in seguito al caricamento di questo asset.

  • Per esportare l'analisi in un file JSON, utilizzare uno dei seguenti metodi:

    • Se IMGUI è abilitato, è possibile scegliere AssetMemoryAnalyzer > Export JSON (Esporta JSON) dal menu Debug.

    • Nella console, immettere assetmem_export per generare il file.

    • Dal codice C++, chiamare ExportJSONFile AssetMemoryAnalyzerRequestBus, con nullptr come parametro per generarlo nella posizione predefinita.

      Ad esempio: EBUS_EVENT(AssetMemoryAnalyzerRequestBus, ExportJSONFile, nullptr). Questo genererà un file nella directory @log@, intitolato assetmem-.json.

  • Per visualizzare i file JSON di analisi della memoria nel browser, aprire dev/Gems/AssetMemoryAnalyzer/www/AssetMemoryViewer/index.html nel browser web (è consigliato Google Chrome). Nella pagina Web che si apre, trascinare e rilasciare il file JSON o fare clic sull'area target per visualizzarlo.

    Questo mostrerà il contenuto del file in una tabella espandibile. Ordinare la tabella in base a una qualsiasi delle colonne. Le colonne danno una ripartizione per più categorie:

    • Heap Allocation (Allocazioni heap) e VRAM Allocations (Allocazioni VRAM)

    • Local summary (Riepilogo locale), che non include le attività secondarie, e Total summary (Riepilogo totale), che include tutte le attività secondarie.

    • Il numero di allocazioni, così come i kilobyte (Kb) allocati.

      Eseguire il drill-down in uno qualsiasi degli asset elencati per scoprire sia le singole allocazioni appartenenti a tale asset sia gli asset secondari che sono stati caricati come conseguenza del caricamento di questo asset.

  • Per strumentare il codice, esaminare i seguenti elementi:

    • Per il caricamento iniziale degli asset:

      • AssetMemoryDriller cattura le allocazioni (heap e VRAM) che si verificano durante una porzione di esecuzione di codice o "ambito" quando un asset è attivo per la registrazione.

        Quando un sistema inizia a caricare un nuovo asset, deve utilizzare la macro AZ_ASSET_NAMED_SCOPE per delimitare l'ambito C++ in cui tale asset potrebbe effettuare attivamente allocazioni.

        #include <AzCore/Debug/AssetMemoryDriller.h> Foo* LoadMyFooAsset(const char* name) { AZ_ASSET_NAMED_SCOPE("Foo: %s", name); Foo* result = aznew Foo(name); // The call to aznew will be recorded as associated with the asset "Foo: <name>" return result; // Once we exit this function, the asset will no longer be in scope, and subsequent allocations will not be recorded }
    • Per la successiva elaborazione delle attività:

      • In seguito, quando un sistema sta per fare più lavoro che coinvolge un asset, o se la risorsa viene trasferita a un thread diverso, dovrebbe utilizzare la macro AZ_ASSET_ATTACH_TO_SCOPE con un puntatore allocato e tracciato dall'asset iniziale. Ciò assocerà eventuali ulteriori allocazioni con lo stesso asset:

        #include <AzCore/Debug/AssetMemoryDriller.h> void UpdateAllFoos(const AZStd::vector<Foo*>& allFoos) { for (Foo* foo : allFoos) { AZ_ASSET_ATTACH_TO_SCOPE(foo); // Subsequent allocations in this scope will associate with any asset that was in scope when foo was allocated UpdateFoo(foo); } } void UpdateFoo(Foo* foo) { aznew Bar; // This automatically gets recorded with the owning asset for foo AZStd::thread doThreadedWork([foo]() { // Work being done on a different thread means we need to reattach to the owning asset AZ_ASSET_ATTACH_TO_SCOPE(foo); aznew Bar; // This will now be recorded under the owning asset for foo }); doThreadedWork.join(); }
      • È possibile tentare di collegarsi a qualsiasi puntatore creato mentre tale asset era nell'ambito o anche a qualsiasi porzione di memoria che è stata allocata. Ad esempio, il seguente codice funziona:

        #include <AzCore/Debug/AssetMemoryDriller.h> struct Baz { int a; char* b; double c; } Baz* CreateBaz(const char* name) { AZ_ASSET_NAMED_SCOPE(name); Baz* baz = aznew Baz; // bar is associated with the named asset return baz; } void TestScopes() { Baz* baz = CreateBaz("My test baz"); { AZ_ASSET_ATTACH_TO_SCOPE(&baz->c); // This works, even though "c" didn't have its own allocation baz->b = aznew char[32]; // This allocation will be recorded under the asset "My test baz" } }

        Ciò significa che non è necessario un puntatore originale a un oggetto che è stato allocato all'interno di un ambito per collegarlo a questo, solo qualcosa di "abbastanza vicino". In questo modo è possibile collegare sistemi a oggetti che sono stati definiti con eredità multipla.

  • Per eseguire l'elaborazione degli asset Ebus:

    • I gestori Ebus possono tentare automaticamente di connettersi a un ambito per ogni gestore che riceve un evento. Funziona quando il gestore stesso è stato allocato come parte di un asset.

      Alcuni Ebus di Lumberyard utilizzano già questa funzione, ad esempio TickBus. Se trovi altri che dovrebbero usarlo, aggiungili! (Tuttavia, non è consigliabile utilizzare in modo predefinito questo EventProcessingPolicy se non è applicabile; vedere le considerazioni sulla strumentazione di seguito.)

  • Considerazioni sulla strumentazione:

    • La creazione di un nuovo ambito denominato richiede chiamate di funzione, ricerca dell'ambiente, blocco di un mutex, due ricerche hashtable e modifiche locali del thread.

    • Il collegamento a un ambito esistente richiede chiamate di funzione, ricerca dell'ambiente, blocco di un mutex, ricerca in un grande albero rosso-nero e modifiche locali del thread.

      La maggior parte delle volte questo ha un costo relativamente piccolo, ma è abbastanza significativo da non utilizzare la macro AZ_ASSET_ATTACH_TO_SCOPE (o utilizzare AssetMemoryDrillerEventProcessingPolicy sull’Ebus) in modo ridondante o se è improbabile che si colleghi a qualcosa.

      Non vi è alcun costo per la strumentazione nelle build in cui AssetMemoryDriller è disabilitato, cioè se la macro AZ_ANALYZE_ASSET_MEMORY rimane indefinita. (Questa è l'impostazione predefinita nelle build Prestazioni.)

Miglioramenti

  • Tracciamento della memoria migliorato per VRAM e visualizzazione di cvar e_MemoryProfiling (LY-104969). L'utilizzo della memoria ora è ripartito:

    • Texture VRAM: raggruppata per target di rendering, asset, dinamica. Buffer: vertice, indice, costante, altro.

    • CPU: suddivisa per allocatori principali.

  • Ristrutturazione della gerarchia di classi di allocatori; rendendole più stabili per l'ordinamento di avvio (risolvendo alcuni problemi nelle build di release/monolitiche).

  • Driller di memoria: correzioni per scaricare tutte le allocazioni in file CSV. NOTA: con qualsiasi modifica che influisce sul layout della memoria, i bug relativi alla memoria precedenti che non causavano arresti anomali/problemi potrebbero ora produrre un comportamento imprevisto. Ad esempio, un sovraccarico di memoria che in precedenza non produceva alcun bug visibile/rilevabile, ora può produrre problemi.

  • IMGUI migliorato: ora si utilizza l'ultima versione di IMGUI con supporto aggiunto per console e controller.

  • Framework asserzioni migliorati: ora si utilizza AZ_Assert con 3 livelli di sys_assert CVAR: 0: niente, 1: solo log, 2: dialogo quando le asserzioni non riescono su tutte le piattaforme.

SDK di Twitch Commerce

Nella funzionalità Animation Editor (Editor animazione) sono stati implementati i seguenti miglioramenti e le seguenti modifiche:

Modifiche nel supporto

Il pacchetto gem Twitch non richiede più l'SDK di Twitch Commerce. L'SDK di Twitch Commerce è obsoleto.

Supporto per Visual Studio

Modifiche nel supporto

Il supporto di Visual Studio 2015 è considerato obsoleto a partire da Amazon Lumberyard versione 1.22. Anche i riferimenti a Visual Studio 2015 e ai file binari VC140 sono stati rimossi dalla documentazione per la versione 1.22. Se utilizzi Visual Studio 2015 o una versione precedente, consulta la documentazione archiviata di Amazon Lumberyard per le versioni precedenti. La versione corrente supportata di Visual Studio è VS 2017 v15.9.2 o successiva e la versione binaria VC++ supportata per le build è VC141.

Varie

Modifiche nel supporto

  • Lo strumento Resource Compiler Image sarà considerato obsoleto in una prossima release di Lumberyard e sostituito dal pacchetto gem ImageProcessing.