Est-ce que tous les jeux sont faits en dessinant chaque image?

60

Je suis un débutant en apprentissage de l'animation par ordinateur (pour les jeux). Jusqu'à présent, la seule méthode que j'ai rencontrée consiste à dessiner chaque image, chaque mise à jour. Ainsi, au début de chaque image, la totalité de l'image est effacée, puis les éléments nécessaires à cette image sont redessinés.

Ma question est de savoir si cette méthode est la seule utilisée pour créer des animations et des jeux. Il semble que c'est un peu inefficace. Je ne comprends pas non plus très bien comment cette méthode fonctionnerait pour les jeux en 3D . Quelqu'un pourrait-il s'il vous plaît expliquer cela plus en détail?

eeze
la source
Les commentaires ne sont pas pour une discussion prolongée; cette conversation a été déplacée pour discuter .
Josh
John Carmack a presque inventé l'approche sur PC consistant à faire défiler l'écran en plein écran en dessinant uniquement la fine tranche verticale de l'écran qui a été modifiée. Les PC n'étaient tout simplement pas en mesure de mettre à jour l'affichage plein écran assez rapidement sans cette technique. Il l'a utilisé dans de nombreux jeux 2D au début des années 90, tels que le commandant Keen. Lisez "Masters of Doom" pour plus d'informations.
Cendres

Réponses:

68

Les très vieux jeux utilisaient une technique qui consistait à redessiner uniquement les parties d’un cadre modifiées sur celui-ci. Ce dont je me souviens, le jeu "Little Big Adventure" utilise cette technique (1994). Mais vous pouvez voir que le jeu a pour la plupart du temps une caméra statique. ce n'est que lorsque vous quittez la zone visible que la scène est redessinée. Si vous jouez au jeu, vous remarquerez également un léger décalage sur cette image. Sur les GPU modernes dotés de moteurs de jeu modernes, les choses ont changé. Tout est redessiné sur chaque image. Selon la technique de rendu, les choses peuvent même être rendues plusieurs fois. La puissance de calcul d'un GPU est incroyablement élevée lorsque vous l'utilisez correctement. Mais la réutilisation est en cours. Par exemple, un moteur pourrait décider de mettre à jour la carte fantôme uniquement toutes les 5 images. Ou bien l'éclairage n'est pas mis à jour tant qu'il n'y a pas de changement dans les sources lumineuses.

Arne
la source
23
Ce ne sont pas que des vieux jeux. Chez EA, on s'est efforcé de réduire l'utilisation de la batterie pour certains jeux "occasionnels", et l'une des techniques consistait à ne redessiner que des parties de l'écran. Vous pouvez parfois voir cela dans Les Sims 3 si vous laissiez la caméra immobile et si un sim traversait l'écran, il y avait parfois un bug où le redessin n'était pas assez grand et vous verriez des pixels laissés derrière dans une ligne à travers le écran. Il suffisait de déplacer légèrement la caméra pour forcer un nouveau tracé et la ligne disparaîtrait.
Kevin Fee
12
Très vieux .. 1994 ... Je me sens vieux maintenant ...
alseether
4
@ alseether old en termes de jeu. Rappelez-vous que nous sommes passés de blobs de pixels de 8 bits au réalisme photographique (dans des cinématiques pré-rendues si ce n’est une action réelle) en seulement 20 ~ 30 ans.
Jared Smith
16

Non.

Du moins si vous incluez des vieux jeux des années 70 qui utilisaient des affichages vectoriels.

Par exemple, le jeu bien connu Asteroids, qui a été développé à l’origine pour les affichages vectoriels, est une manière fondamentalement différente de rendre des graphiques à un écran.

Des moniteurs de vecteurs ont également été utilisés par certains jeux d'arcade de la fin des années 70 au milieu des années 80 tels que Asteroids, Tempest et Star Wars. Atari a utilisé le terme Quadrascan pour décrire la technologie utilisée dans les salles de jeux vidéo.

https://en.wikipedia.org/wiki/Vector_monitor

Les graphismes modernes sont conçus à 100% pour le rasterizaton, qui écrit par définition le contenu d’un tampon graphique sur l’affichage de chaque image.

