Comment les anciens jeux tenaient-ils sur si peu de place ?

[Watcha]

Bonjour à tous,

je pose ici une question assez technique. Cette question m'est venue en regardant les poids que pesaient les jeux sur NES ou sur Master System, voire, encore avant, sur Atari 2600.

Je prends quelques exemples pour expliquer à quel point le peu de place/poids de ces jeux m'a surpris, même en sachant que les pixels étaient plus gros et moins nombreux à l'époque.

- Le premier Zelda de la NES ne faisait que 128 Kio, soit environ 130.000 octets. Quand on sait que ce jeu contenait des centaines d'écrans différents (sur la carte du monde et dans les donjons), je me demande comment ce jeu pouvait tenir sur aussi peu de place.

- Exemple encore plus frappant : la même année, sortait Super Mario Bros, qui ne faisait que 40 Kio, soit environ 40.000 octets !

- Et j'oublie de citer les jeux Atari 2600, qui ne dépassait que très rarement les 16 Kio, et qui ne faisaient le plus souvent que 4 Kio ! :8I:


Bref, je me demande donc, au-delà de la qualité de ces jeux, comment, techniquement, autant de données pouvaient tenir sur aussi peu de place.

Si il y a un programmeur ou un connaisseur dans l’assistance, je le remercie d'avance pour ses éclaircissements.

Merci bien.

[oiseau de proie]

C'est sympa de voir les jeunes s’intéresser à cet aspect

Alors il y a plusieurs facteurs qui font que ça prenait si peu de place.
Il y a 3 éléments qui mangent des octets et comme tu t'en doutes les coupables sont le code, les graphismes et la bande son.
Les jeux d'aujourd'hui sont bien plus complexes et pour certains on atteint un chiffre avec 6 zéros derrière en termes de lignes de code !
Autant dire que ça va prendre de la place à la fois sur le support mais aussi en mémoire; choses qui faisaient défaut pour les consoles que tu as évoqué.
Rien que cet aspect va prendre plusieurs mégas octets sur le CD et en mémoire.
Sur NES ça prend quelques dizaines de Ko voir moins pour les plus basiques...

Pour les graphismes continuons avec la NES comme point de comparaison.
Une simple image 1080p (1920x1080) en 32 Bits pèse pas loin de 8Mo sur PC.
Cette seule et unique image ne rentrerait même pas dans une cartouche NES qui contient en moyenne de 32 à 256Ko :)
Sur NES un écran 256x240 en 16 couleurs prendrait environ 30Ko.
Mais en pratique c'est plus compliqué que ça car un écran est composé avec ce qu'on appelle des tiles.
Ce sont des motifs qui font 8 pixels de large sur 8 pixels de haut et qui peuvent comporter 4 couleurs maximum et pour un poids de... 16 octets seulement :)

Regarde cette capture d'écran :

Comme tu peux le constater en regardant attentivement, il suffit de peu de motifs pour constituer le décor, c'est assez répétitif et ça ressemble souvent à des blocs assemblés.
Là ils ont une taille de 16x16 (découpé ensuite en 8x8 en interne) et à la louche une demi douzaine sont utilisés pour composer cet écran (x4 ensuite).

Avec cette technique, certains jeux NES n'ont besoin que d'une trentaine de Ko pour tout le jeu !
Ils sont tous regroupés sur une seule page et tu pioches dedans pour dessiner tes cartes (map).
Une image de 256x240 sur la cartouche pourrait contenir 960 tiles.
Après selon les éditeurs, l'année et le type de jeu, on peut en trouver nettement moins ou bien plus sur la dite cartouche.
Pour les décors extérieurs il me semble qu'il y a 128 tiles de 8x8 pour Zelda.

