Comment les jeux vidéo stockent-ils les informations hors écran?

J'essaie de créer un jeu vidéo à partir de zéro, mais je suis vraiment nouveau dans ce domaine et je continue à rencontrer des problèmes de base. Plus important encore, comment les jeux vidéo stockent-ils les informations hors écran? Ce que je veux dire, c'est comment le programme sait-il quoi afficher ensuite à l'écran? Ou même, si le joueur change l'environnement, comment ce changement se maintiendra-t-il pour la prochaine fois qu'il se chargera sur l'écran?

Par exemple, dans New Super Mario Bros, si vous frappez un? bloquer puis sortir de l'écran, et revenir, il reste touché. Comment ces informations sont-elles conservées puis exécutées la prochaine fois que le joueur charge le bloc? Pourquoi ne se réinitialise-t-il pas simplement?

Habituellement, vous devez séparer l'état logique de votre environnement de jeu de la représentation visuelle.

Le joueur peut ne voir qu'une petite partie de celui-ci sur son écran, mais vous gardez toujours l'état de tout le niveau en mémoire et calculez généralement les mécanismes de jeu pour tout le niveau. Lorsque votre monde est si vaste que cela nécessiterait trop de RAM et / ou de CPU, vous pouvez suspendre les zones plus éloignées du disque dur.

Votre sous-routine de rendu vérifie quelles parties du niveau sont actuellement à l'écran, puis ne dessine que celles-ci. Tout ce qui est hors écran n'est pas dessiné, mais cela ne signifie pas qu'il n'est pas mis à jour.

Vous allez vers l'arrière.

Vous commencez avec l'état logique de votre jeu et modélisez cela. L'ensemble de l'état logique du monde entier sera presque certainement trop important pour être conservé en mémoire à la fois, de sorte que vous le décomposez en parties plus petites qui peuvent être chargées et enregistrées indépendamment. Ces pièces sont souvent appelées morceaux . Ces morceaux peuvent former un monde continu, mais ils peuvent également être des niveaux / instances distincts. La terminologie varie énormément selon le genre et la technique que vous souhaitez utiliser.

Ensuite, vous chargez les parties qui vous intéressent, c'est-à-dire les morceaux qui se trouvent à proximité du lecteur. Les morceaux trop éloignés sont enregistrés sur disque / stockage permanent et déchargés de la mémoire.

Et puis, comme dernière étape, vous déterminez ce qui est réellement visible et créez la représentation visuelle de l'état actuel du jeu et le rendez sur l'écran.

Bien sûr, vous essayez de ne pas reconstruire la représentation visuelle entière à chaque fois, mais de la mettre en cache et de la réutiliser si vous avez des pièces déjà construites, mais c'est le principe principal.

Cela est vrai pour tout programme qui a une sortie. Si vous écrivez un programme avec une interface graphique normale, comme un éditeur de texte, vous modéliserez probablement le document, puis l'interface graphique déterminera l'état et les parties visibles du document et le rendra à l'écran. Ou remplissez les champs du formulaire de manière appropriée, ou bien.

L'essentiel est: Pensez à où et comment vous stockez les données en premier (probablement avec la façon de les représenter). Presque tous les programmes doivent gérer le stockage des données. Il n'y a que très peu de cas dans lesquels vous ne stockez aucune donnée.

Comme d'autres l'ont dit, vous gardez une carte (par exemple dans un tableau) et en dessinez la partie visible à l'écran, et ne lisez pas à partir de l'écran.

Mais dans certains systèmes plus anciens, vous gardiez littéralement les données hors écran. Il y aurait, disons, 400x300 pixels de mémoire vidéo pour un affichage 320x200, et vous définiriez une fenêtre d'affichage dans celle-ci ("commencer à X = 10 Y = 30"). Vous pouvez donc faire défiler l'écran en ajustant simplement un registre. Vous n'auriez pas à dépenser les cent mille cycles nécessaires pour déplacer les octets, vous changez simplement où le matériel vidéo commence à les lire.

Le NES a cela, combiné avec un système basé sur des tuiles: http://wiki.nesdev.com/w/index.php/PPU_scrolling

Le NES ne construit jamais l'image complète en mémoire, car il n'a pas assez de RAM. Au lieu de cela, il existe un tableau RAM qui définit un ensemble de tuiles sur deux écrans. Un octet par type de tuile. Le matériel vidéo recherche la mosaïque et les coordonnées de décalage X / Y afin de décider quel pixel doit apparaître à tout moment.

Eh bien, si vous posez ce genre de question, vous allez avoir un long chemin pour arriver au point où vous pouvez faire un jeu. Mais, au cœur de votre question, le programme peut enregistrer l'état de nombreuses choses différentes dans des variables qui sont à l'arrière de votre programme. Regardons quelques exemples.

Mario Brothers (ou similaire) enregistre l'état du niveau dans lequel vous vous trouvez. Cela peut comprendre jusqu'où vous êtes allé avant de mourir, si un bloc a été touché ou non. Dans un sens plus orienté objet, le jeu dit simplement "être un bloc ici" et le bloc existe. puis lorsque vous frappez le bloc, le bloc change son propre état interne pour dire "J'ai été touché". De telles données peuvent être stockées de différentes manières.

Votre traitement de texte enregistre ses données dans une structure de données. Maintenant, il existe de nombreuses et de nombreuses façons de les implémenter, mais il utilise probablement une forme d'arbre. Dans un arbre, vous avez au moins un nœud. Tout ce qui a été ajouté avant d'aller à gauche. Tout ce qui est ajouté après, va à droite. Après avoir ajouté trois nœuds, vous en avez deux suspendus au nœud central. Et l'arbre peut devenir encore plus grand avec de nouveaux morceaux ajoutés n'importe où et l'arbre se reconstruira lui-même. Ou pensez aux jeux de tir où votre ennemi se promène. Chacun d'eux a des variables qui suivent leur emplacement, leur vie, etc. de sorte que lorsque vous en blesserez un, il se souviendra qu'il a été blessé.

