Comment les jeux sur cartouche ont-ils été programmés? [fermé]

Je pense à la SNES, à la N64, à Atari ... même à la DS aujourd'hui, je suppose.

Les jeux SNES ne prennent généralement pas plus de 4 Mo d’espace et les jeux N64 ont une capacité de stockage de 32 à 64 Mo de données.

Ces jours-ci, vous pouvez à peine compiler un "Bonjour le monde!" programme sans la compilation résultante générant 1,21 gigaoctet !! de données. (Blague à part, les fichiers actuels occupent des tonnes et des tonnes d'espace par rapport à certaines technologies de l'époque.)

Alors ... comment l'ont-ils fait?

• En quoi ont-ils programmé ces jeux? ASM? Le tout en ASM?!
• Comment les graphiques ont-ils été créés? De quelle technologie ont-ils eu besoin pour créer des feuilles de sprite et, dans certains cas (comme la N64), des modèles 3D?
• Comment ont-ils pu contenir autant de niveaux, personnages, quêtes et objets sur ces cartouches? Je veux dire, Super Mario World sur la SNES compte environ 1 Mo, et il compte 96 sorties! Ocarina of Time, Banjo-Kazooie, DK64 et quelques autres jeux prennent moins de 64 Mo et ont des mondes gigantesques, des tonnes de contenu et des modèles 3D!

Désolé si mes questions semblent un peu lointaines, je suis simplement étonné que beaucoup de grands titres aient réussi à tenir dans un espace de stockage aussi petit.

C’est fascinant pour moi, car même les fichiers et les jeux les plus insignifiants et les plus insignifiants parviennent à occuper au moins quelques Mo; imaginer que des niveaux aussi élevés que ceux de GoldenEye 007 aient réussi à ne prendre presque aucune donnée est époustouflant.

Ce sont les ressources artistiques et audio qui occupent de la place. Le choix du langage de programmation consistait davantage à tirer le meilleur parti du matériel.

En prenant comme exemple N64, la plupart des jeux en 3ème partie étaient de 8, 12 ou 16 Mo. Les jeux de 32 et 64Mo étaient pour la plupart de Nintendo car il était si coûteux d’envoyer des charrettes aussi volumineuses pour tous. Cela semble minuscule, mais il en va de même pour les ressources artistiques et la production visuelle finale. Vous devez vous rappeler que la plupart des jeux N64 rendus en 320x240 ne sont pas les 1280x760 ou plus d'aujourd'hui. Avec une résolution de sortie aussi réduite, les textures et les sprites étaient bien plus petits qu’aujourd’hui.

En raison du cache de texture minuscule sur le N64, la plupart des textures étaient de 32 x 64 pixels avec une palette de 4/8 bits (couleurs 16/256). Des détails de couleur supplémentaires ont souvent été obtenus en mélangeant des textures et des couleurs de vertex. Les jeux de banjo en sont un bon exemple.

Aujourd'hui, une seule pierre dans un jeu de moteur Unreal aura plusieurs 512x512x24bpp ou même 32bpp. De plus, au lieu d'une simple texture diffuse, vous avez maintenant des cartes normales, des masques spéculaires, des masques de réflexion, des cubes de réflexion et plus encore. Ainsi, un objet qui avait 4 Ko de textures est maintenant couvert par plusieurs Mo de données.

Les vieux jeux ont également une énorme quantité de réutilisation de l'art. Les buissons de Super Mario Bros. sont les mêmes sprites que les nuages, les collines sont les mêmes que les champignons. Différents personnages ne sont que des versions de couleurs différentes des mêmes ressources artistiques. Tout cela a eu pour effet de mieux utiliser chaque texture ou sprite présent sur le panier.

L'audio est une autre grande différence pour les jeux modernes. Presque tout dans le passé était fait avec des pistes séquencées. Maintenant, les deux pistes de musique, les effets vocaux et sonores sont stockés dans divers formats audio compressés. Certes, elles sont plus petites que les données non compressées, mais elles sont toujours beaucoup plus grandes que leurs équivalents séquencés.

Pour ce qui est de la NES (et du SNES surtout), voici un aperçu de base. Je n'ai écrit aucun jeu NES, mais un émulateur NES (Graybox) et fait pas mal d'ingénierie de révision de vieux chariots.

En ce qui concerne le langage de programmation: oui, tout était assemblé. Programmer la NES signifiait travailler directement avec les interruptions matérielles, les ports DMA, la commutation de banque, etc. Heureusement, programmer le 6502 (ou plutôt le 2A03) est assez simple [1]:

• il y a peu de registres: A, X et Y principalement, les deux derniers n'étant utilisables que pour l'indexation et l'itération
• le jeu d'instructions est petit et la plupart du temps simple
• pas beaucoup de mémoire vive: la mémoire vive principale est de 2 Ko, avec une extension optionnelle de 8 Ko sauvegardée par batterie. Sur ces 2 Ko, 256 octets sont réservés pour la pile et la page 0 (les 256 premiers octets) est l'endroit où vous souhaitez stocker vos pointeurs et valeurs les plus utilisés en raison de certains modes d'adressage spéciaux.

