D'où viennent tous les octets?

Excellente question Dion! Je vais y répondre, et pas seulement parce que vous êtes mon nouveau patron, mais parce que c'est une bonne question. (mais aussi parce que tu es mon nouveau patron.)

Je veux cependant clarifier quelque chose ici: nous ne comparons pas vraiment des pommes aux pommes, définissons donc d'abord certaines technologies.

Comment fonctionne Mario

Parlons donc du fonctionnement du jeu original de Super Mario, du point de vue des actifs.

La console NES d'origine a été conçue uniquement pour produire des images de 256 de large sur 240 de haut; Cela signifie que l'image finale qui devait être affichée à l'écran avait une taille de 180 Ko.

En plus de cela, la NES ne disposait que de 2 Ko de RAM. Une cartouche elle-même pourrait contenir 8k à 1 Mo de données de jeu. Il n'y avait donc aucun moyen de mettre tout le contenu du jeu dans la mémoire principale. Fondamentalement, un sous-ensemble des données de la cartouche de 1 Mo doit être chargé dans la RAM de 2 Ko et utilisé pour rendre l'écran de 180 Ko. Comment y parvenir?

SpriteSheets.

Les feuilles de sprite contiennent de petits carreaux de graphiques, qui sont réutilisés encore et encore. Par exemple, ci-dessous est un remake de la feuille de sprite originale de super mario:

Chaque petit carré de 16 x 16 pixels représente une «tuile» et les artistes les enchaîneraient pour créer les niveaux réels. Les niveaux eux-mêmes sont devenus un tableau 2D géant d'index dans la feuille de sprite. (J'en parle beaucoup plus en détail dans la leçon 3 de mon cours de développement de jeux HTML5 @ Udacity, ou dans mon livre HTML5 Game Development Insights.) Apprenez à utiliser l'encodage Run-Length-Encoding, ou un LZ77 de base, et vous obtenez un format assez compact pour les niveaux.

Ainsi, avec des concepts tels que les feuilles de tuiles et les feuilles de sprite, nous pouvons utiliser un petit ensemble d'images pour créer de grandes scènes et des mondes. C'est généralement ainsi que fonctionnent la plupart des jeux. Même les jeux 3D auront un ensemble de textures communes qui seront appliquées plusieurs fois et à plusieurs endroits tout au long du jeu lui-même.

Parlons maintenant de la compression d'image générique.

Comment les images sont compressées

Voici la partie « pas juste » de cette comparaison. Les algorithmes génériques de compression d'image n'ont aucune connaissance du domaine des pixels qu'ils contiennent. JPG, PNG, WebP ont tous été conçus pour les photos et pas tant pour les écrans de jeux . Le résultat est que pour un bloc de 16x16 pixels donné, ces algorithmes supposent qu'il est unique parmi l'image; Outre une certaine quantification des couleurs, aucune logique réelle n'a été ajoutée pour déterminer si un autre bloc 16x16 pourrait être une copie exacte du bloc actuel. Cela signifie généralement qu'il existe une limite inférieure sur la façon dont un bloc de données donné est compressé.

Par exemple, JPG divise une image donnée en blocs de 8 x 8 pixels, convertit l'espace colorimétrique RVB dans la version YCbCr, puis leur applique une transformation en cosinus discret. Ce n'est qu'après cette étape qu'un encodeur sans perte arrive et voit s'il peut faire correspondre les groupes de doublons courants à l'aide de DPCM ou RLE.

Ainsi, le seul endroit où deux blocs peuvent être compactés en un seul bloc est si leur version post-DCTd est identique et RLE peut faire des recommandations de pas. Cela n'arrive pas souvent.

Malgré ses autres défauts, la PNG est bien meilleure à cet égard. La compression PNG est entièrement sans perte (donc la qualité de votre image est élevée, mais vos économies de compression sont faibles) et basée sur le codec DEFLATE, qui associe LZSS à la compression arithmétique. Le résultat est que de longues séries de pixels similaires peuvent finir par être réduites à une taille beaucoup plus petite. C'est pourquoi une image avec un arrière-plan très uniforme sera toujours plus petite en PNG au lieu d'un JPG.

L'image ci-dessous est un fichier PNG de 5,9 ko, tandis que l'image JPG est de 106 ko

Pommes contre fruit du dragon

Ce que je veux dire ici, c'est qu'il est un peu injuste de comparer le contenu du jeu à une seule image sur Internet.

Du côté du jeu, vous commencez avec un petit ensemble de tuiles réutilisables et vous les indexez pour construire votre image plus grande, nous pouvons le faire, car nous savons comment le jeu va être fait. De l'autre côté, JPG / PNG / WebP essaie simplement de compresser les données qu'il peut trouver dans des blocs locaux, sans réelle volonté de faire correspondre le contenu répété. La compression d'image est clairement désavantagée ici, puisqu'ils n'ont pas de connaissances préalables sur leur espace de données, ils ne peuvent pas vraiment faire d'attentes à ce sujet.

Je veux dire, considérez The Demo Scene qui est super important sur ce genre de chose. Ils peuvent entasser 30 minutes d'un jeu de tir 3D entier dans 64 Ko parce qu'ils comprennent et en savent beaucoup plus sur leurs données.

Cela montre simplement qu'avec la bonne connaissance préalable de vos données, vous pouvez faire de grandes choses avec la compression.

Avoir hâte de.

De toute évidence, nous avons grandi depuis les écrans 256x240 des jours NES. Le téléphone dans ma poche a 1 920 x 1 080 pixels d'affichage à sa taille de 5,2 pouces, ce qui lui donne une densité d'environ 423 pixels par pouce. Pour comparer cela dans le même nombre de pixels, c'est ~ 33 écrans super-mario, ou plutôt 8 Mo de données de pixels. Je ne pense pas que quiconque soit surpris que les résolutions d'écran augmentent, mais cela entraîne également le besoin de plus de données .

C'est quelque chose sur lequel j'insiste depuis un moment maintenant. Alors que nous obtenons des écrans plus grands, les canaux de contenu doivent augmenter leurs sorties de résolution afin de toujours bien paraître sur nos configurations à haute densité (sinon, nous obtenons un flou de mise à l'échelle ..). Cela entraîne bien sûr une augmentation de la taille de nos packages de jeux vidéo, une augmentation de la taille de nos pages Web et même une augmentation de la taille de nos vidéos en streaming sur YouTube. Fondamentalement, nous envoyons plus de données à des appareils plus petits simplement en raison de la résolution de l'écran. Ce qui, pour les 2 prochains milliards de personnes dans les marchés émergents, sur les connexions 2G, est comme la pire idée qui soit.

Mais je m'éloigne du sujet. C'est un article différent.