Pour le son c'est différent, aujourd'hui les musiques et les bruitages sont constitués de sons numérisés (appelés sons digitalisés en franglais).
ça prend beaucoup de place, un son d'une minute en 44,1KHz 16 Bits (standard CD) mono prend 5.28 Mo.
Autant dire qu'utiliser ce genre de son est une impasse car ce seul son d'1mn ne rentrerait pas dans une cartouche NES.
A l'époque on devait faire autrement, ce sont les puces sonores qui créait en temps réel le son contrairement à aujourd'hui où on lit des sons qu'on a préalablement enregistrés.
C'est pour cela que les musiques de tous les jeux ont toutes le même rendu car elles dépendent des possibilités de la puce.
Le musicien peut trifouiller des ondes carrés ou triangulaires sur 3-4 canaux.
Toutes les musiques de Zelda tiennent dans seulement 5Ko grâce à ça :)

Voilà, j'espère que j'ai été assez compréhensible, dans le cas contraire n'hésite pas à poser des questions.

[nicolpodo]

Merci c'etait super interessant, technique mais accessible. C'est ton domaine de travail ?

[Invité]

Très intéressant ODP :)

[oiseau de proie]

Merci c'etait super interessant, technique mais accessible. C'est ton domaine de travail ?

J'ai bidouillé chez moi dans ma jeunesse sur des ordis, c'était plus intéressant que les cours de programmation quand j'étais étudiant :)
Mais la pratique n'est pas forcément nécessaire pour comprendre tous les aspects, lire des docs hardware ou des kits de dev d'une machine permet d'assimiler beaucoup de choses.
Néanmoins je n'ai jamais travaillé dans une boite de jeu vidéo contrairement à mon frangin.

L'aspect technique m'a toujours intéressé, j'aime savoir comment ça marche et à tous les niveaux, code, graphisme et son.
Quand on est curieux on apprend beaucoup choses et ça rentre assez bien si on aime la chose en question :)

Je suis content que ça vous plaise à toi et Shenmue III, j'avais peur que mes explications soient trop obscures ou brouillonnes.

[Invité]

Non c 'est bon ça se li bien.

[Azerty0210]

Merci ODP, super intéressant!

[Invité]

Très bonne explication, très accessible, pour tout le monde.

Cependant tu as oublié une toute petite partie.
La taille n'a plus vraiment de limite a notre époque. Du coup, il n'est plus nécessaire d'optimiser le code.
Ce qui fait que certaine partie de code pourrait être simplifier ne le sont pas car le coût d'optimisation serait supérieur a celui de l'espace utilisé.
C’était exactement la philosophie opposé à l’époque. L'espace était de 36Ko, pas 37. Il fallait faire avec quoi qu'il en coûte. Et il était peu envisageable d'utiliser une deuxième cartouche pour coller le 37iem Ko.

[Watcha]

Merci beaucoup, ODP, pour cette explication tout à fait claire :)

Je savais déjà pour le son, mais pas pour le code et les graphismes, et je te remercie d'avoir pris le temps de rédiger ta réponse à une heure aussi tardive.

Merci encore.

[rafifoudu31]

Oiseau de proie, tu viens de m'apprendre plein de choses, merci beaucoup !

[Azerty0210]

Cela serait sympa de l"épingler d'ailleurs!
ODP tu penses pouvoir faire un petit topic la dessus?

[barbarian_bros]

Pour les graphismes on peut même aller plus loin :
Là où aujourd'hui un personnage est un modèle 3d complexe composé de plusieurs milliers de polygones (déjà plusieurs Mo pour le modèle), sur lequel on plaque des textures de plus en plus nombreuses et détaillées (dans Quake c'était 1 texture par perso, maintenant c'est un texture pour les cheveux, une autre pour la peau, un pour le pantalon, etc...).
Alors que dans la plupart des jeux 2D il y avait des planches de sprites. Sur une image de la taille de l'écran, un perso était dessiné 8 fois avec un mouvement décomposé en 2-3 images (rarement plus) ce qui fait que sur une seule image 'plein écran' on trouvait jusqu'à 4 mouvements décomposés. Ensuite il suffit d'indiquer quelle partie de l'image on affiche, comme pour les 'tiles' des décors.