Toutes ces choses nécessitent une connaissance des structures de données. Cela va bien au-delà de ce que vous voyez à l'écran. Je suggère de lire sur les tableaux, les listes, les hachages (parfois appelés dictionnaires ou cartes), puis de revenir à votre problème.

Voici quelques bons matériaux de départ:

• http://visualgo.net/

Dans une certaine mesure, cela dépend du rendu de la 3D. Par exemple, OpenGL éliminera automatiquement la géométrie en dehors de la plage -1,0, +1,0 dans l'espace d'écran XY (Z est plus complexe mais similaire). La géométrie éliminée ne génère jamais de fragments (environ pixels) et n'est donc jamais transformée en imagerie réelle, malgré son envoi au système pour le rendu. Dans tous les cas, il est impossible d'écrire dans un espace en dehors de la fenêtre de rendu (si tout fonctionne comme il se doit).

Dans certains contextes, il suffit de s'appuyer sur ce comportement comme optimisation. Cependant, vous devez toujours passer toutes vos données de jeu à travers au moins une étape de rendu (vertex shaders) avant que la carte vidéo puisse savoir ce qui est visible. Dans quelque chose comme, disons, Skyrim, ce ne serait pas pratique. Non seulement vous devez envoyer tous les sommets du monde via le pipeline de rendu, mais vous devez également charger chaque sommet dans la mémoire système / vidéo. C'est inefficace, voire possible.

Ainsi, de nombreux jeux utiliseront l'abattage basé sur le processeur. Ils mettent généralement en œuvre une sorte de système de niveau de détail (niveau de détail), dans lequel la qualité et l'existence des actifs sont influencés par l'importance qu'ils sont évalués pour être dans un contexte donné. Un maillage pyramidal peut être une approximation acceptable pour une montagne si vous êtes à 80 kilomètres de là. Si vous ne pouvez pas le voir du tout (comme il est bloqué par d'autres montagnes), il n'est même pas nécessaire de le charger. Il existe un certain nombre de méthodes plus complexes pour ce faire qui sont des sujets qui, selon moi, ne sont pas directement liés à la profondeur demandée par cette question, mais regardez la tessellation pour l'un des exemples les plus courants.

L'essentiel est que les visuels ne sont que le produit du jeu. Les données réelles n'ont rien à voir directement avec ce que vous voyez ou ne voyez pas la plupart du temps, et les données sont filtrées par différentes étapes pour supprimer les informations superflues avant d'atteindre le point où une image est écrite à l'écran. Selon la conception du moteur, les visuels peuvent être extrêmement dissociés de la logique du jeu, dans la mesure où quelque chose comme avoir une interface 2D et 3D avec le même jeu est une possibilité. Il est même possible pour de nombreux moteurs de jeu de fonctionner sans aucune sortie; Parfois, cela est utilisé pour tester l'IA du jeu.

C'est là que les choses peuvent se compliquer, cependant. Dans quelque chose de simple comme un jeu Mario, il n'est pas trop prohibitif de calculer le mouvement de tous les ennemis dans le niveau, même s'ils ne sont pas visibles. Dans les contextes modernes, ce qui se passe hors écran est une véritable question à considérer sérieusement. S'il y a plusieurs villes entières de PNJ, comment gérez-vous leur comportement lorsqu'ils sont complètement éliminés - comme lorsque le joueur se trouve dans une ville différente? Voulez-vous vraiment calculer des centaines de décisions de PNJ sur toute la carte? La réponse est généralement non, mais l'approche exacte à suivre pour ne pas le faire peut varier et cela peut avoir des répercussions sur le jeu.

Il est important de noter que c'est ainsi que les choses fonctionnent maintenant . Les anciens jeux Mario eux-mêmes étaient probablement programmés de manières très différentes (je ne peux pas parler des moyens exacts), étant donné les limites matérielles extrêmes de l'époque. Le concept de la 3D n'existait pas à l'époque; pourtant aujourd'hui, presque tous les jeux, même ceux qui sont entièrement en 2D, utilisent le rendu 3D sous une certaine forme, même s'ils ne le savent pas. Le matériel vidéo moderne est d'abord 3D, et le rendu 2D (au moins lorsqu'il utilise correctement le matériel) ignore simplement la 3ème dimension.

Pour répondre à votre question: les jeux vidéo gardent l'état du monde du jeu dans une structure de données abstraite qui n'a rien à voir avec l'écran. Ceci est ensuite rendu à l'écran selon les besoins (c'est-à-dire, selon l'endroit où se trouve le joueur).

Les jeux qui utilisent la RAM vidéo directement à des fins d'état existaient dans les années 80 en 8 bits, peut-être même à l'ère 16 bits, mais à moins que vous ne développiez pour cette plate-forme ou pour certains µC qui concentrent sa RAM en Ko à la place de GB, oubliez ça.

Cela dit, vous semblez être très nouveau dans tout ce qui touche à la programmation, sinon la question ne se poserait pas. Je suggère de procéder pas à pas, en programmant d'abord des choses très faciles; peut-être quelque chose qui n'a que des entrées / sorties textuelles (invites simples et tout ça). Pour être honnête, le moment où je l'ai fait est d'environ 30 ans, donc je n'ai pas vraiment de bonnes ressources pour vous, mais votre bibliothèque locale pourrait être meilleure qu'Internet pour vous donner un très bon départ dans la programmation.