Sandy Chapman
la source
7
Les écrans vectoriels n'ont même évidemment pas de "cadre".
Hobbs
2
@hobbs Correct, ce qui rend ma réponse toujours correcte puisque la réponse à "Tous les jeux sont-ils créés en traçant chaque image?" est "Non, même tous les jeux ne s'appuient pas sur des cadres."
Sandy Chapman
1
cependant, dans un sens plus profond, la question portait sur le dessin répété de tous les éléments visibles, pas seulement des éléments qui bougent, et pour la plupart des écrans vectoriels, la réponse est toujours "oui" (le tube de stockage des images serait une exception)
szulat
@szulat d'une manière qui est vraie, mais pour être juste, cela ne tire toujours pas dans les espaces où l'affichage est noir. Il actualise uniquement les éléments visibles à l'écran. En astéroïdes, il ne fait que redessiner le vaisseau et les astéroïdes restants à l'écran.
Sandy Chapman
@ SandyChapman et à un autre niveau, il y a vraiment peu de différence. un jeu met à jour la mémoire d'écran ou les images-objets lorsque quelque chose change. sinon, la partie correspondante de l'affichage reste statique. Ceci est vrai pour les systèmes vectoriels et raster - «astéroïdes» gère l'actualisation de l'écran à partir de la mémoire d'écran (vectorielle!) sans déranger le processeur, de la même manière que le matériel du spectre zx génère son signal vidéo raster. Le fait que le faisceau réel ou imaginaire dessine des polygones ou balaye l'écran selon un motif fixe est secondaire.
dimanche
11

Au niveau le plus bas, le processeur graphique de votre ordinateur calculera chaque image à partir de la base et l’enverra à votre écran. Vous ne serez exposé à cela, cependant, que si vous gérez vous-même ce genre de choses de bas niveau. [1] Tout moteur graphique (et avec cela, le jeu) supportera ces choses pour vous, et vous êtes libre d'exprimer la scène. en termes de nombreuses entités que vous pouvez modifier entre les cadres, mais seront persistantes.

... comment cette méthode fonctionnerait pour les jeux 3D ...

Les éléments dans l'espace 3D sont persistants, le moteur graphique recalculera à nouveau l'image sur votre écran pour tenir compte de tous les changements survenus (mouvement de la caméra, etc.).

[1] ... par exemple si vous écrivez votre propre moteur [2] avec quelque chose comme OpenGL. Même dans ce cas, vous stockeriez probablement des choses persistantes entre les images.

[2] Ce qui n'est pas une option à votre niveau de compétence actuel.

TauCraft
la source
Avez-vous des références pour prendre en charge "le processeur graphique sur votre machine calculera effectivement chaque image à partir de zéro"?
Kromster dit de soutenir Monica
@Kromster: C'est surtout une question d'efficacité. Comme chaque trame peut nécessiter un calcul complet et qu'il est incertain que les parties ne le fassent pas, vous aurez besoin d'un calcul coûteux pour déterminer exactement quels bits pourraient être sauvegardés. Même s'il s'agissait d'une amélioration nette de la performance, cela entraînerait des taux de trame incohérents.
MSalters
@MSalters comme il est formulé, contredit beaucoup de points dans de nombreuses réponses de voisins.
Kromster dit de soutenir Monica
Je dirais que l'affirmation "le processeur graphique sur votre machine calculera effectivement chaque image à partir de la base" est techniquement fausse. Le GPU calcule exactement ce que vous lui dites. Si vous voulez qu'il réutilise le cadre précédent, alors il le fera (en fait, c'est sa valeur par défaut). De nombreux moteurs de jeu modernes (et même les interfaces graphiques des systèmes d'exploitation) choisissent de commencer à partir de zéro (où l'image précédente n'est affichée que si la nouvelle image n'a pas fini de s'afficher à temps), mais ce n'est pas obligatoire.
Ove
Je ne suis même pas sûr de ce qui constituerait une référence pour "l'écran doit être effacé", mais j'ai une référence sur la manière dont un cadre est rendu dans Doom: adriancourreges.com/blog/2016/09/09/doom-2016- étude graphique ; N'oubliez pas qu'une carte graphique moyennement haut de gamme devrait être capable de gérer un billion de calculs par seconde, plusieurs milliers par pixel.
pjc50
2