Ces trois éléments réunis permettent de créer un environnement assez facile à mémoriser pour l’utiliser. Oui, vous gérez vous-même toute la mémoire, mais cela signifiait essentiellement que vous créiez une carte complète de tout ce qui se passe devant vous et que cette carte n’est pas très grande, car vous devez vous préoccuper uniquement de la distance de 2K. papier quadrillé. Vous deviez planifier un peu plus et affecter statiquement des variables et des constantes aux emplacements de RAM et de ROM (sur des cartouches).

Cela devient un peu plus compliqué une fois que les données de votre cartouche dépassent les limites adressables du processeur. Il s’agit de 64 Ko, dont les 32 Ko inférieurs sont gravés dans la pierre et mappés sur toutes sortes de ports matériels et de RAM. C’est là que la commutation de banque entre en jeu, ce qui implique de mapper une partie de la ROM sur l’espace adresse supérieur (32 Ko).

Ceci peut être utilisé comme le souhaite le programmeur, mais un exemple d'utilisation pourrait être un jeu à 3 niveaux, avec toutes les données de niveau, métadonnées et code pour chaque niveau entassés dans des zones de mémoire distinctes de 8 Ko sur la cartouche. Le niveau peut avoir des rappels pour, par exemple, l’initialisation, la mise à jour par image, etc. Le "chargement" du niveau signifie le mappage de ce bloc de mémoire de 8 Ko à 0xC000, par exemple. Vous pouvez ensuite spécifier que la routine d'initialisation est toujours à 0xC000, que la routine de mise à jour de trame est à 0xC200 et que les données de niveau commencent à 0xC800. Le code principal du jeu, hébergé dans une autre partie de la mémoire, contrôle ensuite les changements de niveau en échangeant simplement la bonne partie et en passant aux adresses absolues 0xC000 et 0xC200 aux moments appropriés.

Wrt graphical data: les données de tuiles de la NES sont des cartes 2 bits 8x8 pixels. Pour le fond, elles sont combinées avec une couche 2 bits à résolution 1/4. Ces valeurs 4 bits ont ensuite été indexées dans une palette de 16 entrées, avec 53 couleurs uniques effectives disponibles. Les sprites ont également utilisé les données de pixel à 2 bits et chaque sprite a spécifié son propre index de groupe à 2 bits, formant à nouveau un index PAL à 4 bits. L'image BG à l'écran est un tableau 32x30 de numéros d'index.

Essentiellement, en ayant une tonne de répétitions et d'index dans les index, vous pouvez garder les données très petites. Les données de niveau étaient souvent stockées sous forme de barres verticales d'index de mosaïques et, comme ces barres verticales étaient également réutilisées, elles étaient également indexées et stockées une seule fois sur la cartouche. Les techniques simples de compression de données fonctionnent de la même manière. Cela a permis à Mario 1 de disposer de 32 Ko de données (avec suffisamment d’espace disponible) et de 8 Ko de données bitmap.

En ce qui concerne les environnements de développement, j'ai vu des photos où des personnes travaillaient sur des ordinateurs certes anciens connectés aux graveurs EEPROM. Le débogage assisté par outil n’était vraiment possible qu’après l’âge SNES [2]. C’est la raison principale pour laquelle tant de vieux jeux contiennent des bugs "évidents" et pourquoi des choses comme Gameshark pourraient faire ce qu’elles font; la santé du joueur sera toujours au mem-location X, vous pouvez donc le forcer à 100 à tout moment.

Si vous trouvez ces choses intéressantes, je vous encourage à consulter, par exemple, http://wiki.nesdev.com/w/index.php/Nesdev_Wiki Il existe assez peu de cours de programmation pour NES également disponibles en ligne.

J'espère que cette vue d'ensemble simplifiée a permis de mieux comprendre le développement de jeux datant des années 80.

[1] Relativement parlant. De plus, je suis partial lorsque j'ai écrit Graybox elle-même dans un assemblage PowerPC d'environ 85%. [2] Voir l'article de FF6: http://www.edge-online.com/features/the-making-of-final-fantasy-vi/.

Il y a beaucoup de sous-sujets dans presque toutes les questions que vous posez. L’optimisation est un vaste domaine à part entière et il ya beaucoup de choses à explorer.

Si vous êtes intéressé par ce type d'optimisation, une des choses que vous pourriez explorer est la demoscene . La demoscene, et certaines de ses cultures artistiques, a depuis longtemps émerveillé de vouloir créer un art complexe pour ordinateurs, qui occupe le moins de place possible. Beaucoup d’entre eux auront des informations sur la façon dont ils ont réalisé certaines ou toutes leurs "astuces".

