Il gioco Super Mario Bros. era di soli 31 Kilobyte. Com'è possibile?

Questa è una domanda affascinante. Ho letto la sua risposta un paio di mesi fa, "LA RISPOSTA ESPLICATIVA". Senza perdere tempo, permettetemi di condividerla con voi.

Voglio però mettere in chiaro una cosa: non stiamo davvero confrontando mele con mele, quindi definiamo prima alcune tecnologie.

Come funziona Mario

Perciò parliamo di come funzionava il gioco originale di Super Mario, dal punto di vista delle risorse.

La console NES originale era progettata solo per produrre immagini di 256 di larghezza per 240 di altezza; ciò significa che l'immagine finale che doveva essere visualizzata sullo schermo aveva una dimensione di 180kb.

Inoltre, il NES aveva solo 2kb di RAM. Una cartuccia stessa poteva contenere da 8k a 1mb di dati di gioco. Quindi, non c'era modo di inserire l'intero contenuto del gioco nella memoria principale. Fondamentalmente, un sottoinsieme dei dati della cartuccia da 1MB deve essere caricato nella RAM da 2kb e usato per rendere lo schermo da 180kb. Come si ottiene ciò?

SpriteSheets.

Sprite sheets contengono piccole piastrelle di grafica, che vengono riutilizzate più e più volte. Per esempio, qui sotto c'è un remake del foglio sprite originale di Super Mario:

Non è l'esatto foglio sprite originale, ma si può avere un'idea dei piccoli blocchi di dati che possono essere usati più e più volte.

Ogni piccolo quadrato di 16x16 pixel rappresenta un "tile" e gli artisti li mettevano insieme per creare i livelli. I livelli stessi diventavano semplicemente un gigantesco array 2D di indici nel foglio degli sprite. (Parlo di questo in modo molto più dettagliato nella Lezione 3 del mio corso HTML5 Game Development @ Udacity, o nel mio libro HTML5 Game Development Insights.) Aggiungete un po' di Run-Length-Encoding, o un po' di LZ77 di base, e otterrete un formato abbastanza compatto per i livelli.

Ecco, quel livello che i vostri genitori non potrebbero mai completare.

Quindi con concetti come tile-sheets e sprite-sheets, possiamo usare un piccolo set di immagini per creare grandi scene e mondi. Questo è generalmente il modo in cui funziona la maggior parte dei giochi. Anche i giochi 3D avranno un insieme di texture comuni che vengono applicate più volte e in più punti nel gioco stesso.

Ora parliamo della compressione generica delle immagini.

Come vengono compresse le immagini

Ecco la parte "non giusta" di questo confronto. Gli algoritmi generici di compressione delle immagini non hanno alcuna conoscenza del dominio dei pixel al loro interno. JPG, PNG, WebP sono stati tutti progettati per le foto e non tanto per le schermate dei giochi. Il risultato è che per un dato blocco di 16x16 pixel, questi algoritmi assumono che sia unico nell'immagine; a parte qualche quantizzazione del colore, non c'è una vera logica aggiunta per determinare se un altro blocco 16x16 potrebbe essere un esatto duplicato di quello attuale. Questo generalmente significa che c'è un limite inferiore su come un dato blocco di dati viene compresso.

Per esempio, JPG rompe una data immagine in blocchi di 8x8 pixel, converte lo spazio colore RGB nella versione YCbCr, e poi applica la trasformazione discreta coseno su di essi. È solo dopo questo passo che un codificatore lossless arriva, e vede se può abbinare gruppi comuni duplicati usando DPCM, o RLE.

Una visione a blocchi di come funziona la compressione delle immagini JPG.

Quindi, l'unico posto dove due blocchi potrebbero essere compattati in 1 blocco, è se la loro versione post-DCTd è identica, e RLE può fare delle raccomandazioni di falcata. Questo non accade molto spesso.

Nonostante i suoi altri difetti, PNG è molto meglio in questo senso. La compressione PNG è interamente senza perdita, (quindi la qualità dell'immagine è alta, ma il risparmio di compressione è basso), e basata sul codec DEFLATE, che accoppia LZSS con la compressione aritmetica. Il risultato è che lunghe serie di pixel simili possono finire per essere ridotte ad una dimensione molto più piccola. Questo è il motivo per cui un'immagine con uno sfondo molto uniforme sarà sempre più piccola come PNG invece che come JPG.

L'immagine qui sotto è un file PNG da 5.9kb, mentre l'immagine JPG è 106kb

Siccome questa immagine ha molti pixel duplicati (lo sfondo blu del cielo) i compressori come PNG fanno un lavoro migliore delle loro controparti JPG a blocchi.

Apples vs. Dragonfruit

Il mio punto qui è che è piuttosto ingiusto paragonare il contenuto di un gioco a una singola immagine su internet.

Dal lato del gioco, si inizia con un piccolo set di tessere riutilizzabili, e le si indicizza per costruire l'immagine più grande, possiamo farlo, perché sappiamo come sarà fatto il gioco. Dall'altro lato, JPG/PNG/WebP cerca solo di comprimere i dati che può trovare nei blocchi locali, senza alcun reale desiderio di far corrispondere il contenuto ripetuto. La compressione delle immagini è chiaramente in svantaggio qui, dato che non hanno una conoscenza preliminare del loro spazio di dati, non possono davvero fare alcuna aspettativa su di esso.

Voglio dire, considerate The Demo Scene che è super grande su questo genere di cose. Possono stipare 30 minuti di un intero sparatutto in 3d in 64kb perché capiscono e conoscono molto di più i loro dati.

Un confronto molto migliore. La demo .kkrieger ha inserito 30 minuti di gameplay di uno sparatutto 3D, con fisica, suono, texture e IA in 64kb di dati. Sembra un'enorme quantità di guadagno per soli 24kb in più rispetto al Mario originale.

Si tratta solo di dimostrare che con la giusta quantità di conoscenza dei propri dati, si possono fare grandi cose con la compressione.

Fonte : Da dove vengono tutti i byte? - Free Code Camp

Spero che queste informazioni siano sufficienti per capire la magia nera dietro Mario.