Réponse courte: non

Longue histoire:

Lorsque j’ai appris la programmation de jeux à l’école, on nous a appris à:

Décidez quel taux de fps nous voulions dans le jeu (30 par exemple).

Écrivez un code qui ajoute 1 à un compteur pour chaque intervalle (33 ms pour 30 ips). Ce code est exécuté en même temps que la boucle de jeu.

Ensuite, la boucle de jeu qui effectue les calculs pour le jeu (mise à jour de l’état du jeu) réduira le même compteur de 1 pour chaque image. Mais les calculs graphiques et le dessin à l'écran ne seront effectués que si le compteur est à zéro.

Le résultat est que la cadence graphique va s'ajuster en fonction de la manière dont l'unité centrale gère les calculs en jeu. Lorsque le jeu n’est pas excessif, les calculs sont faciles et la cadence graphique est supérieure à la mise à jour réelle de l’état du jeu (gaspillage de cycles puisque nous dessinons le même état plus d’une fois à l’écran).

Mais alors beaucoup de choses se passent dans le jeu, le processeur aura plus de travail à faire et les mises à jour de l’état du jeu seront priorisées par rapport au dessin à l’écran.

La plupart du temps, le jeu continuera à se mettre à jour à la vitesse souhaitée, mais il apparaîtra "en retard" car vous ne verrez pas chaque mise à jour à l'écran. Cela peut être préférable au ralentissement du jeu car vous le forcez à dessiner chaque mise à jour à l'écran.

Tout cela a été fait avec C ++ et sans moteur de jeu, ni carte graphique. Tout a fonctionné sur un seul processeur central. Nous avons utilisé des bibliothèques pour les graphiques 2D.

utilisateur985366
la source
1
Je me souviens du jeu "Golden Axe". Lorsqu'il était joué sur 8086, le jeu était plus lent et beaucoup plus facile à gérer que celui joué sur 286, par exemple lorsque la situation évoluait plus rapidement. Juste FYI.
akostadinov
0

Avant que l’on puisse dire si les jeux vidéo "dessinent" l’affichage à chaque image, il faut d’abord définir ce que l’on entend par "dessiner". Il existe certainement de nombreux jeux vidéo qui ne dessinent certainement pas chaque image en assemblant une bitmap à partir de zéro; En effet, de nombreuses plates - formes de jeu ne se réunissent bitmaps plein du tout .

