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?

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.

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.

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.

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.

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.

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.