Un jeu pourtant très animé et détaillé comme Metal Slug n'utilise qu'une seule image par personnage, il doit y en voir une supplémentaire avec les animations de 'mort' des 4 persos principaux, soit 5 images pour 4 personnages, et ça c'est sur Neo-Geo, sur ST et Amiga c'était en général une seule image par perso, et sur les consoles 8bits c'était même plusieurs persos par image (là on peut voir le saut décomposé en 9 sprites, c'est énorme, beaucoup de jeux n'en auraient utilisé que 4).



Goldsugar souligne un autre point important :
Quand sur les anciennes machines il fallait que le programme tienne compte des spécificités de la machine, les programmeurs optimisaient leur code pour qu'il prenne moins de place ou qu'il s’exécute plus vite.
Sur C64, il fallait que le programme rentre dans les 64 ko de RAM de la machine, y'en avait pas un 65ème. Donc il fallait absolument optimiser le code.
Quand on portait un programme Amiga sur Amstrad, une fois l'aspect graphique et sonore rabaissé aux capacités de la machine, il fallait encore largement optimiser le code pour qu'il s'exécute beaucoup plus vite et éviter que ça rame sur un processeur plus lent et moins puissant.
Pareil à l'époque de la Playstation : le jeu devait entrer sur 1 CD (ou plusieurs si ion mettait plein de cinématiques), mais surtout l'affichage devait prendre en compte la minuscule mémoire vidéo de la machine, couplée à un lecteur CD lent (2x), fallait pas que les images soient trop grosses sinon ça rentrait pas.

Maintenant le jeu sort pas fini (pas grave on mettra un patch sur le PSN ou le Live, ou on vendra la fin en DLC), et si jamais on a un jeu pas optimisé (avec des affichages et des chargements trops longs sur le pauvre lecteur DVD/Bluray... on oblige le joueur à utiliser 20Go d'espace disque dur...(sympa pour ceux ayant acheté une consoels avec unpetiti disque ou pas du tout de disque dur). On va pas payer les programmeurs à optimiser le code, ça coute trop cher.

Sur ordis c'est encore pire : sur ST et Amiga à partir de 90 il fallait absolument avoir une extension de RAM (1Mo) pour profiter vraiment des jeux qui devenaient plus gourmands (certains tournaient avec 512ko de RAM, mais sans musique par exemple).
Mais pour les graphismes et la 3D, les programmeurs devaient optimiser leur code et innover pour tirer toujours plus de capacités d'un matériel vieux de plus de 5 ans.
Sur PC on a très vite eu la logique inverse : si la machine est pas assez puissante, faut changer le processeur et/ou la carte graphique, quant au stockage : le jeux sont prévus pour s'installer entièrement sur le disque dur, et depuis longtemps.

[Noelfhim]

Une petite précision pour la partie code (et j'essaierai de trouver du temps pour aller sur le topic des présentations, que je déteste) :

Prenez un linux (parce que c'est ce que j'avais sous la main pour faire un test rapide), faites un simple "Hello World", le bête programme d'exemple qui affiche jute ce texte. J'ai déjà 7159 octets d'utilisés. Oui : 8Ko pour faire coucou. Et sous windows c'est pire !

Après on peut essayer d'optimiser un (petit) peu mais imaginez si vous voulez rajouter le réseau (qui est finalement assez complexe à coder)...

La raison est simple : il faut discuter avec l'OS et embarquer des bibliothèques (code tout prêt) là où avant on attaquait directement le matériel avec du code assembleur (quite à recoder à chaque fois la même chose). L'être humain étant (heureusement) feignant et la limitation de place étant tombée, on a pris nos aises. On code plus vite, c'est plus facile, mais par contre ça prend plus de place, d'autant qu'on n'a pas forcément besoin de toutes les fonctions ajoutées au code.

Régis.

[Invité]

Bonjour Noelfhim, n'oublie pas de créer un topic pour te présenter dans la section dédiée, on pourra d'y souhaiter la bienvenue. :)