Il existe quelques approches que les jeux vidéo peuvent adopter pour générer un affichage. Un très petit nombre de fois que le processeur allume et éteint le faisceau d'électrons ou pour chaque pixel ou, pour les jeux à balayage vectoriel, définit la coordonnée XY de chaque point à tracer. La plupart des jeux qui le font le font principalement pour démontrer que le processeur est assez rapide. Plus généralement, les jeux auront un matériel qui, en l'absence d'implication de la part du processeur, afficherait de manière répétée un motif de pixels ou de vecteurs sur l'écran. Ce motif peut être produit en lisant les données séquentiellement dans une région de la mémoire et en interprétant chaque bit ou groupe de bits comme une couleur de pixel (on parle d'affichage bitmap). Dans certains cas, le matériel peut lire un octet de mémoire pour chaque unité 8x8, 16x16, ou une autre région de taille de l’affichage, puis utilisez cet octet pour sélectionner une plage de mémoire à lire pour les données de pixels (on parle souvent d’affichage de carte de caractères). Certaines plates-formes matérielles peuvent superposer plusieurs écrans bitmap avec des positions configurables. Celles-ci sont appelées sprites.

Certaines plates-formes n'autorisent pas la modification du modèle d'affichage lors de son envoi à l'écran, mais exigent plutôt que toutes les mises à jour aient lieu une fois que le faisceau a fini de dessiner une image mais avant de commencer à dessiner la suivante. Sur de telles plates-formes, tout ce qui va apparaître sur un cadre doit être chargé dans le matériel d'affichage avant le début de ce cadre et l'affichage se limitera à montrer un motif pouvant être configuré en une seule fois. Si la CPU devait cesser de fonctionner pendant l'affichage du cadre, ce même cadre continuerait à s'afficher indéfiniment. D'autres plates-formes permettent au motif d'être modifié ou reconfiguré pendant qu'il est dessiné à l'écran. Cela permet de montrer un écran beaucoup plus compliqué que les circuits vidéo ne pourraient gérer par lui-même.

La plupart des jeux pour ordinateurs personnels utilisent un matériel configuré pour dessiner un seul écran bitmap, puis affichent sur cet écran tout ce qui doit être différent de ce qui existe déjà. Parfois, il peut être plus facile de dessiner des choses sans se soucier de savoir si cela est réellement nécessaire dans un cas particulier, mais si le code peut facilement dire qu’il n’ya aucune raison de changer une partie de l’écran, les performances peuvent être améliorées en sautant cette partie. Les plates-formes actuelles sont souvent assez rapides pour dessiner l'écran entier à plusieurs reprises au cours d'une image, mais cela n'a pas toujours été le cas. Le code le plus rapide possible pour écrire tous les pixels sur l'écran haute résolution de l'ordinateur Apple II, par exemple, nécessiterait plus de deux images, et le code le plus rapide possible pour copier tous les pixels sur l'ordinateur Apple II ' Un écran haute résolution d’un autre tampon prendrait deux fois plus de temps. Pour obtenir de bonnes performances, il fallait que les jeux ne mettent à jour que des choses réellement en train de changer, et c'est ce que font généralement les bons jeux.

supercat
la source
1
Je suis arrivé à mi-chemin de cette réponse et je ne suis pas sûr de savoir comment cela répond réellement à la question. Votre premier paragraphe parle des processeurs, des coordonnées XY, des faisceaux d'électrons, des octets de mémoire et des sprites - mais rien de tout cela ne consiste à dessiner chaque image. Le deuxième paragraphe parle longuement des modèles d’affichage, puis il me perd. Je pense que vous devez prendre n'importe quelle partie de cela pour réellement redessiner l'écran, la mettre en haut dans une déclaration claire, puis relier tout ce dont vous avez besoin de parler pour expliquer ce qui se passe.
doppelgreener
1
@doppelgreener: La notion de "dessin" de chaque image est un peu vague. Quelque chose doit faire tout le nécessaire pour générer chaque image, mais il existe de nombreuses façons de travailler qui peuvent être divisées par le processeur et le matériel. Certains moyens exigent que le processeur soit impliqué dans chaque image même avec des parties de l'écran qui semblent identiques d'une image à l'autre, alors que d'autres ne le font pas. Tandis que tout jeu LCD ou CRT nécessitera en fin de compte que quelque chose sorte chaque cadre non vide [les jeux utilisant du papier électronique ou des affichages à bascule pourraient ne pas le faire], les actions nécessaires peuvent être ou ne pas être considérées comme des "dessins".
Supercat
Je vous suggère de commencer par le langage simple (si nous "dessinons un cadre" en permanence) et de travailler à partir de là, en expliquant plus de détails techniques sur les raisons pour lesquelles cela pourrait ne pas être une façon précise de le dire - au lieu de plonger directement dans les détails . Avant tout, votre message nécessite un résumé analytique et une introduction avant que vous ne commenciez à examiner la question à fond.
doppelgreener
-11

Pour le dire brièvement, je dirais que tous les cadres ne sont pas dessinés, mais seulement ceux qui sont nécessaires pour présenter votre histoire ou votre thème de jeu ou de jeu. De plus, le moment auquel vous souhaiteriez arriver dans certains cas importerait.

Sakib Zang
la source
9
Cela n’a même aucun sens avec la question posée. Je pense que vous avez confondu le "cadrage" de quelque chose d’autre ... êtes-vous en train de confondre avec des éléments d’un story-board? OP parle spécifiquement de cadres dans le contexte du rendu
Trotski94