Il y a souvent un mélange astucieux de sens commun, bien qu'il y ait des "astuces" et des "hacks" spécifiques à un jeu ou à un genre. Souvent, il y a un peu de «chance» en jeu, et une équipe connaissant les limites pour lesquelles elle travaille (peut-être continuellement en butant avec ces limites tout au long du processus), connaissant leurs compromis disponibles et étant disposée à effectuer certains des échanges nécessaires -offs et sacrifices pour atteindre leurs limites.

Voici certaines des choses que je peux penser qui peuvent aider une équipe à obtenir un jeu plus petit.

• Réutilisez ce que vous pouvez: réutiliser les mêmes images-objets et les variations que vous pouvez facilement créer à partir d'une seule image-objet (telles que les réflexions, les rotations, les décalages de palette) vous permettront de gagner du temps. Il en va de même pour le code, la musique et presque tout le reste d'un jeu.
• Compressez ce que vous pouvez: il existe un certain nombre de schémas de compression, et savoir lequel utiliser peut représenter un gain de place considérable. Même parfois, des schémas de compression simples, tels que le codage de longueur d'exécution, peuvent faire une différence surprenante. De plus, il existe des schémas de compression (et des formats alternatifs qui ne sont pas exactement la compression) pour des types de fichiers individuels, souvent avec des compromis de qualité. Par exemple, les fichiers audio wave / CD peuvent être compressés, avec une légère perte d’informations, en fichiers MP3. En outre, les formats de fichier tels que MIDI et les MOD basés sur des échantillonneurs sont des formats alternatifs qui prennent beaucoup moins de place, mais encodent la musique de manière totalement différente et requièrent des compétences différentes pour être efficaces.
• Perdez ce dont vous n’avez pas besoin: pouvez-vous le faire moins cher? Par exemple, pouvez-vous toujours obtenir la "personnalité" d'un caractère en moins de pixels (ou de polygones)? Le placement des tuiles doit-il être défini avec précision par un concepteur ou peuvent-ils être générés de manière aléatoire dans le code de votre programme?
• Le code est souvent moins cher: bien que vous ayez dit en plaisantant combien d'espace compilez un code, il faut maintenant des idées (il y a des raisons pour lesquelles cette "plate-forme" a augmenté au fil des ans, et des moyens de la réduire quand vous en avez absolument besoin), mais en règle générale, si vous pouvez faire facilement quelque chose avec un algorithme, une procédure ou un code, cette approche sera également plus facile à ajuster et à réutiliser pour d'autres actifs similaires mais différents. Les fractales sont un exemple particulièrement facile à comprendre: vous pouvez avoir une image d'une fractale complexe prenant beaucoup de place par rapport à la formule mathématique qui la génère. De plus, la formule mathématique peut avoir des paramètres pouvant générer des images similaires, mais parfois étonnamment différentes.

Quoi qu'il en soit, pour un ensemble de questions aussi important et chargé, nous espérons que certains des sujets ci-dessus constitueront de bons points de départ pour vous permettre d'en apprendre davantage.

Une chose est que je ne suis pas sûr qu'il soit toujours dans l'ère post N64, mais les SNES et N64 ont souvent réutilisé des textures sur d'autres objets 3D, ce qui permet souvent de gagner un espace considérable et de rendre l'art pré-rendu dont les arrière-plans sont souvent fictifs. Une autre astuce consistait à créer un brouillard d'arrière-plan de bordure.

San Francisco Rush N64 avait toujours du brouillard, même si les paramètres pouvaient changer la densité là où l’arcade de San Francisco Rush n’en avait pas et que le Golden Gate Bridge était visible sur la voie 1 par rapport à la version N64.

De plus, les jeux réutilisant souvent de la musique, comme Zelda Ocarina of Time, réutilisent beaucoup de musique, ce qui me gêne, car il aurait pu être fait mieux, comme Banjo Kazooie / DK64 ayant souvent des thèmes à l'intérieur de thèmes!

Zelda Ocarina aurait peut-être eu le Hyrule Overworld puis une version sous-marine du thème si vous plongez sous l'eau ou que les instruments du Thème Boutique reflètent l'espace extérieur où les flûtes et les violons sont utilisés pour le magasin et les cors trompettes pour la boutique et les tambours de la ville du château de Hyrule dans le village de Goron.etc

Dans PC, les modules 3D sont compilés dans des bibliothèques pour y accéder rapidement à l'aide d'un programme permettant de le décompresser, mais je ne suis pas sûr que ce soit le cas avec Nintendo, qui est basée sur une ROM. Le PC est une RAM, c'est comme aller dans une pièce en désordre dans laquelle les choses ne restent pas toujours là où elles sont supposées et où l'information peut être écrasée au point que l'ordinateur ne démarre même pas!

Les consoles de jeu sont des ROM où tout est stocké dans un espace alloué de manière à ce que chaque fois que vous allumez le jeu, il recherche les fichiers dans cet espace alloué avec la garantie qu’il y restera.