2012-06-29 12 views
7

Ho cercato di scoprire come i motori di gioco gestiscono la compressione delle risorse. Ovviamente comprimono tutte le risorse quando costruiscono il gioco. Ma come li decomprimono durante il runtime. L'unica cosa che potevo pensare era decomprimerla in memoria, ma doveva essere molto intensiva della memoria. Se si decomprimono sull'HDD, una cartella si riempie durante il gioco? Questo non suona molto efficiente.Decompressione runtime di Game Engine

Utilizzando una libreria come zlib (o qualsiasi altra) con C++, come viene eseguita questa decompressione di runtime?

David

+2

non so cosa 'asset' significa qui in particolare, ma se hai molti file compressi separati, potresti provare a decomprimere su richiesta + un po 'di cache. Quindi un file viene decompresso in memoria solo quando è necessario, quindi viene memorizzato nella cache e, se non è necessario per un certo tempo, viene scartato dalla cache quando altri file devono essere decompressi, per evitare che la cache diventi troppo grande. – sashoalm

+0

per asset intendo i file necessari per il gioco, cose come immagini, mesh, materiali, shader quel genere di cose – Constan7ine

+0

In "Game Coding Complete" c'era praticamente il metodo descritto da satuon. – risingDarkness

risposta

9

È un po 'come questo, hai un gioco con così tanti dati che non si adatta a una quantità ragionevole di memoria, quindi non puoi caricarli tutti in una volta in memoria, quindi definisci dei buffer per i dati che utilizzi come cache.

Ora la memoria in ordine di velocità dal più basso al più alto, in quanto tale:

  • DVD
  • disco rigido
  • RAM

Idealmente non sarà necessario eseguire lo streaming dei dati da il DVD, ma è qualcosa da tenere in considerazione se devi fare un gioco per console, per esempio. Quindi per ciascuno di questi spazi di archiviazione disponibili si definisce un buffer da utilizzare come cache.

Quando il motore di gioco decide che potrebbe aver bisogno di una risorsa, dovrebbe prima cercare nella cache più veloce per vedere se la risorsa è già stata caricata. Se è allora che sei fortunato, puoi immediatamente inviarlo per essere estratto. Se non è nella cache più veloce, devi scendere di un livello nella cache del disco rigido. Questo è un file in cui si conservano asset già decompressi e pronti per essere caricati in memoria. Se la cache più veloce non è completamente occupata, puoi iniziare a caricare i dati e usarli quando è pronto. Se lo spazio non è sufficiente, dovrai prima scaricare altre risorse, ti consiglio di rimuovere le risorse meno utilizzate di recente fino a quando non avrai spazio sufficiente per caricarne una nuova.

Ora se la cache del disco rigido non ha i dati caricati, è necessario scendere di un altro livello nell'archivio, si vorrà utilizzare il formato zip per comprimerlo perché il formato del file zip non forza devi decomprimere l'intero archivio per avere accesso a un solo file, quindi tutto ciò che devi fare è trovare l'offset di detto file all'interno dell'archivio e decomprimerlo nella cache del disco rigido. Anche in questo caso, se la cache è piena dovresti prima scaricare alcune altre risorse, ancora una volta ti consiglio di rimuovere la meno recente utilizzata, ma puoi provare anche altri algoritmi se pensi che migliorerà le prestazioni.

John Karmack aveva un keynote al QuakeCon 2011, dove ha spiegato tutto questo processo forse un po 'meglio di me in un post (tra le altre cose impressionanti), si può trovare here

+0

Wow Grazie ragazzi per le vostre eccellenti risposte! – Constan7ine

0

motori di gioco contratto con la compressione di asset

Ci sono diversi asset motore di gioco come ad esempio i modelli geometrici (triangolazione/modello poligonale), texture, ecc Ogni classe di attivi ha un diverso strategia di compressione. Può essere più preciso ?

Per la compressione modello, Check this

+0

Ok diciamo textures. la ragione per cui dico questo è perché i motori con cui ho lavorato in precedenza sembrano comprimere quasi tutto in uno o due file che usano in fase di esecuzione. – Constan7ine

+0

Penso che dovresti vedere questo: http://www.webpronews.com/google- talks-texture-compression-for-games-at-gdc-2012-03 – Ram

3

compressione può avvenire in molti modi su molti livelli diversi, e quando, dove e come la sua utilizzati sono totalmente dipendenti quali sono i suoi obiettivi & obiettivi sono (compressione non è sempre di risparmiare spazio su disco).

In pratica, su un livello superiore, tutte le risorse potrebbero/potrebbero essere compresse in un archivio di massa (questo accelera le letture, poiché c'è meno da leggere dall'HDD, ma si sta sacrificando la potenza di elaborazione per questo, come indicato per usare DMA per leggere i file non compressi, che non usano affatto la CPU), la lettura indietro viene quasi sempre fatta memoria per la memoria, la lettura dell'HDD distruggerebbe le prestazioni e causerebbe una serie di problemi (e in alcuni casi sarebbe impossibile, come nelle console di vecchia generazione).

Un secondo livello può/può essere eseguito sulla risorsa stessa, ad esempio, le trame possono essere compresse in MOLTI modi diversi, ma principalmente la compressione a blocchi (S3TC/DXTn, BCn) viene utilizzata in questi giorni in quanto la sua decompressione è supportata in hardware (o emulato dal driver), quindi quando viene letto per l'archivio/disco, non è necessario eseguire ulteriori decompressioni.

Le strategie di compressione variano anche per piattaforma, soprattutto su console, che sono molto sensibili al layout della memoria, hanno risorse limitate e hanno piccole cache ecc

utilizzando una libreria come zlib (o qualsiasi altro) con C++ , come viene eseguita questa decompressione runtime?

in genere si desidera utilizzare i file mappati memoria dell'archivio e decomprimere direttamente sulla RAM, un buon esempio di un sistema di archiviazione AAA che è ben documentato che fa questo è il MPQ format (usato da Blizzard Entertainment, maggiori dettagli here), utilizza una varietà di algos di compressione, come deflate per Diablo I, zlib per Warcraft III, bzip2 in World of Warcraft e recentemente hanno aggiunto LZ e compressione sparsa per i loro nuovi giochi come SCII.

La tesi di Jan Wassenberg (Optimizing File Accesses via Ordering and Caching) presenta una buona interruzione della gestione dei file, che potrebbe anche essere di interesse.