O jogo Super Mario Bros. era apenas 31 Kilobytes. Como é que isso é possível?

Esta é uma pergunta fascinante. Li a sua resposta há uns meses atrás, "A EXACTA RESPOSTA EXPLANATÓRIA". Sem perder tempo, deixem-me partilhá-la convosco.>p>Quero definir algo claro aqui: não estamos realmente a comparar Maçãs com Maçãs, por isso vamos definir algumas tecnologias primeiro.

Como funciona o Mario

Então vamos falar sobre como o jogo Super Mario original funcionava, de uma perspectiva patrimonial.

A consola NES original foi desenhada apenas para produzir imagens que tinham 256 de largura por 240 de altura; o que significa que a imagem final que precisava de ser exibida no ecrã tinha 180kb de tamanho.

Além disso, a NES tinha apenas 2kb de RAM. Um cartucho em si podia conter de 8k a 1mb de dados do jogo. Portanto, não havia como encaixar todo o conteúdo do jogo na memória principal. Basicamente, um subconjunto dos dados do cartucho de 1MB deve ser carregado na RAM de 2kb e usado para renderizar a tela de 180kb. Como se consegue isso?

SpriteSheets.

Sprite sheets contêm pequenos tiles de gráficos, que são reutilizados uma e outra vez. Por exemplo, abaixo está um remake da folha original super mario sprite:

Não é a folha sprite original exata, mas você pode obter uma noção dos pequenos blocos de dados que podem ser usados sobre e sobre novamente.

Cada pequeno quadrado de 16x16 pixels representa um "azulejo" e os artistas os enfileirariam para criar os níveis reais. Os níveis em si, acabaram de se tornar uma gigantesca matriz 2D de índices para a folha de sprite. (Falo sobre isso com muito mais detalhes na Lição 3 do meu curso de Desenvolvimento de Jogos HTML5 @ Udacity, ou no meu livro HTML5 Game Development Insights). Tack on some Run-Length-Encoding, ou algum LZ77 básico, e você obtém um formato bastante compacto para níveis.

Até, aquele nível que vocês pais nunca poderiam completar.

Então com conceitos como tile-sheets e sprite-sheets, podemos usar um pequeno conjunto de imagens para criar grandes cenas & mundos. Geralmente é assim que a maioria dos jogos funciona. Mesmo jogos 3D terão um conjunto de texturas comuns que são aplicadas várias vezes e lugares ao longo do próprio jogo.

Agora vamos falar sobre compressão genérica de imagens.

Como as imagens são comprimidas

Aqui está a parte "não justa" desta comparação. Algoritmos genéricos de compressão de imagens não têm conhecimento de domínio sobre os pixels dentro delas. JPG, PNG, WebP foram todos desenhados para fotos e não tanto para telas de jogos. O resultado é que para um determinado bloco de 16x16 pixels, estes algoritmos assumem que é único entre a imagem; Além de alguma quantização de cores, não há nenhuma lógica real adicionada para determinar se outro bloco 16x16 poderia ser uma duplicata exata do bloco atual. Isto geralmente significa que há um limite inferior sobre como um dado bloco de dados é comprimido.

Por exemplo, JPG quebra uma dada imagem em blocos de 8x8 pixel, converte o espaço de cor RGB na versão YCbCr, e então aplica a transformação Discreta cosseno neles. Somente após este passo, aparece um codificador sem perdas, e veja se ele pode combinar grupos duplicados comuns usando DPCM, ou RLE.

Uma visão em bloco de como a compressão de imagens JPG funciona.

Então, o único lugar onde dois blocos podem ser compactados em 1 bloco, é se sua versão pós-DCTd é idêntica, e o RLE pode fazer recomendações stride. Isso não acontece com tanta freqüência.

Apesar de suas outras falhas, PNG é muito melhor nesse aspecto. A compressão PNG é totalmente sem perdas, (portanto sua qualidade de imagem é alta, mas sua economia de compressão é baixa), e baseada no codec DEFLATE, que emparelha LZSS junto com Arithmetic Compression. O resultado é que longas tiragens de pixels similares podem acabar sendo reduzidas a um tamanho muito menor. É por isso que uma imagem com um fundo muito uniforme será sempre menor como um PNG em vez de um JPG.

A imagem abaixo é um arquivo PNG de 5.9kb, enquanto a imagem JPG é 106kb

Desde que esta imagem tenha muitos pixels duplicados (o fundo azul do céu) compressores como o PNG fazem um trabalho melhor do que os seus homólogos JPG baseados em blocos.

Apples vs. Dragonfruit

O meu ponto aqui é que é meio injusto comparar o conteúdo do jogo com uma única imagem na internet.

Do lado do jogo, você começa com um pequeno conjunto de tiles reutilizáveis, e indexá-los para construir sua imagem maior, nós podemos fazer isso, pois sabemos como o jogo vai ser feito. Do outro lado, JPG/PNG/WebP apenas tenta comprimir os dados que pode encontrar em blocos locais, sem qualquer desejo real de combinar conteúdo repetido. A compressão de imagens está claramente em desvantagem aqui, uma vez que eles não têm conhecimento prévio do seu espaço de dados, eles não podem realmente fazer nenhuma expectativa sobre isso.

I quero dizer, considere A Cena Demo que é super grande neste tipo de coisa. Eles podem colocar 30 minutos de um atirador 3d inteiro em 64kb porque eles entendem e sabem muito mais sobre seus dados.

Uma comparação muito melhor. A demonstração .kkrieger encaixa 30 minutos de um jogo de tiro 3D, com física, som, texturas e IA em 64kb de dados. Parece uma enorme quantidade de ganho por apenas 24kb a mais do que o original Mario.

P>Vai mostrar, com a quantidade certa de conhecimento prévio sobre seus dados, que você pode fazer grandes coisas com compressão.

Fonte : De onde vêm todos os bytes? - Free Code Camp

Espera que esta informação seja suficiente para entender a magia negra por trás de Mario.